2026年山东大学软件学院创新项目实训博客（三）
一、工作进展
本阶段我负责的前端工作重点从页面骨架切换到登录能力落地，核心目标是把“能看到登录页”推进到“登录链路稳定可联调”。
本次工作围绕登录实现拆成四个模块：
- 登录表单与提交流程：完成输入校验、提交状态、错误提示与成功跳转。
- 登录态存储模块：用全局
auth-store管理 token 与用户信息，统一登录态来源。 - 路由守卫与会话恢复模块：刷新后恢复会话，未登录拦截受保护页面。
- 鉴权请求模块：统一注入
Authorization，处理 401 失效场景。
除了功能实现，我还做了一次登录链路回归：
“首次登录 -> 刷新页面 -> 切换路由 -> 退出登录 -> 再次访问受保护页”。
通过这次回归，登录相关的状态切换和页面跳转已经形成完整闭环。
二、详细内容
1. 登录表单与提交流程
登录页这一阶段不只关注样式，重点是交互行为一致性。实现上我把登录交互分成三段：
- 输入段：用户名、密码的基础必填与格式校验。
- 提交段：提交中禁用重复点击，避免并发登录请求。
- 结果段：成功后落库并跳转，失败后保留输入并提示错误原因。
这样设计的原因是：登录属于高频入口，用户对“按钮点了是否生效”非常敏感。若没有提交态和错误态，体验会直接退化成“点了没反应”。
表单层我坚持“只处理交互，不处理持久化”。也就是登录页只负责采集和触发，不直接写本地存储。这样可以保证登录规则变更时，不需要同时改页面和状态层。
2. 登录态存储（auth-store）
我把登录状态收敛到auth-store，统一维护以下信息：
isAuthenticated：当前是否已登录。token：后续请求鉴权所需凭证。user：页面展示所需的基础用户信息。
对应操作也集中在 store 层：
setAuthSession：登录成功后写入 token 与用户信息。restoreAuthSession：应用启动时从本地恢复会话。clearAuthSession：退出登录时清空状态与本地缓存。
这种集中管理的好处是，页面不再各自维护“是否登录”。
登录页、头部用户信息、路由守卫都从同一状态源读取，状态不会出现分叉。
3. 路由守卫与会话恢复
登录是否稳定，关键不在登录瞬间，而在刷新和路由切换后的行为。
本阶段我把这部分实现成“启动恢复 + 守卫拦截”两层：
- 启动恢复：应用初始化时先执行
restoreAuthSession，避免页面先当作未登录再闪跳。 - 守卫拦截：访问受保护路由时检查登录态，未登录统一重定向到登录页。
为了减少误跳转，我在守卫中区分了公开路由和受保护路由：
- 公开路由（如登录页）不触发强制拦截。
- 受保护路由必须通过登录检查。
这套策略解决了一个常见问题：
之前在网络慢或初始化晚的情况下会出现首屏闪烁（先跳登录，再跳回业务页）。现在恢复时机前置后，这种抖动明显减少。
4. 鉴权请求模块（Authorization 注入）
为了保证登录态能真正用于业务请求，我把鉴权逻辑统一放在 API 客户端层：
- 发请求前读取
auth-store中的 token。 - 自动拼接
Authorization: Bearer <token>。 - 遇到 401 时统一触发登录失效处理。
这样页面层可以完全不关心 token 细节，只消费业务数据。
我还补了两个稳定性细节：
- 请求取消：页面卸载时取消未完成请求，避免旧请求回写新页面。
- 错误归一：把网络错误和业务错误统一成可展示结构，减少页面分支判断。
这一步做完后，登录不再是“只对登录页生效”，而是贯穿到整个请求链路。
5. 登录联调中的问题与处理
本阶段登录联调遇到的典型问题有三个：
- token 恢复时机偏晚导致首屏闪烁。
- 快速切页时旧请求回写导致状态错位。
- 401 处理分散在页面，提示风格不一致。
对应处理方式：
- 把会话恢复提前到应用初始化阶段。
- 在请求层统一增加取消与落地保护。
- 把 401 失效处理收敛到客户端层，而不是页面层临时处理。
这些改动看起来分散，但共同目标一致：登录能力要“可持续工作”，而不是“只在演示路径可用”。
6. 本阶段工程经验
这一篇我最核心的经验是：登录实现必须按链路拆解，而不是按页面拆解。
我在实现中坚持三条约束：
- 页面只处理交互，不直接持久化登录数据。
- 登录态只允许一个全局来源（auth-store）。
- 鉴权逻辑统一放在请求层，不下放到业务页面。
这三条约束让登录相关问题更容易定位：
是表单问题、状态问题、守卫问题还是请求问题，可以快速分层排查。
三、总结
本篇工作的核心是“登录实现闭环”，不是单点页面优化。
本阶段已完成结果：
- 登录表单、提交状态、错误提示、成功跳转流程完整可用。
auth-store统一托管 token 与用户信息，登录态来源一致。- 路由守卫与会话恢复联动，刷新与切页场景稳定。
- API 客户端完成鉴权头注入与 401 统一处理。
通过这次实现，前端登录从展示层能力升级为可联调、可维护、可扩展的基础能力。
