404状态码，移动端与桌面端怎样检查差异
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e8095966645e.html
📄
404状态码，移动端与桌面端怎样检查差异
检查移动端与桌面端的404差异，核心是比较同一路径在两种User-Agent和两种视口下返回的HTTP状态码是否一致。最可靠的做法是用命令行分别请求，而不是只靠肉眼浏览。下面从一个假设的协作场景展开。
假设场景：一次上线后的分歧
假设某团队上线新版页面，把旧路径 /promo/spring 迁移到 /campaign/spring。桌面端测试同事反馈“正常跳转”，移动端测试同事反馈“显示404页”。两人都没说谎，但结论不同，说明检查口径不一致。交付前需要把这个差异定位清楚，否则修复方向会跑偏。
常见错误有三种：一是只在浏览器地址栏输入，浏览器缓存了旧响应；二是只看页面内容，不看HTTP状态码，把“返回200但内容是404提示页”当成真404；三是移动端用了不同的域名或路径前缀，比如 m.example.com 与 www.example.com，两者路由规则本就不同。
用命令行分别请求两端
先固定一个待测URL，然后用不同User-Agent请求，观察状态码行。示意命令如下，域名和路径请替换为实际值：
curl -I -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" https://www.example.com/promo/spring
curl -I -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" https://www.example.com/promo/spring
输出第一行的三位数字就是状态码。两端都返回 404，说明是同一处路由缺失；一端 301 或 302、另一端 404，说明重定向规则按设备分流，移动端分支漏配；两端都返回 200，但页面写着“未找到”，那是软404，需要单独处理。
移动端检查要多看两项
移动端与桌面端的差异，往往不只在User-Agent，还在视口和渲染方式。检查时补上这两项：
- 视口宽度：用窄视口打开，确认404页面本身是否可读，而不是被样式挤成空白，让人误以为“页面不存在”。
- 跳转链路：如果移动端先跳转到独立域名再返回404，要记录完整跳转链，判断是第几跳丢失。
判断结果时注意：curl -I 只取响应头，不执行JavaScript。若站点用前端路由，服务端可能对任意路径都返回 200，真正的404由脚本渲染。这种情况下命令行结果与浏览器表现会不同，需要再用浏览器开发者工具的Network面板核对文档请求的状态码。
协作交付时怎么记录
为减少返工，建议每个待测URL交付一张对照表，字段固定为：URL、设备类型、User-Agent摘要、状态码、最终URL、检查时间。两端各填一行，差异一眼可见。若状态码不同，再附上定位结论，区分“可能原因”和“已定位原因”：前者写“疑似移动端重定向规则未覆盖”，后者写“移动端分支返回404，桌面端返回301，已复现”。
还要注意边界：robots.txt 的抓取限制不等于索引移除，站点地图也不保证收录。这些与404的设备差异是不同层面的问题，不要混在一张表里下结论。
下一步，挑一个已知会分流的URL，按上面的命令各跑一次，把两张响应头并排贴进协作文档，先确认状态码是否一致，再决定改路由还是改重定向。
