与开发人员交接 404notfound 问题,核心不是把“页面打不开”丢过去,而是先确认请求返回的是真正的 HTTP 404,还是内容存在但入口失效。交接时应提供可复现的 URL、请求时间、返回状态码、来源页面和期望结果,并明确这是线上问题还是测试环境问题。这样开发才能判断是路由缺失、资源被删、重定向配置错误,还是服务器把其他错误伪装成了 404。
很多交接失败,是因为双方对“404”的理解不同。浏览器或应用界面可能显示“未找到”,但服务器实际返回的是 200、302、403 或 500。对搜索引擎和监控系统来说,HTTP 状态码才是判断依据,页面上的文字只是给用户看的。
可以用浏览器开发者工具或命令行检查:
curl -I https://example.com/path 只看响应头,确认第一行状态码。判断结果:状态码为 404,说明资源在服务器端未找到;状态码为 200 但页面提示未找到,说明请求成功但应用层没有匹配内容;状态码为 301 或 302,说明发生了跳转,应继续检查跳转目标是否有效。
开发不需要一段模糊描述,而需要能复现问题的上下文。下面这份清单可以直接复制到工单或聊天记录中,按实际情况填写。
如果问题涉及一批 URL,例如同一目录下大量旧页面,可以给出一个代表性 URL 和 URL 模式,例如 /old-products/*,再附上两三个具体例子。这样开发能判断是单点问题还是规则问题。
交接时最忌讳把猜测写成结论。你可以写“可能原因”,但必须标明尚未验证;只有经过检查的现象才能写成“已经定位”。
curl -I 显示 404,且服务器访问日志中同一路径记录为 404,同时该路径在代码路由表中不存在。判断条件:如果只有用户截图,没有状态码和日志,只能写“疑似 404”;如果状态码、日志和代码检查一致,才可以写“已确认路由缺失”。这样开发不会把时间浪费在错误方向上。
假设某旧文章页无法访问,可以这样写:
问题:访问 https://example.com/blog/old-post 返回 404。
复现:从首页“旧文章”链接点击进入,每次均复现。
检查:curl -I 返回 HTTP/1.1 404 Not Found。
期望:如果文章已迁移,请 301 到新地址;如果已删除,请确认是否返回 410。
影响:目前只发现这一个 URL,但同目录下可能还有旧链接。
这个例子里,开发能直接看到 URL、状态码、入口和期望结果,也能判断下一步是查路由、查重定向还是查内容迁移记录。注意,301 和 410 的选择取决于业务是否还有替代内容;没有替代内容时,不要为了“看起来正常”而全部跳转到首页。
开发回复“已修复”后,不要只看页面是否能打开。重新执行同一检查项:
下一步,把上面的最小信息清单整理成团队固定的 404 交接模板。下次遇到类似问题时,先填状态码、URL、入口和期望结果,再决定是否升级给开发。