404错误排查：测试环境与线上怎样对照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /28a291680b1d.html
📄
404错误排查：测试环境与线上怎样对照
在测试环境与线上对照排查404，核心做法是固定同一批URL，分别请求两边的完整响应，比较状态码、重定向链、响应头和实际返回内容，而不是只看浏览器页面是否显示正常。测试环境看不到404，线上却出现404，通常意味着请求域名、服务配置或数据版本在两边并不一致。
准备：先固定可对照的请求样本
从线上真实入口收集URL，不要凭记忆手写。优先覆盖三类：首页与栏目页、曾经可访问的旧链接、带参数的动态链接。每类取若干条，记录完整地址，包括协议、域名、路径、查询字符串和结尾斜杠。
- 用同一台机器或同一代理发起请求，排除本地DNS和网络差异。
- 记录请求方法，GET与HEAD的返回可能不同。
- 把线上域名与测试域名并列成表，只替换域名部分，其余保持逐字一致。
这一步决定后续结论是否可信。如果两边请求的路径本身写法不同，比较状态码没有意义。
实施：用命令获取原始响应
浏览器地址栏会自动补全、缓存和跳转，不适合做精确对照。用命令行分别请求两个环境，重点看状态码和重定向位置。下面命令中的域名需替换为实际域名，仅作方法示例。
curl -sS -o /dev/null -D - -L --max-redirs 5 https://example.com/old-page
去掉-L可以只观察第一跳，加-L则跟随重定向。对测试环境执行同一命令，只改域名。把两次输出的第一行状态码、location头、最终状态码逐项对照。
判断规则可以这样用：两边首跳都返回301且指向同一路径，说明重定向逻辑一致；线上301指向新地址而测试返回404，说明测试环境缺少该重定向规则；两边都返回404，则问题可能出在内容本身不存在，而不是环境差异。
验证：区分配置、数据与路由三类差异
状态码一致不代表页面一致，状态码不同也不代表只有一种原因。按下面顺序缩小范围。
- 检查Web服务器或反向代理的路径重写规则，确认测试与线上是否加载了同一份配置。
- 检查应用路由表，确认动态路由、大小写敏感和结尾斜杠处理是否相同。
- 检查内容数据，确认测试库中是否存在线上对应的文章、商品或页面记录。
- 检查静态资源目录，确认文件是否随发布流程同步到测试环境。
如果测试环境用简化数据，404很可能来自数据缺失而非代码缺陷。此时应补一条与线上同结构的记录再测，而不是直接修改路由。
涉及抓取限制时要注意，robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录。若404页面同时返回软404或200状态码，需要单独核查，不能与真实404混为一谈。
维护：把对照变成可重复的检查
每次发布前，用同一批URL对测试环境跑一遍，记录状态码和重定向链，与线上基线比较。基线可保存在版本库中，随配置变更更新。发现差异时，先确认是预期变更还是回归，再决定是否放行。
HTTPS不保证安全无漏洞或排名，因此不要用协议差异解释404。真正需要长期维护的是：URL清单、两边配置版本、数据同步状态和每次对照的结果记录。只要这三项可追溯，测试与线上的404差异就能被定位到具体环节。
下一步：选取线上最近出现404的十条URL，按上面的命令分别请求测试与线上，把首跳状态码和最终状态码填进同一张表，先找出两边不一致的那几条。
