摘要：我以前在项目里整合权限控制模块时，刚好遇到过 HTTP 状态码 401 和 403 的那些坑，真的是一不小心就给自己挖个大洞，权限逻辑一写错，整个接口响应就乱套。所以今天就来聊聊这俩状态码到底咋回事，它们长得像，但用错了真的会让前端和后端互相甩锅。
我以前在项目里整合权限控制模块时，刚好遇到过 HTTP 状态码 401 和 403 的那些坑，真的是一不小心就给自己挖个大洞，权限逻辑一写错，整个接口响应就乱套。所以今天就来聊聊这俩状态码到底咋回事，它们长得像，但用错了真的会让前端和后端互相甩锅。
先说401，这个状态码英文叫 Unauthorized，但说实话，这命名挺迷惑人的。你以为是“没有权限”，但实际上它的意思是“你还没登录，或者登录信息不对”。就像你去饭店吃饭，人家说你得先登记身份证，这就是401。你要是压根没带身份证，或者身份证过期了，人家压根不会让你点菜，更别说吃饭了。
最常见的使用场景是你访问某个接口没带 token，或者带了个过期的 token，比如：
GET /api/user/profileAuthorization: Bearer expired_tokenHTTP/1.1 401 UnauthorizedWWW-Authenticate: Bearer realm="example"注意这个 WWW-Authenticate 响应头，这是协议里的规定，用来告诉客户端该怎么登录、要提供什么认证方式。OAuth 2.0 里就是靠这个头告诉你要传 Bearer Token 的。
换句话说，401 是“你谁啊？我不认识你”。你认证成功后再来，我才让你进去。
而403呢，就更直接了，Forbidden。意思是“你进来了，我知道你是谁，但你没这个权限”。这才是我们通常意义上的“权限不够”。
比如你是一个学生账号，访问了 /api/teacher/course/create 接口，服务端一看你是学生不是老师，就会直接返回403，像这样：
HTTP/1.1 403 Forbidden这里重点是，服务端知道你是谁，而且你也认证成功了，就是不给你这个权限。它根本不想让你继续尝试了，也不会引导你去登录或重新认证。
很多新手一开始搞权限，喜欢只用401，用户没权限直接一律返回401。但这其实是误导。因为用户可能已经登录了，前端看到401会以为用户未登录，跳到登录页，结果用户一脸懵逼：“我不是刚登录过吗？” 就这样体验炸了。
更别说有些安全框架还会自动对401做拦截跳转，那你这个403不写清楚，调试权限问题就像拆盲盒，惊喜连连。
我之前项目里是这么区分这两个状态的：任何“未登录或token非法”的情况，都返回401；而“已登录但权限不足”的，返回403。而且我们在响应体里还会带上详细的错误码和提示信息，比如：
{"code": "NO_PERMISSION","message": "你没有访问该资源的权限"}哦对了，还有一种奇怪的现象，就是有些反爬虫策略喜欢用403来“挡人”，比如你用爬虫刷人家网页，服务器监测到了，就直接403你，意思是“你别再来了我不欢迎你”。这时候你哪怕身份再合法，也别想爬到数据。
再说回代码里实际处理逻辑，我们做 API 开发时，一般在鉴权中间件里统一处理，比如用 Express 写 Node 后端，可以这样做：
function authMiddleware(req, res, next) {const token = req.headers['authorization'];if (!token) {return res.status(401).json({ code: 'UNAUTHORIZED', message: '请先登录' });}const user = verifyToken(token); // 假设有个解析token的方法if (!user) {return res.status(401).json({ code: 'TOKEN_INVALID', message: '登录已过期，请重新登录' });}req.user = user;next;}然后权限判断一般在业务逻辑中做，比如：
app.post('/admin/user/create', authMiddleware, (req, res) => {if (req.user.role !== 'admin') {return res.status(403).json({ code: 'FORBIDDEN', message: '你不是管理员，不能创建用户' });}// 有权限的逻辑...});就这套逻辑，写清楚了前端省不少事，测试同事也好覆盖边界场景。我个人觉得，权限控制逻辑最怕的就是模糊不清，让人不知道到底是没登录，还是权限问题。
有时候，还会遇到一些后端直接把“用户权限不足”也返回成 200，错误写在响应体里。这种做法其实很坑，前端看到 200 以为请求成功了，结果拿着数据处理一堆空对象，用户界面全是空白。这样的后端我基本想锤他。
总之啊，这两个状态码看似差不多，其实语义完全不同。用对了能提升整套系统的清晰度和可维护性，用错了就是一个隐形炸弹，尤其是系统权限多的时候。
对了，你们团队有没有遇到那种权限配置混乱、401和403经常出错的情况？我以前就在一个SaaS项目上看到后端同事每次出错就甩一个401，搞得我们前端天天跟产品扯不清楚，最后还是我提了一个统一的权限状态设计才彻底理顺。你们是怎么处理这类问题的？有没有什么标准化的做法可以借鉴？
来源：不秃头程序员一点号
