跳到主要内容

[草稿] 认证、菜单与权限

Nebula 前端 Shell 已经把认证、菜单和权限的主链路串好了。理解这条链路后，业务页面通常只需要关心“我要展示什么”，不需要重复处理“我有没有资格展示”。

登录态是怎么工作的​

apps/shell/src/app.tsx 里已经实现了完整的会话启动和刷新逻辑：

  • 应用启动后先从本地恢复会话
  • 如果已有 token 且满足刷新条件，就自动调用刷新接口
  • 登录成功后预加载菜单、字典、通知等 Shell 运行数据
  • token 即将过期时自动续期，失败则清空会话并跳转 /login

对业务模块来说，这意味着你不应该再自己维护一套 token 生命周期。

菜单是怎么变成页面的​

前端路由不是写死在单个文件里的，而是由两部分共同组成：

  1. 后端返回的菜单数据
  2. 已注册业务模块声明的路由元数据

packages/core 会把菜单和模块注册信息组合成最终可用路由，因此：

  • 后端菜单决定页面是否出现在导航中
  • 业务模块的 PlatformModule 决定某个路径该加载哪个组件

这也是为什么菜单和前端组件 key 要保持一致。

权限怎么判断​

权限能力已经封装在 @platform/core 中：

  • usePermission(code)：返回布尔结果
  • NePermission：做声明式渲染保护
  • auth.hasPermission(code)：从 AppContext 访问权限判断

推荐方式是：

  • 页面级或按钮级显示控制优先使用 NePermission
  • 需要在逻辑中判断时再用 usePermission

前后端协作时要约定什么​

最关键的是三类约定：

  • 登录和刷新接口返回的会话结构要稳定
  • 菜单树里的路径、组件标识、可见性字段要与前端注册信息对齐
  • 按钮权限码要在前端页面里以统一 code 使用

一旦这三类约定稳定下来，前端页面就能随着后端菜单和权限配置动态变化，而不需要频繁改路由骨架。