摘要

前端项目常见的认证故障，包括登录成功后反复返回登录页、页面刷新导致权限丢失，以及普通用户看见管理员菜单。这些问题往往同时牵涉 Token、用户状态、路由守卫与接口权限。本文将说明如何先让 Codex理清完整认证链路，再实施最小范围修改并进行回归验证。

遇到登录异常时，许多开发者第一反应是要求 Codex直接修改登录页面：

登录后总是跳回登录页，帮我修复。 

然而，故障未必来自登录按钮，更可能发生在登录成功后的状态恢复环节。

常见的认证链路可以整理如下：

提交账号密码
→ 接口返回 Token
→ 保存 Token
→ 获取用户信息
→ 写入状态管理
→ 路由守卫判断权限
→ 加载对应菜单

其中任何环节没有处理完整，都可能引发登录或权限故障。

一、先让 Codex梳理调用链

可以先输入：

请分析当前项目的登录和权限流程，不要修改代码。
重点检查：
1. 登录接口；
2. Token 保存与读取；
3. 用户信息初始化；
4. 路由守卫；
5. 菜单权限；
6. 接口 401 处理；
7. 退出登录流程；
8. 相关测试文件。

应当先确定故障位于哪一层，然后再划定修改范围。

二、重点检查三个高频问题

1. 页面刷新后状态消失

状态管理一般存放于内存，浏览器一旦刷新便会清空。若项目仅保存 Token，却没有再次请求用户信息，路由守卫就可能误判用户尚未登录。

2. 权限判断启动得太早

如果用户信息尚未恢复，路由守卫便开始判断角色，同样可能触发错误跳转。

可为此加入清晰的初始化状态：

type AuthStatus =
  | "idle"
  | "loading"
  | "authenticated"
  | "unauthenticated";

必须等初始化完成以后，才可以开始权限判断。

3. 把前端隐藏菜单当作权限控制

管理员按钮在前端不可见，并不等于接口已经安全；真正的权限校验必须放在后端执行。

Codex能够协助整理前端展示规则，却不能用修改菜单配置的办法替代后端鉴权。

三、对修改边界作出严格限制

登录与权限均属高风险模块，因此建议明确规定限制：

允许修改：
- src/stores/user.ts
- src/router/guard.ts
- tests/auth
禁止修改：
- 后端权限规则；
- Token 签名逻辑；
- 数据库用户角色；
- package.json；
- 其他业务模块。

若故障仅仅是刷新后没有恢复用户状态，就不应顺带重构整个权限系统。

四、回归测试不可缺少

至少需要覆盖：

• 成功登录后进入首页；
• 刷新页面后仍保持登录；
• Token 失效后跳转至登录页；
• 普通用户不能访问管理页面；
• 管理员菜单能够正常显示；
• 退出以后清除本地状态；
• 用户信息接口失败时，不允许继续进入系统。

完成修改以后运行：

npm run type-check
npm run test
npm run build

最后检查 Git Diff，确认没有删除权限判断或降低测试标准。

五、哪些情况下应考虑升级 Pro？

如果只是偶尔排查一次登录故障，现有方案一般足以应对。

如果每天都需要 Codex完成以下工作：

• 读取前端与后端的认证代码；
• 梳理多个权限模块；
• 持续修改并执行测试；
• 分析大量接口日志；
• 并行维护多个项目；
• 多次核查安全风险；

这表明 Codex已经进入持续性的工程开发流程。

此时首先应利用任务拆分和 AGENTS.md 范围控制来改善流程。若工作流已经完成优化，但长上下文分析、测试及多文件修改依然频繁中断，可以再次评估 Plus、Credits 和 Pro。对长期高频开发者而言，Pro更有利于维持任务连续性，并减少反复恢复上下文所消耗的时间。

总结

让 Codex处理登录权限故障时，排查重点不能局限于登录页面。

更可靠的处理流程是：

先梳理认证链路，再定位失败阶段；先限制修改范围，再补充测试；最后检查 Git Diff 和真实权限结果。

登录和权限模块直接影响账户及数据安全。AI能够协助开发者定位故障，但最终规则仍应由开发者与后端共同核实确认。