React 管理端认证与请求拦截：源码观察和修复边界

本文根据个人管理端项目的默认分支做只读源码复核，重点观察 React Router、Axios 请求层和资源 API 模块之间的认证边界。文章不展示仓库名、接口路径、域名、私有依赖或认证值；没有构建该项目、登录系统、读取环境文件或访问生产服务。以下“风险”是部署条件下的源码推断，不代表已复现线上故障。本次源码快照复核日期为 2026-10-20。

源码观察

• 路由入口使用 BrowserRouter、basename 和受保护路由，说明应用考虑了子路径部署与路由访问控制。
• 共享 Axios 客户端设置 15 秒超时，从构建时环境读取 API 基址，并在未提供时退回相对地址；响应拦截器直接返回 response.data。
• 请求拦截器从 localStorage 读取 bearer token 并写入 Authorization。这让刷新后恢复登录更直接，但同源脚本一旦遭遇 XSS，持久化 token 可能被读取；这是一种存储威胁模型，不等同于发现了可利用的 XSS。
• 响应拦截器用 URL 子串判断某类认证请求是否跳过失效处理；其余 401 会删除本地 token，并用根绝对地址跳转到登录页。因为路由另有 basename，若部署基址不是站点根路径，这两处路径语义可能不一致。需要在实际构建基址下验证，不能只凭源码断言当前部署已坏。
• 403 与其他错误走通用消息提示，不会按 401 逻辑清除 token。这样可避免把“已登录但无权限”误判为“需要重新登录”，但管理员可读的错误文案仍应区分权限拒绝、会话失效和服务端异常。
• 本次快照中，API 按业务资源拆成多个客户端对象，覆盖列表、详情、增删改、状态和库存等操作；不少请求体使用宽泛的 Record<string, unknown>。这便于快速接入，但会把字段拼写、可空性和状态枚举错误推迟到运行时。

这些观察只覆盖请求层与路由/API 模块的静态结构；没有读取部署变量来确认实际 basename，也没有检查后端 token 生命周期、Cookie 策略或服务端授权。因此这里只能说明路径耦合和存储选择的条件性风险，不能得出当前线上认证失效或权限绕过的结论。

使用明确的认证状态

把“正在恢复会话”“未登录”“已登录”表示为互斥状态，避免用多个布尔值拼出互相矛盾的组合：

type AuthState =
  | { status: 'checking' }
  | { status: 'anonymous' }
  | { status: 'authenticated'; user: User };

启动时若存在持久化会话线索，应先向服务端确认会话有效，再渲染管理区域。只有 authenticated 且用户资料完整时，路由守卫才显示受保护页面；解析失败、字段缺失或服务端拒绝时都回到 anonymous，不要把损坏状态当成已登录。

角色守卫可以改善导航体验，但不能取代 API 权限检查。浏览器里的 store、路由状态和按钮可被用户修改；每项管理操作最终都必须由服务端再次验证身份和权限。服务端授权模式见API 权限设计指南。

让部署路径只有一个来源

应用如果部署在 /admin/ 等子路径，登录页地址、资源 base、路由 basename 和会话失效跳转必须遵循同一部署配置。不要让请求拦截器硬编码站点根路径。针对上面的观察，应优先让路由器负责导航：请求层发出“会话失效”信号，应用壳层清理状态并通过 navigate 跳转；若必须由浏览器整页导航，则从已验证的部署基址安全拼出目标地址，并测试根路径、子路径和尾斜杠情况。

推荐由请求层发出“会话失效”信号，由应用层统一清理认证状态并使用路由导航：

// request client
if (response.status === 401 && !isLoginRequest(config)) {
  window.dispatchEvent(new Event('auth:expired'));
}

// application shell
useEffect(() => {
  const expireSession = () => {
    authStore.getState().clearSession();
    navigate('/login', { replace: true });
  };

  window.addEventListener('auth:expired', expireSession);
  return () => window.removeEventListener('auth:expired', expireSession);
}, [navigate]);

这里的 navigate('/login') 应由已配置 basename 的路由器解析。请求层只负责识别失效，不直接拼接浏览器绝对地址；如果项目采用多标签页，还要同步通知其他标签清理同一账号的状态。

一次性清理会话

401 发生时，统一处理令牌、用户资料、私有缓存和正在进行的用户请求，然后替换到登录页。只删除 token 却保留 store 中的用户信息，会让界面短暂或持续呈现已登录状态。清理逻辑应可重复调用，并避免并发 401 导致多个弹窗或跳转。

如果使用 localStorage 保存 bearer token，同源脚本注入可能读取该令牌；可评估使用 HttpOnly、Secure、SameSite Cookie，并同步设计 CSRF 防护。迁移前要核对现有客户端、反向代理、CORS 和跨站登录流程，不能只改前端存储位置。API 客户端也应逐步使用明确的请求 DTO、响应类型和状态枚举；只有当资源行为确实一致时才抽共享 CRUD 帮助，避免把不同业务约束塞进一个过度通用的接口。

需要覆盖的测试

1. 在根路径与配置的子路径下直接打开登录页、刷新深层链接、处理未知路由。
2. 未登录访问受保护页面时重定向到路由器管理的登录页，不拼错站点根路径。
3. checking 状态完成前不短暂渲染管理内容；损坏或缺少用户资料的状态必须失败关闭。
4. API 返回 401 时清空内存、持久化用户状态和私有缓存，只触发一次恢复导航。
5. 403 不应伪装成登录过期；应显示无权限反馈并保留可理解的页面状态。
6. 普通用户和管理员的 API 权限分别在服务端验证，前端守卫不能作为测试替代品。
7. 会话过期期间发起的并行请求应共享同一次恢复流程，避免重复重试写操作。

将请求层、认证状态和路由导航用一组明确契约连起来，通常比让每一层各自删除 token、写 window.location 更容易测试和维护。本文只记录经脱敏的源码形态及条件性风险，没有暴露项目接口或内部依赖，也没有把静态推断写成已发生的线上问题；文章地址保持不变。