这个插件解决什么问题
做资源分享站，最尴尬的一幕是这样的：读者点开你精心整理的资源帖，找到网盘链接，点进去，跳出来一句「分享的文件已经被取消」。他不会去怪网盘，他会觉得这个站不靠谱。
而这个问题几乎必然发生。网盘的分享链接会失效——作者删档、平台清理、会员到期、被举报封禁，任何一种都能让一条昨天还好好的链接今天就变成死链。资源站几百上千个下载点，靠人工一条条点开看，既做不完，也追不上失效的速度。
「网盘链接巡检」要解决的就是这件事：把下载点可用性核验变成自动流程，结果直接挂在资源详情页上，谁都能看见。
这里有个前提必须说在前面：有些网盘的链接，程序是真的判断不了。这个插件对这类情况的做法是如实标注「需要人工确认」，而不是猜一个状态糊弄过去。下面会说明哪些能判、哪些不能判，以及为什么。
插件概览
-
插件名称：网盘链接巡检
-
插件标识：
guaqi/link-check -
当前版本：v1.0.0
-
巡检引擎：linkcheck/1.0（纯 PHP 实现，零外部依赖）
-
运行环境：瓜奇（GuaQi）框架运行时插件，需 WordPress 侧支持
-
适用前端：Nuxt SSR 站点，核验结果在服务端直出
-
上线状态：已在 8号码库（8maoku.com）资源详情页启用运行
五档状态：查不了的就直说查不了
核验结果分五档。把「没查成」和「确实判不了」分开，是这个插件最要紧的设计：
-
可用：链接有效，已确认
-
已失效：链接确实挂了
-
需人工：网盘机制决定了程序无法判断，需要点开确认
-
未填写：这个下载点压根没填地址
-
请求失败：探测过程本身没成功（超时、证书异常等）
「已失效」和「需人工」必须分开。前者是可以直接下架的结论，后者只是「我们没查出问题，但也没法担保」。把判不了的说成失效，读者会去点一个其实好好的链接；说成可用，就等于替网盘做了担保。两种都是在骗人。
对读者展示的文案也按这个原则写：
ok → 已验证可用
dead → 该下载点暂时不可用
unknown → 该下载点需要登录后确认
empty → 该下载点暂未提供
error → 该下载点暂时无法核验复制
各网盘分别怎么判
不同网盘的判断方式完全不同，这也是不能拿一个「状态码检查」糊弄过去的原因。
阿里云盘、夸克网盘：官方接口，最可靠
这两家有公开的匿名分享接口，不需要登录、不需要签名。查一次能直接拿到分享名称和过期时间，失效时返回明确的错误码。这是证据强度最高的一档——不是「看起来像失效」，而是平台自己说这条分享不存在。
百度网盘、123云盘：页面标题 + 状态码
失效时返回 404 并带有明确的失效文案；有效时页面标题会提示「请输入提取码」。
自建分发短链：跟完跳转看落点
不少站点用自建短链分发资源。这类链接必须跟完重定向再判断——只看状态码会把失效短链判成活的，因为失效时短链系统会返回一个 200 的首页。
蓝奏云、移动云盘：判不了，如实标注
这两家必须单独说明：
-
蓝奏云：返回的是 JS 反爬挑战页。有效链接和失效链接的响应完全一致，解压后字节数相同，只有混淆变量的取值不同。静态请求无法区分。
-
移动云盘：分享页是前端路由的单页应用，服务端返回的 HTML 与这条分享是否存在无关。
还有一类同样判不了：夸克和阿里网盘的网页形态。有效页与失效页的 HTML 逐字节相同，都是前端空壳。所以这两家只能走官方接口，不能靠抓页面。
这几类在结果里统一标为「需人工」，不会伪装成任何确定结论。
实测：一个站的 111 个下载点
拿 8号码库自己实测：全站 104 篇文章、111 个下载点，串行跑完用 98.6 秒。
可用 106 · 已失效 0 · 需人工 4 · 未填写 1 · 请求失败 0复制
这个站没有真死链——4 条「需人工」不是查不出来，而是蓝奏云与移动云盘的机制决定的（3 条蓝奏云、1 条移动云盘）。另有 1 条是资源条目压根没填地址，属于内容问题，不是链接问题。
顺便说明这个数字该怎么看：如果站上真有失效链接，它会实打实地掉进来。引擎不会为了让报表好看，把判不出来的往「需人工」里塞，也不会把失效混进「可用」。
一次失败不算失效
网络抖动、对方限流、临时超时，都能让一次探测失败。如果一次失败就判定失效，站上会天天出现假警报，最后没人再信这个结果。
所以插件按「下载点名称 + 地址」做签名，只有连续两次都判定为失效或失败，才会在后台标出「连续 N 次」。换了一个地址，就当作一个新的下载点，不继承旧记录。
前台怎么呈现
核验结果有两个出口，既避免内容重复、又兼顾搜索引擎收录：
-
服务端直出：向文章正文追加一块核验结果，由服务端渲染，搜索引擎抓到的就是完整内容。
-
模块渲染：前端模块渲染出结果后，会把直出块摘掉，同一个页面不会出现两份一样的东西。
两种情况模块会整体隐藏，不留空壳：这篇文章没有登记任何下载点，或者从来没有核验过。「还没查」和「查了没问题」长得一样，才是真正会误导人的地方。
怎么跑巡检
单篇：编辑页点一下
文章编辑页右侧有「网盘下载点巡检」面板，列出这篇的全部下载点，点「立即巡检这一篇」同步执行，几秒钟出结果。
全站：工具页排队跑
后台 工具 → 网盘链接巡检，点「全站巡检（排队执行）」。全站 111 个点跑完要 98 秒，超过 PHP 的脚本执行上限，所以走的是分批队列——每批 3 篇，跑完一轮自动续下一轮。
装完之后，必须先跑一次
这一条最容易踩坑：插件装好、模块也布置到页面模板上了，前端却什么都不显示。原因通常不是插件坏了，而是一次巡检都没跑过——没有结果，模块就按设计隐藏了。先去后台跑一次，数据就有了。
后台配置
模块的配置项很少：
{
"apiBase": "https://www.q0di.top", // 核验结果接口地址
"showList": true, // 是否显示逐条明细
"showBars": true // 是否显示状态占比条
}复制
apiBase 留空也能用，会自动回落到站点源站。但注意不要填前端域名——前端通常只反代页面，/wp-json/ 这类接口路径在前端域名下是 404。
技术规格
-
纯 PHP 引擎：不调用
exec、proc_open、shell_exec等外部程序。宝塔默认禁用这些函数，引擎完全跑在 PHP 内部。 -
不下载整个文件：探测到响应是文件流时会立刻中断读取。否则每跑一次巡检，等于把站上所有资源包下载了一遍。
-
接口刻意裁字段：面向读者的接口只给「下载点名称 + 状态 + 一句话结论」，不下发下载地址，也不下发跳转链路。读者需要知道的是能不能用，不是地址是什么。
-
不解压交给系统：部分网盘的失效页会声明 gzip 但正文其实是明文，交给自动解压会连状态码都拿不回来。所以解压逻辑收归引擎，按响应头声明与 gzip 魔数双条件判断。
-
证书链兼容：部分国内小站证书链不全，遇到证书错误会降级重试一次，避免把「我们没查成」误报成「这个链接有问题」。
-
三语支持：简体中文 / English / Español，前台文案按语言分开存放。
上线提醒
下面几条是实际部署时踩过的坑，提前知道能省不少时间：
1. 装完先跑一次巡检
前面提过，这里再强调一遍：没有核验数据，页面上不会显示任何内容，这是设计而不是故障。插件不会自动巡检，需要手动触发一次。
2. 全站巡检依赖站点访问触发
分批队列走的是 WordPress 计划任务，而计划任务需要站点有访问才会执行。站点长时间没有流量时，任务会一直挂着。这种情况下在后台点一次单篇的「立即巡检这一篇」（同步执行，不依赖计划任务），或者访问一下站点把它带起来。
3. 巡检目标在资源字段里，不在正文
下载地址存在文章的资源数据字段（guaqi_metas）里，不是写在正文里。所以纯资讯类文章（没填资源条目的）不会有任何核验结果，这是正常的。
4. 安装、启用都在后台完成
运行时插件的安装与启用走的是会话级校验，应用密码接口只能读取插件目录、写不了。这一步没法用脚本批量处理，在后台的运行时插件页操作即可。
小结
「网盘链接巡检」把「这个下载链接还有没有效」从读者的碰运气，变成挂在资源详情页上、随时可查的一份状态。它会如实告诉读者哪些可用、哪些失效、哪些需要自己点开确认——包括那些它确实判断不了的。
本文介绍的插件为 8号码库原创，目前已在 8maoku.com 的资源详情页实际运行。判定规则可以按自己的资源类型继续增补。
