权限错误需提前识别、明确区分、精准响应，应检查response.status或响应体中的code字段，而非仅依赖try/catch；推荐封装语义化fetch工具统一处理401/403等场景。

在 async 函数中处理权限错误，关键不是“捕获所有错误”，而是**提前识别、明确区分、精准响应**——权限错误（如 403 Forbidden、401 Unauthorized）通常属于业务层面的预期异常，而非网络中断或解析失败这类意外错误。

判断权限错误的来源

权限问题一般出现在 HTTP 响应阶段，而不是请求发送失败时。因此不能只靠 try/catch 捕获网络层异常，更要检查 response.status 和 response.headers：

• HTTP 状态码为 401（未认证）或 403（禁止访问）是典型权限信号
• 部分 API 会返回 200 状态但 body 中含 { "code": 403, "message": "无操作权限" } ——需解析响应体
• Token 过期、角色缺失、资源归属校验失败等，都可能触发这类响应

在 await 后主动校验响应

避免把权限错误当作“异常”吞掉或误报为系统错误。推荐在 fetch 后立即做语义化判断：

async function fetchUserProfile() {
  const res = await fetch('/api/profile', {
    headers: { 'Authorization': `Bearer ${token}` }
  });

  // 主动检查权限状态
  if (res.status === 401) {
    throw new Error('AUTH_REQUIRED'); // 可用于跳转登录页
  }
  if (res.status === 403) {
    throw new Error('PERMISSION_DENIED'); // 可用于显示无权提示
  }
  if (!res.ok) {
    throw new Error(`HTTP ${res.status}: ${res.statusText}`);
  }

  return res.json();
}

统一处理权限错误的调用层

不要每个接口都重复写 status 判断。可封装一个带权限语义的 fetch 工具函数：

• 返回标准化错误类型（如 AuthError、ForbiddenError），便于上层 switch 分支处理
• 自动刷新 token 后重试 401（需配合 auth store 或 refresh logic）
• 对 403 返回 { type: 'forbidden', action: 'contact-admin' } 等携带引导信息的对象

避免常见陷阱

权限错误容易被错误归类，导致体验断裂：

• ❌ 不要仅靠 try/catch 捕获，就认为“有错即失败”——403 是有效响应，不是 rejected Promise
• ❌ 不要在 .catch() 里统一弹“请求失败”，而应根据 error 类型显示“请先登录”或“您暂无此操作权限”
• ❌ 不要忽略 CORS 或预检失败（OPTIONS 403）——这属于跨域配置问题，非用户权限问题