http status code 404 使用陷阱

背景

最近遇到一个问题，业务逻辑里面需要检查资源是否存在。一般来说，如果返回码是 404， 就可以认为资源不存在，然后做出一些动作
但是，这个 404 不一定能反映真实情况

依赖链路

由于我们的 API 服务一般会部署在各种负载均衡或者网关之后，传输链路可能是这样的

由于依赖链路过长，只要有一个环节异常，Cloudflare 与 Gateway 其实都有可能存在改写 status code 的情况。
最常见的就是 404， 有可能是 Cloudflare 没有找到网关，也有可能是网关没有找到服务。 而这个时候，你的服务可能是正常的，有可能是机房网络异常，或者一些不恰当的运维变更导致链路中断。

优化点

如果服务本身的 payload 是有一定特征的，比如返回的格式是 json, 里面有具体的响应码，这个时候就可以解析这个返回码，用于判断资源是否存在，可靠性比单纯使用一个 404 返回码来判断要高。