如果你也在多个平台分发内容早晚会需要一个脚本回答这个问题我上个月发出去的那些稿子现在还在吗最省事的写法是请求一下看状态码200 就算活着。这篇文章要说的是这个判据在真实的内容平台上会同时犯两种错——把活的判死把死的判活而且两种错都不报错、不抛异常安安静静地进你的表格。下面的所有形态都来自一次真实的批量复核先把口径写清楚。〇、本文数据的口径样本作者所属公司自己发布在各内容平台上的24 条存量稿件只测自家发布资产不涉及任何第三方或同类产品的内容。时间2026-09-20 19:39–19:47 PDT本机时区实读。方式全程curl游客态——不带 cookie、不带 Authorization、未登录任何平台桌面 Chrome 140 的 UA 串。重试每条 URL 的每种读数最多重试 3 次只有返回000才重试。只读全程 GET / HEAD无 POST未改动任何线上内容。⚠️ 一个必须披露的干扰项握手里出现过HTTP/1.1 200 Connection established说明请求走了本机的 HTTP CONNECT 代理。因此下文所有反爬类非 200403 / 521都可能掺杂代理出口 IP 的信誉因素本文不声称已排除这一项也不据此对任何平台下判断。样本性质这是一次自家资产的存活复核不是平台横评、不是行业抽样、也不是第三方独立评测样本量只有 24 条结论的适用范围仅到「写判活脚本时要防哪些形态」为止。一、起点一条看起来够用的判据我们一开始写死的判据是这么一句游客态 HTTP 200且正文不含「审核中 / 不存在 / 已删除 / 需要登录」四串 ⇒ 判为存活且过审。这条判据本身是合理的它同时管住了「页面在不在」和「内容过没过审」四串也确实是中文内容平台最常见的兜底文案。问题是把它对着 24 条真实 URL 跑一遍之后24 条里有 5 条的结论不成立而且脚本毫不知情。二、HTTP 200 的四种假阳性都是实测形态形态 A反爬壳 200 —— 不剥script活稿会被判死某订阅号平台的三条稿页面本体是 3.4–3.5 MB 的完整 HTML实测 3,474,821 B / 3,487,962 B / 3,568,121 B2026-09-20 实读。拿原始 HTML直接 grep 那四串三篇各命中「不存在」3 次、「已删除」1 次。看上下文就知道冤枉...throw new Error(... thirdExtParam 不存在);... ..., 4: { show: !0, msg: 商品已删除 }, 5: {...这是页面自带的 JS 库里的模板串和报错串跟文章状态毫无关系。剥掉script/style/ 注释 / 标签之后三篇的四串命中数全部归零正文分别是 4,599 B / 5,805 B / 10,953 B页面里的标题字段读回的也是真实文章标题。纪律一判据原文写的是「正文不含」那就必须先把脚本剥掉再判。拿原始 HTML 去 grep等于让页面的前端代码替你的文章判死刑。形态 B空壳 200 —— 任意 ID 都回同一个响应某资讯客户端的两条稿HEAD 和 GET 都稳定 200字节数72,914 B。这时候最该做的动作是对照实验拿一个故意编的、根本不存在的文章 ID去请求同一个路径。结果对象HTTP字节响应体 md5已发布稿 ①20072,914完全相同已发布稿 ②20072,914完全相同故意编的错 ID20072,914完全相同三者的响应体md5 逐位相同。body 是个反爬 JS 壳剥脚本后正文1 字节没有title文章标题 0 命中。⇒ 这个平台对任何 article id 都回同一个 200 空壳。⇒ 在这里「200 四串 0 命中」这个结论和「这篇文章根本不存在」在信息上不可区分。所以正确的记法不是「它活着」也不是「它死了」而是本方法在这个平台上测不出来需要另案取证登录态、或浏览器渲染后再读。纪律二任何「全绿」的批量结果先拿一个故意编错的 ID 跑一遍。真 ID 与假 ID 的响应不可区分 ⇒ 这一格的结论作废记「测不出」不记「通过」。形态 C200 回 404 页 —— 状态码对了落地 URL 已经跳走某图文社区的三条内容页-IHEAD不跟随返回302-LGET跟随跳转返回20096,759 B但最终落地 URL 已经不是内容页而是该站的/404路径query 里带着一个错误码与一段中文错误文案大意是「当前内容暂时无法浏览」title是一句「你访问的页面不见了」式的通用文案剥脚本后正文415 B四串审核中 / 不存在 / 已删除 / 需要登录一个都没命中。机械套判据200 四串 0 命中 ⇒ 判「存活且过审」。实际上这三条已经不可浏览了。同样做对照实验拿一个全 0 的假 ID 请求落地形态完全相同200 同一个/404页 同一个错误码。这不是平台的错是判据本身的漏口一个站完全可以用「200 一个前端 404 页」来表达「没有」而它的 404 文案里一个中文关键词都不用出现。纪律三必须记录并检查%{url_effective}跟随跳转后的最终 URL。最终落地 URL 不在文章路径域内尤其跳到/404⇒ 一律判不过不管状态码是多少。形态 D间歇 521 / 200 —— 同一条 URL两次读数两个结论某开发者社区的一条稿第一次读是5212,165 B该站的反爬拦截页重试一次就是 200190,635 B剥脚本后正文 35,706 Btitle与登记标题逐字一致四串 0 命中。同一条 URL、同一次批量、同一套参数前后两次读数给出两个相反的结论。⇒ 结论只能记「重试后取到的那一次」并且不许写成「稳定 200」。跑批量的时候这种条目会随跑随变如果你的表格只存最后一次读数而不存重试次数下次复盘时你自己都不知道它当时抖过。三、反过来也一样非 200 不等于稿子死了同一批里某问答社区的7 条1 篇专栏 6 条回答全部返回403且响应体都是 650 B 的同一个壳剥脚本后正文 103 B是该站的通用欢迎语四串 0 命中。按判据的字面意思这 7 条全部判不过。但 403 定长壳 通用欢迎语是典型的反爬特征跟「文章被删」「未过审」完全是两回事——何况本次出口还挂着 CONNECT 代理见 §〇IP 信誉这一项我们排除不掉。⇒ 我们的记法是这 7 条既不记「存活」也不记「被删」记「本法测不出另案取证」并且不擅自给判据加「403 豁免」——加豁免等于给脚本开了一个永远不会报警的后门。对照组是有的同一批里确实有一条真删了的——HTTP40426,112 B剥脚本后正文里「不存在」命中 1 次。真的删稿长这样反爬不长这样。两者的区别不在状态码在响应体的形态。四、单条失败必须重试000是网络不是结论这批 24 条里有 6 条首次请求直接返回000curl 没拿到任何 HTTP 响应重试之后分别变成 200 或 403。这一周里本机还出现过另外几次同类的瞬时 TLS 失败本周本机共观察到 3 次同型瞬断2 次在 2026-09-20 当晚、1 次在 09-17分属不同的请求任务重试即恢复。定性是本机网络侧的抖动不是目标站故障。纪律四000永远不是结论只是一次没打通。单条失败必须重试我们设的是最多 3 次之后才允许判死否则你的「死链清单」里会混进一堆当晚网络不好的条目。五、两个工具层的坑一个比一个静这两条不涉及平台纯粹是脚本自己会骗自己我们两条都踩了。坑 1用-I | head -1取状态码在有代理的机器上全读成 200第一版脚本是这么取码的curl-sSI$URL|head-1|awk{print $2}# ⛔ 不要这么写本机有 HTTP CONNECT 代理于是响应的第一行是代理自己的HTTP/1.1 200 Connection established结果24 条全部读成 200——包括那条已经真删、实际返回 404 的。整跑出来是一张漂亮的全绿表而它一个字都不成立。第一遍就是这么错的作废重跑。正确写法是让 curl 自己报最终状态码curl-sS-o/dev/null-w%{http_code}-I--max-time20-A$UA$URL纪律五永远用-w %{http_code}取状态码不要去解析响应头的文本行。任何中间层代理、隧道、CDN 调试头都可能在你要的那一行之前插一行。坑 2坏 URL 不会报错只会让整批安静地返回000判活脚本的输入是一份 URL 清单而清单通常不是手敲的——是从别处抽出来的。抽的那一步出了错curl 不会告诉你。同一周另一批批量核查里我们的清单是从一份 XML 里用sed剥标签抽出来的。剥标签那条正则在 macOS 自带的 sed 上没按预期生效BRE 与 ERE 的?写法不通用这里要的是sed -E于是每一行 URL 都带着没剥干净的尖括号残片。curl 拿到这种 URL 的反应是不抛错、退出码正常、状态码一律000。屏幕上是一整张000的表——而在你会怀疑的东西里「我的 URL 本身是坏的」排得非常靠后网络、证书、对方封了你都排在它前面。这个坑的普遍形式跟sed无关输入只要经过一次转换就必须在进循环之前肉眼验一眼转换结果。纪律六抽完 URL 先打印前 3 条看一眼再进循环。并且——整批同值本身就是告警信号不是结果全000、全 200、字节数全等三种都算。坑 1 那张全绿表和这张全000表是同一个病的两个症状。六、补完之后的判据可以直接抄把上面六条纪律并进去判据从一条变成四条四条同时成立才判「存活且过审」游客态不带 cookie、不带 Authorization请求返回200并记录这个 200 是第几次读数取到的——形态 D 那种 521↔200 的抖动会让同一条 URL 先后读出两个相反的结论最终落地 URL%{url_effective}仍在文章路径域内—— 跳到/404、跳到登录页、跳到站点首页一律判不过剥掉script/style/ 注释 / 标签之后的正文不含「审核中 / 不存在 / 已删除 / 需要登录」与故意编错的 ID 做过对照两者的响应可区分字节数、md5、正文长度、标题字段任一项能分开不可区分 ⇒ 判「测不出」不判「通过」。另外两条不进判据、但必须进表格反爬类非 200403 / 间歇 521单独记一栏「本法测不出」⛔ 不并进「被删」每条记重试次数与最终读数来自第几次⛔ 不把重试得来的 200 写成「稳定 200」。三种读数的 curl 写法UAMozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36# ① HEAD不跟随跳转看这一跳本身是什么curl-sS-o/dev/null-w%{http_code}-I--max-time20-A$UA$URL# ② GET跟随跳转把最终落地 URL 和体积一起记下来curl-sS-obody/$ID.html-w%{http_code}|%{url_effective}|%{size_download}\-L--max-time30-A$UA$URL# ③ 正文判读先剥 script/style/注释/标签再查四串perl-0777-pes/script\b.*?\/script//gsi; s/style\b.*?\/style//gsi; s/!--.*?--//gs; s/[^]/ /gs; s/\s/ /gbody/$ID.html①②③ 各自最多重试 3 次只有000才重试非 000 的状态码是有效读数重试会掩盖形态 D 那种抖动。对照实验只是把$ID换成一个编出来的假值跑同样的 ①②③然后比md5、比size_download、比剥脚本后的正文长度md5body/$ID.htmlbody/FAKE.html# macOSLinux 用 md5sum七、这套方法测不出什么必须写清楚的边界同一批 24 条先按 §一 那条起点判据机械汇总一次2026-09-20 实测、样本 24 条、游客态结论分三堆结论条数判「存活且过审」200 落地 URL 在域内 剥脚本后四串 0 命中 标题字段与登记标题逐字一致11判「不过」起点判据只看状态码把反爬和真删算在一起8其中 7 条是反爬 4031 条是真删404 正文命中「不存在」判「本法测不出」起点判据判不出、靠对照实验才暴露的5空壳 200 的 2 条 200 回/404的 3 条⚠️ 这张表是机械汇总不是补完后的判据的输出。换上 §六 的四条判据再读一遍「判不过」那 8 条里的7 条反爬 403 要移进「本法测不出」§三 的理由真正判「不过」的只剩那 1 条真删。也就是说起点判据下24 条里有5 条给不出结论补完后的判据下给不出结论的是5 7 12 条正好一半。补完判据没有让更多稿子「过」它只是让更多的「不知道」显形。这是这套方法真实的天花板不是可以四舍五入掉的余数——一个把 12 条不确定条目写成「通过」的脚本比一个老实承认一半测不出的脚本危险得多。它测不出的场景至少还有三类登录墙判据里留「需要登录」这一串是为了覆盖跳登录页 / 登录墙这种形态本次 24 条里没有出现这种形态所以上面的数据不能当成「这条串被验证过」的证据内容被改而没被删状态码、落地 URL、四串全部正常正文却被平台悄悄删改过——要靠正文比对哈希或长度基线才发现登录态下才可见的限流游客态 200不等于分发正常。这套方法只回答「这个 URL 现在还能不能被一个没登录的访客打开、且不是一个否定页」它不回答任何关于流量、分发或效果的问题。八、一张可以抄走的自检清单写完你的判活脚本对照过一遍再上线状态码用-w %{http_code}取不解析响应头文本行记录并检查%{url_effective}跳到/404、登录页、首页一律判不过判正文前先剥script/style/ 注释 / 标签每条至少跑一次「故意错 ID」对照不可区分就判「测不出」000必须重试建议 3 次后才判死并记录重试次数反爬类非 200 单开一栏不并进「被删」sed用-E抽完 URL 先打印前 3 条肉眼确认整批同值全 200 / 全 000 / 字节数全等当成告警不当成结果表里同时存状态码、最终 URL、字节数、剥脚本后正文长度、md5、重试次数——少一列下次复盘就还得重跑最后一句可能是这篇文章里最有用的批量核查最危险的输出不是报错是一张全绿的表。遇到全绿先去验你的脚本再去信你的数据。本文数据来自作者所属公司对自家已发布稿件的一次批量可达性复核2026-09-20 实测、24 条、游客态文字由 AI 辅助创作、作者审校发布。利益相关本文作者所属公司开发并运营一款 GEO生成式引擎优化监测工具本文全部数据来自对该公司自家已发布稿件的一次批量可达性复核样本为自家存量稿件 24 条、非行业代表性抽样非第三方独立评测。本文不含任何推广链接与购买入口。
如果你也在多个平台分发内容早晚会需要一个脚本回答这个问题我上个月发出去的那些稿子现在还在吗最省事的写法是请求一下看状态码200 就算活着。这篇文章要说的是这个判据在真实的内容平台上会同时犯两种错——把活的判死把死的判活而且两种错都不报错、不抛异常安安静静地进你的表格。下面的所有形态都来自一次真实的批量复核先把口径写清楚。〇、本文数据的口径样本作者所属公司自己发布在各内容平台上的24 条存量稿件只测自家发布资产不涉及任何第三方或同类产品的内容。时间2026-09-20 19:39–19:47 PDT本机时区实读。方式全程curl游客态——不带 cookie、不带 Authorization、未登录任何平台桌面 Chrome 140 的 UA 串。重试每条 URL 的每种读数最多重试 3 次只有返回000才重试。只读全程 GET / HEAD无 POST未改动任何线上内容。⚠️ 一个必须披露的干扰项握手里出现过HTTP/1.1 200 Connection established说明请求走了本机的 HTTP CONNECT 代理。因此下文所有反爬类非 200403 / 521都可能掺杂代理出口 IP 的信誉因素本文不声称已排除这一项也不据此对任何平台下判断。样本性质这是一次自家资产的存活复核不是平台横评、不是行业抽样、也不是第三方独立评测样本量只有 24 条结论的适用范围仅到「写判活脚本时要防哪些形态」为止。一、起点一条看起来够用的判据我们一开始写死的判据是这么一句游客态 HTTP 200且正文不含「审核中 / 不存在 / 已删除 / 需要登录」四串 ⇒ 判为存活且过审。这条判据本身是合理的它同时管住了「页面在不在」和「内容过没过审」四串也确实是中文内容平台最常见的兜底文案。问题是把它对着 24 条真实 URL 跑一遍之后24 条里有 5 条的结论不成立而且脚本毫不知情。二、HTTP 200 的四种假阳性都是实测形态形态 A反爬壳 200 —— 不剥script活稿会被判死某订阅号平台的三条稿页面本体是 3.4–3.5 MB 的完整 HTML实测 3,474,821 B / 3,487,962 B / 3,568,121 B2026-09-20 实读。拿原始 HTML直接 grep 那四串三篇各命中「不存在」3 次、「已删除」1 次。看上下文就知道冤枉...throw new Error(... thirdExtParam 不存在);... ..., 4: { show: !0, msg: 商品已删除 }, 5: {...这是页面自带的 JS 库里的模板串和报错串跟文章状态毫无关系。剥掉script/style/ 注释 / 标签之后三篇的四串命中数全部归零正文分别是 4,599 B / 5,805 B / 10,953 B页面里的标题字段读回的也是真实文章标题。纪律一判据原文写的是「正文不含」那就必须先把脚本剥掉再判。拿原始 HTML 去 grep等于让页面的前端代码替你的文章判死刑。形态 B空壳 200 —— 任意 ID 都回同一个响应某资讯客户端的两条稿HEAD 和 GET 都稳定 200字节数72,914 B。这时候最该做的动作是对照实验拿一个故意编的、根本不存在的文章 ID去请求同一个路径。结果对象HTTP字节响应体 md5已发布稿 ①20072,914完全相同已发布稿 ②20072,914完全相同故意编的错 ID20072,914完全相同三者的响应体md5 逐位相同。body 是个反爬 JS 壳剥脚本后正文1 字节没有title文章标题 0 命中。⇒ 这个平台对任何 article id 都回同一个 200 空壳。⇒ 在这里「200 四串 0 命中」这个结论和「这篇文章根本不存在」在信息上不可区分。所以正确的记法不是「它活着」也不是「它死了」而是本方法在这个平台上测不出来需要另案取证登录态、或浏览器渲染后再读。纪律二任何「全绿」的批量结果先拿一个故意编错的 ID 跑一遍。真 ID 与假 ID 的响应不可区分 ⇒ 这一格的结论作废记「测不出」不记「通过」。形态 C200 回 404 页 —— 状态码对了落地 URL 已经跳走某图文社区的三条内容页-IHEAD不跟随返回302-LGET跟随跳转返回20096,759 B但最终落地 URL 已经不是内容页而是该站的/404路径query 里带着一个错误码与一段中文错误文案大意是「当前内容暂时无法浏览」title是一句「你访问的页面不见了」式的通用文案剥脚本后正文415 B四串审核中 / 不存在 / 已删除 / 需要登录一个都没命中。机械套判据200 四串 0 命中 ⇒ 判「存活且过审」。实际上这三条已经不可浏览了。同样做对照实验拿一个全 0 的假 ID 请求落地形态完全相同200 同一个/404页 同一个错误码。这不是平台的错是判据本身的漏口一个站完全可以用「200 一个前端 404 页」来表达「没有」而它的 404 文案里一个中文关键词都不用出现。纪律三必须记录并检查%{url_effective}跟随跳转后的最终 URL。最终落地 URL 不在文章路径域内尤其跳到/404⇒ 一律判不过不管状态码是多少。形态 D间歇 521 / 200 —— 同一条 URL两次读数两个结论某开发者社区的一条稿第一次读是5212,165 B该站的反爬拦截页重试一次就是 200190,635 B剥脚本后正文 35,706 Btitle与登记标题逐字一致四串 0 命中。同一条 URL、同一次批量、同一套参数前后两次读数给出两个相反的结论。⇒ 结论只能记「重试后取到的那一次」并且不许写成「稳定 200」。跑批量的时候这种条目会随跑随变如果你的表格只存最后一次读数而不存重试次数下次复盘时你自己都不知道它当时抖过。三、反过来也一样非 200 不等于稿子死了同一批里某问答社区的7 条1 篇专栏 6 条回答全部返回403且响应体都是 650 B 的同一个壳剥脚本后正文 103 B是该站的通用欢迎语四串 0 命中。按判据的字面意思这 7 条全部判不过。但 403 定长壳 通用欢迎语是典型的反爬特征跟「文章被删」「未过审」完全是两回事——何况本次出口还挂着 CONNECT 代理见 §〇IP 信誉这一项我们排除不掉。⇒ 我们的记法是这 7 条既不记「存活」也不记「被删」记「本法测不出另案取证」并且不擅自给判据加「403 豁免」——加豁免等于给脚本开了一个永远不会报警的后门。对照组是有的同一批里确实有一条真删了的——HTTP40426,112 B剥脚本后正文里「不存在」命中 1 次。真的删稿长这样反爬不长这样。两者的区别不在状态码在响应体的形态。四、单条失败必须重试000是网络不是结论这批 24 条里有 6 条首次请求直接返回000curl 没拿到任何 HTTP 响应重试之后分别变成 200 或 403。这一周里本机还出现过另外几次同类的瞬时 TLS 失败本周本机共观察到 3 次同型瞬断2 次在 2026-09-20 当晚、1 次在 09-17分属不同的请求任务重试即恢复。定性是本机网络侧的抖动不是目标站故障。纪律四000永远不是结论只是一次没打通。单条失败必须重试我们设的是最多 3 次之后才允许判死否则你的「死链清单」里会混进一堆当晚网络不好的条目。五、两个工具层的坑一个比一个静这两条不涉及平台纯粹是脚本自己会骗自己我们两条都踩了。坑 1用-I | head -1取状态码在有代理的机器上全读成 200第一版脚本是这么取码的curl-sSI$URL|head-1|awk{print $2}# ⛔ 不要这么写本机有 HTTP CONNECT 代理于是响应的第一行是代理自己的HTTP/1.1 200 Connection established结果24 条全部读成 200——包括那条已经真删、实际返回 404 的。整跑出来是一张漂亮的全绿表而它一个字都不成立。第一遍就是这么错的作废重跑。正确写法是让 curl 自己报最终状态码curl-sS-o/dev/null-w%{http_code}-I--max-time20-A$UA$URL纪律五永远用-w %{http_code}取状态码不要去解析响应头的文本行。任何中间层代理、隧道、CDN 调试头都可能在你要的那一行之前插一行。坑 2坏 URL 不会报错只会让整批安静地返回000判活脚本的输入是一份 URL 清单而清单通常不是手敲的——是从别处抽出来的。抽的那一步出了错curl 不会告诉你。同一周另一批批量核查里我们的清单是从一份 XML 里用sed剥标签抽出来的。剥标签那条正则在 macOS 自带的 sed 上没按预期生效BRE 与 ERE 的?写法不通用这里要的是sed -E于是每一行 URL 都带着没剥干净的尖括号残片。curl 拿到这种 URL 的反应是不抛错、退出码正常、状态码一律000。屏幕上是一整张000的表——而在你会怀疑的东西里「我的 URL 本身是坏的」排得非常靠后网络、证书、对方封了你都排在它前面。这个坑的普遍形式跟sed无关输入只要经过一次转换就必须在进循环之前肉眼验一眼转换结果。纪律六抽完 URL 先打印前 3 条看一眼再进循环。并且——整批同值本身就是告警信号不是结果全000、全 200、字节数全等三种都算。坑 1 那张全绿表和这张全000表是同一个病的两个症状。六、补完之后的判据可以直接抄把上面六条纪律并进去判据从一条变成四条四条同时成立才判「存活且过审」游客态不带 cookie、不带 Authorization请求返回200并记录这个 200 是第几次读数取到的——形态 D 那种 521↔200 的抖动会让同一条 URL 先后读出两个相反的结论最终落地 URL%{url_effective}仍在文章路径域内—— 跳到/404、跳到登录页、跳到站点首页一律判不过剥掉script/style/ 注释 / 标签之后的正文不含「审核中 / 不存在 / 已删除 / 需要登录」与故意编错的 ID 做过对照两者的响应可区分字节数、md5、正文长度、标题字段任一项能分开不可区分 ⇒ 判「测不出」不判「通过」。另外两条不进判据、但必须进表格反爬类非 200403 / 间歇 521单独记一栏「本法测不出」⛔ 不并进「被删」每条记重试次数与最终读数来自第几次⛔ 不把重试得来的 200 写成「稳定 200」。三种读数的 curl 写法UAMozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36# ① HEAD不跟随跳转看这一跳本身是什么curl-sS-o/dev/null-w%{http_code}-I--max-time20-A$UA$URL# ② GET跟随跳转把最终落地 URL 和体积一起记下来curl-sS-obody/$ID.html-w%{http_code}|%{url_effective}|%{size_download}\-L--max-time30-A$UA$URL# ③ 正文判读先剥 script/style/注释/标签再查四串perl-0777-pes/script\b.*?\/script//gsi; s/style\b.*?\/style//gsi; s/!--.*?--//gs; s/[^]/ /gs; s/\s/ /gbody/$ID.html①②③ 各自最多重试 3 次只有000才重试非 000 的状态码是有效读数重试会掩盖形态 D 那种抖动。对照实验只是把$ID换成一个编出来的假值跑同样的 ①②③然后比md5、比size_download、比剥脚本后的正文长度md5body/$ID.htmlbody/FAKE.html# macOSLinux 用 md5sum七、这套方法测不出什么必须写清楚的边界同一批 24 条先按 §一 那条起点判据机械汇总一次2026-09-20 实测、样本 24 条、游客态结论分三堆结论条数判「存活且过审」200 落地 URL 在域内 剥脚本后四串 0 命中 标题字段与登记标题逐字一致11判「不过」起点判据只看状态码把反爬和真删算在一起8其中 7 条是反爬 4031 条是真删404 正文命中「不存在」判「本法测不出」起点判据判不出、靠对照实验才暴露的5空壳 200 的 2 条 200 回/404的 3 条⚠️ 这张表是机械汇总不是补完后的判据的输出。换上 §六 的四条判据再读一遍「判不过」那 8 条里的7 条反爬 403 要移进「本法测不出」§三 的理由真正判「不过」的只剩那 1 条真删。也就是说起点判据下24 条里有5 条给不出结论补完后的判据下给不出结论的是5 7 12 条正好一半。补完判据没有让更多稿子「过」它只是让更多的「不知道」显形。这是这套方法真实的天花板不是可以四舍五入掉的余数——一个把 12 条不确定条目写成「通过」的脚本比一个老实承认一半测不出的脚本危险得多。它测不出的场景至少还有三类登录墙判据里留「需要登录」这一串是为了覆盖跳登录页 / 登录墙这种形态本次 24 条里没有出现这种形态所以上面的数据不能当成「这条串被验证过」的证据内容被改而没被删状态码、落地 URL、四串全部正常正文却被平台悄悄删改过——要靠正文比对哈希或长度基线才发现登录态下才可见的限流游客态 200不等于分发正常。这套方法只回答「这个 URL 现在还能不能被一个没登录的访客打开、且不是一个否定页」它不回答任何关于流量、分发或效果的问题。八、一张可以抄走的自检清单写完你的判活脚本对照过一遍再上线状态码用-w %{http_code}取不解析响应头文本行记录并检查%{url_effective}跳到/404、登录页、首页一律判不过判正文前先剥script/style/ 注释 / 标签每条至少跑一次「故意错 ID」对照不可区分就判「测不出」000必须重试建议 3 次后才判死并记录重试次数反爬类非 200 单开一栏不并进「被删」sed用-E抽完 URL 先打印前 3 条肉眼确认整批同值全 200 / 全 000 / 字节数全等当成告警不当成结果表里同时存状态码、最终 URL、字节数、剥脚本后正文长度、md5、重试次数——少一列下次复盘就还得重跑最后一句可能是这篇文章里最有用的批量核查最危险的输出不是报错是一张全绿的表。遇到全绿先去验你的脚本再去信你的数据。本文数据来自作者所属公司对自家已发布稿件的一次批量可达性复核2026-09-20 实测、24 条、游客态文字由 AI 辅助创作、作者审校发布。利益相关本文作者所属公司开发并运营一款 GEO生成式引擎优化监测工具本文全部数据来自对该公司自家已发布稿件的一次批量可达性复核样本为自家存量稿件 24 条、非行业代表性抽样非第三方独立评测。本文不含任何推广链接与购买入口。
