2026年山东大学软件学院创新项目实训博客（三）

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 统一处理。通过这次实现前端登录从展示层能力升级为可联调、可维护、可扩展的基础能力。