常见的HTTP状态码，你真的懂吗？
做开发的都知道，调接口最怕什么？不是逻辑复杂，而是返回一串看不懂的数字。比如调个登录接口，没成功也不报具体原因，只给你一个401，这时候就得翻文档看错误码说明。
其实大多数问题都出在对标准状态码理解不深。比如200代表请求成功，这大家都知道。但301和302的区别呢？一个是永久重定向，一个是临时跳转。如果前端拿301当临时处理，可能缓存就错了，用户点一次链接后面全乱。
非200系列要特别小心
400是客户端参数有误，常见于漏传字段或格式不对。曾经有个项目，传时间戳用了字符串而不是数字，后台直接甩了个400回来，查了半小时才发现是类型问题。
401是未认证，一般出现在token失效或者压根没带鉴权信息。而403是权限不够，就算你登录了，也可能因为角色限制访问不了某些资源。比如普通用户想删管理员发布的帖子，系统就会拦住。
500是服务器内部错误，属于后端背锅专用码。但有时候其实是前端传了非法数据导致程序异常，这时候不能马上甩锅，得先看看自己有没有传奇怪的东西。
自定义错误码才是重灾区
除了标准HTTP状态码，很多系统还会在返回体里加自己的错误码。比如：
{
"code": 1001,
"msg": "用户不存在",
"data": null
}这种code=1001就是业务层面的定义。不同公司、不同项目的规则不一样，有的从1000开始编号，有的按模块划分区间，比如账户相关用1xxx，订单用2xxx。
问题来了——文档更新不及时。上次遇到一个老接口，文档写code=1001表示“用户名已存在”，实际运行却是“密码太弱”。问后端才知道改过逻辑，但没人同步文档，前端测了半天以为自己拼错了参数。
如何避免被错误码坑
第一，拿到接口先看完整响应示例，别只盯着成功情况。第二，把常见错误码整理成表格贴在工位旁边，或者塞进团队知识库。第三，联调阶段主动构造异常输入，试试少传字段、错类型、超长字符串，看看系统怎么反馈。
有些团队做得更细，会把所有错误码汇总在一个JSON文件里，自动导入到Postman做校验。甚至有人写了个小工具，输入code就能查含义，省得每次翻文档。
安全角度别忽视错误信息泄露
调试时返回详细错误没问题，但上线后得控制输出。曾经有个系统在500错误里直接暴露了数据库查询语句，攻击者一看就知道用了MySQL，还知道表名叫user_info，等于把大门钥匙挂门口。
正确的做法是区分环境。开发环境可以详细报错，生产环境统一返回“系统开小差了，请稍后再试”，日志里再记录真实原因。这样既不影响排查，又不会给黑客递梯子。
另外，敏感操作比如支付、删除，错误提示要模糊些。不能说“余额不足”或“该记录已被删除”，最好统一用“操作失败”这类话术，防止被试探出系统状态。