404 not found：静态响应与脚本渲染结果不同时怎样定位差异，先固定一个可复现的请求条件
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /bc11996b12f6.html
📄
404 not found：静态响应与脚本渲染结果不同时怎样定位差异，先固定一个可复现的请求条件
先给有条件的结论：如果同一 URL 用禁用脚本的方式请求得到 404，而允许脚本执行后页面又出现内容，优先怀疑差异出在“谁在什么阶段决定响应状态”上，而不是先改页面文案。要定位它，需要把“服务器返回的状态”和“浏览器或渲染器执行后看到的页面”当成两条独立证据链来核对。若服务器对同一路径始终返回 200 且正文为空，而脚本再填入 404 提示，则上面的结论不成立，问题已从响应层转移到前端路由层。
先固定一个可复现的请求条件
不同角色对同一事实理解不同，通常是因为一方看的是原始响应，另一方看的是渲染后的页面。把分歧转成可核对项目的第一步，是固定请求条件：是否携带 Cookie、是否执行 JavaScript、请求方法是什么、是否跟随重定向。假设一个测试地址 /old-page，用命令行只取响应头时看到 HTTP/1.1 404 Not Found，而用带脚本的浏览器打开却看到完整导航和“页面不存在”的排版内容。这两个结果可以同时为真：服务器确实返回了 404，前端脚本只是把 404 状态渲染成了友好页面。
此时不要急着说“服务器错了”或“前端错了”。先记录三样东西：原始状态码、响应正文是否为空、脚本执行后 DOM 中是否出现主内容。若原始状态码为 404 且正文为空，脚本渲染出内容，说明差异来自渲染层；若原始状态码为 200 且正文包含“未找到”字样，说明差异来自服务端把错误页当正常页返回。这个区分会直接决定下一步是查路由配置还是查前端渲染逻辑。
用两组证据区分服务端路由与前端路由
第一组证据来自禁用脚本的请求。若禁用脚本后仍返回 404，且响应正文为空或只有极简错误提示，那么服务端路由已经认定该路径不存在。第二组证据来自允许脚本的请求。若允许脚本后页面出现完整布局，需要继续看这个布局是服务端渲染的输出，还是前端路由在客户端接管后生成的。
- 服务端路由问题：同一路径在不同请求方法下返回不同状态，例如 GET 返回 404 而 HEAD 返回 200，或带尾斜杠与不带尾斜杠结果不同。
- 前端路由问题：原始响应始终为 200，正文为空壳，脚本执行后才根据路径显示“未找到”组件。
- 混合问题：服务端对未知路径返回 404，但前端脚本又根据同一路径渲染了内容，导致状态码与页面语义不一致。
一个可操作的判断动作是：用同一路径分别请求两次，一次只看响应头，一次让渲染器执行脚本后取最终 DOM。若响应头为 404 而最终 DOM 有主内容，下一步应检查前端是否在 404 响应上继续挂载应用；若响应头为 200 而最终 DOM 显示未找到，下一步应检查服务端是否把兜底页错误地返回为 200。
把“404 提示页”和“404 状态”分开核对
很多分歧源于把“页面上写着 404”当成“响应状态是 404”。这两件事可以分离：服务端可以返回 404 状态并附带一个设计完整的错误页；也可以返回 200 状态并附带一段写着“未找到”的正文。后者对用户看似合理，但对需要判断资源是否存在的自动化流程会制造歧义。
核对时，先看响应头中的状态码，再看正文中是否包含主内容，最后看脚本执行后是否替换了正文。若状态码为 404 且正文包含主内容，说明错误页本身有内容，这不矛盾；若状态码为 200 且正文包含主内容，但脚本又显示“未找到”，说明前端路由和服务端路由对同一路径的判断不一致。此时应把路径、请求方法、状态码、正文长度、脚本执行后是否出现主内容列成一行记录，而不是继续用“我这边能打开”来争论。
一个带假设的短例子
假设某站点把未知路径交给前端路由处理，服务端对所有路径都返回 200 和同一个空壳 HTML。用户 A 用禁用脚本的方式请求 /missing，看到空正文，认为页面不存在；用户 B 用浏览器打开同一路径，脚本根据路由表渲染出“未找到”组件，认为页面正常处理了错误。两人说的都不是假话，但依据不同。若此时直接改服务端返回 404，而前端仍对 404 响应继续挂载应用，就可能出现状态码为 404、页面却仍有主内容的结果。下一步应统一约定：由服务端决定状态码，前端只负责在对应状态码下渲染错误页，而不是反过来用脚本决定状态语义。
结论失效的反例与下一步动作
如果服务器对同一路径始终返回 200，且正文中已经包含完整的“未找到”内容，那么“差异来自脚本渲染”这个结论就不成立，问题已变成服务端把错误页当正常页返回。此时继续查前端脚本不会解决状态码语义问题，应先修正服务端路由对未知路径的响应状态。
下一步动作可以这样安排：先选一个具体路径，分别记录禁用脚本与允许脚本两种条件下的状态码、正文长度和主内容是否存在；若两者状态码不同，优先查服务端路由和重定向规则；若状态码相同但主内容出现时机不同，优先查前端路由和渲染挂载条件。完成这一步后，再决定是调整服务端返回逻辑，还是调整前端对 404 响应的处理方式。只有把状态码与页面内容分开核对，多个角色对同一事实的分歧才能转成可验证、可修改的项目。
