网站死链查询：静态响应与脚本渲染结果不同怎样定位差异
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0e783ef0ff7a.html
📄
网站死链查询：静态响应与脚本渲染结果不同怎样定位差异
先给结论：静态响应返回 200 不代表页面真实可用，脚本渲染后返回 404 也不代表服务器配置错误。两者不同时，优先判断差异来自“资源层”还是“路由层”——前者是 JS、接口、跳转链路的问题，后者是服务端返回码与前端路由不匹配。定位顺序是：先固定同一 URL 的静态响应码，再用渲染环境复现，最后对比差异发生在哪一步。
矛盾现象：同一 URL 两种结果
假设你抽查了 50 个 URL，静态抓取时全部返回 200，但用无头浏览器渲染后，其中 7 个显示 404 页面内容。这不是工具出错，而是两个环境看到的“页面”根本不是同一个东西。
静态抓取只拿到服务器返回的 HTML 源码，如果站点是 SPA 或依赖客户端路由，源码里可能只有一个空壳加一段 JS。渲染环境会执行 JS、请求接口、再决定展示什么内容。所以差异的本质是：你测的是两个不同阶段的产物。
两种解释：资源层问题 vs 路由层问题
解释一：资源层问题
静态 HTML 是正常模板，但渲染时某个 JS 文件或接口请求失败，前端兜底逻辑跳到了 404 组件。典型证据：
- 渲染日志里出现某个 JS 或 API 请求返回 4xx/5xx；
- 静态源码中能找到 404 组件或错误边界的代码痕迹；
- 同一批 URL 中，失败集中在依赖同一接口或同一 chunk 的页面。
解释二：路由层问题
服务端对所有路径都返回 200（常见于 history 模式的兜底配置），但前端路由表里没有对应路径，渲染后主动展示 404 内容。典型证据：
- 静态响应头里没有真实的内容协商，所有路径返回同一份 HTML；
- 渲染后的 404 是前端组件渲染出来的，不是服务器返回的；
- 差异只出现在特定路径模式上，比如带参数或深层嵌套的 URL。
能区分两种解释的证据
关键动作：对同一个 URL 分别记录三样东西——静态响应码、渲染后页面标题、渲染过程中的网络请求列表。
- 如果静态响应码是 200，渲染后标题是 404 页面，但网络请求全部成功，指向路由层问题。
- 如果静态响应码是 200，渲染后标题是 404 页面，且网络请求里有失败项，指向资源层问题。
- 如果静态响应码本身就是 404，那问题不在渲染，而在服务端配置或链接本身，属于另一类死链。
这个动作的结果直接决定下一步：路由层问题要改前端路由表或服务端兜底规则；资源层问题要查接口可用性和 JS 加载链路。两者修的地方完全不同，混在一起改会反复返工。
规模化后为什么会出现例外
单样本成立不代表批量成立。抽查 50 个 URL 时，你可能只覆盖了主要路径模式。规模化后出现例外，通常有三个边界：
- 参数化 URL：带查询参数的路径可能触发不同的接口分支，静态抓取时参数被忽略，渲染时才暴露。
- 登录态或权限差异：渲染环境如果带了 cookie，可能进入不同路由分支，静态抓取没有这个上下文。
- 缓存层差异：CDN 或服务端缓存可能对部分 URL 返回旧版本 HTML，渲染时拿到的是新版本 JS，两者不匹配。
所以不能直接把小样本结论套到全站。正确做法是：先按路径模式分层，每层抽 3–5 个样本做静态与渲染对比，确认差异集中在哪一层，再决定是否扩大检查范围。
一个假设的短例子
假设某站点有 1000 个 URL，你抽查 50 个发现 7 个渲染后 404。按路径分层后发现，这 7 个全部是带两级以上路径的 URL。进一步检查发现，服务端对所有路径返回 200，但前端路由表只注册了一级路径。此时结论是路由层问题，修复动作是补全路由表或调整服务端兜底策略。如果这 7 个分散在不同路径模式上，且渲染日志里有接口失败，那结论就变成资源层问题，修复动作转为查接口稳定性。
两种情况下，你下一步要动的东西完全不同，而区分它们只需要在同一个 URL 上同时记录静态响应码和渲染网络请求。这个动作不需要额外工具，但决定了你后续是改前端还是改服务端。
