做内容站的人大概都干过这件事：新发一篇东西，然后一天点开三遍搜索引擎的站长后台，盯着「索引量」看它涨了没有。涨了，说明蜘蛛来过；没涨，就继续等，也不知道要等多久。

这不是错觉。搜索引擎发现新页面主要靠「爬」，而爬需要时间——站点权重越低、页面越深、外链越少，蜘蛛来的越慢，几天到几周都算正常。一个新发的地址，就这样躺在那里等着被摸到。

「收录主动推送」把这件事反过来做：不等蜘蛛自己找过来，内容一发布，就把地址主动递到搜索引擎的收录通道口。百度普通收录 API 和 IndexNow 都是官方为此开放的接口——你给我地址，我去抓。

做源码分享站，有一件事最怕：包里有后门，自己成了投毒链条上的一环。用户在你这里下载、中招、回头找你——砸的是自己的招牌，而这个问题在下载量上来之后几乎必然遇到。

另一件更日常的事是：买家问「这个包安全吗」，你只能回一句「应该没问题」。想认真回答就得人工审——一个 20MB 的商业源码包，PHP 文件上百个，逐个人工看一遍不现实，看完了也没法留下凭证给下一个买家看。

「源码安全检测报告」要解决的就是这两件事：把资源包的安全检测变成自动流程，检测结果直接挂在资源详情页上，谁都能看得见。不用装任何外部程序，也不用把源码交到第三方平台。

做资源分享站，最尴尬的一幕是这样的：读者点开你精心整理的资源帖，找到网盘链接，点进去，跳出来一句「分享的文件已经被取消」。他不会去怪网盘，他会觉得这个站不靠谱。

而这个问题几乎必然发生。网盘的分享链接会失效——作者删档、平台清理、会员到期、被举报封禁，任何一种都能让一条昨天还好好的链接今天就变成死链。资源站几百上千个下载点，靠人工一条条点开看，既做不完，也追不上失效的速度。

「网盘链接巡检」要解决的就是这件事：把下载点可用性核验变成自动流程，结果直接挂在资源详情页上，谁都能看见。

1panel 安装瓜奇 Node 端的时候，会将 server/index.mjs 会加载上一级的 ../launcher.mjs。但是入口却是 /app/index.mjs，所以解析成了 /launcher.mjs，会导致启动失败。

在 1Panel 中调整：

将完整发布目录挂载到 /app，保留以下结构，不能只挂载 server：

根据文档说明，基础版是「服务端 1 个，前端无限制」，并且一个 WordPress 后台可以对应多个前端。

假设我的部署方式如下：

WordPress 后台部署在 api.example.com（或单独一台服务器）