这是背单词小程序「优词记 Pro」技术复盘的收尾篇。前六篇聊了架构、路由、代码生成、SQL 重构和构建踩坑，今天讲后台管理里最容易写脏的两个横切关注点——权限控制和操作日志——以及怎么用注解把它们变成「加一行声明」的事。

问题：权限逻辑怎么放都别扭

管理后台有几十个接口，每个接口的权限要求不一样。早期的写法是在方法开头手写判断：先取当前用户，再查角色、查权限表、比对标识……三个接口下来代码就开始复制粘贴，而且很容易漏——新加一个接口忘记写校验，它就对所有登录用户敞开了。

权限校验的本质是「这个方法要求调用者具备什么」，而「方法的要求」恰恰是注解最擅长表达的：它贴着方法声明，一目了然，还能被统一调度器集中执行。

三个注解，覆盖全部场景

整个后台的权限体系收敛成三个注解：

#[NoNeedLogin]                          // 免登录（如登录接口本身）
#[Permission(['course-index-add'])]     // 要求权限标识
#[OperationLog('新增课程', Course::class, ACTION, [Course::class])]

默认安全是这套设计的地基：Dispatcher 默认要求所有接口登录，想开放才显式声明 #[NoNeedLogin]。这从机制上消灭了「忘了加校验」这类漏洞——安全是默认值，而不是可选项。

权限标识对应 config/autoload/admin_permissions.php 里配置的权限树。标识在注解里写短名（如 course-index-add），运行时自动拼接应用前缀成为全局唯一 key（app-course-index-add），权限树和接口声明各自维护、靠约定对齐。权限树的 key 也有强制命名规范：模块主资源的子级统一用 index 占位（course > index > add），子资源用自身名字（course > unit > add），杜绝了 course-course 这种嵌套冗余。

操作日志则把审计也收进了注解：描述、操作对象模型、动作类型、关联模型全部声明在注解里，由调度器在方法执行成功后自动落库。业务方法里没有任何日志代码，也不会出现「忘了记日志」的接口。

工程上的收益

• 新增接口默认安全，权限是声明式的，review 时扫一眼注解就能确认覆盖面

• 审计无死角：操作日志由调度器统一触发，不依赖开发者自觉

• 横切逻辑收敛：控制器方法里只有业务参数处理，权限和日志的复杂度都在调度层

适用边界

这套方案的前提是「接口路径与权限标识一一对应」的约定能被团队守住，一旦出现「一个方法被两个不同权限入口复用」的场景就会露怯——好在我们的后台没出现这种情况。权限体系复杂到需要数据驱动（比如运行时动态组装权限规则）时，注解这种静态声明方式也会到顶，届时要换的就不是注解，而是整个鉴权架构。

——
到这里，这个系列就告一段落了。七篇下来从架构决策到具体踩坑都聊了一遍，如果你只记住一句话，我希望是：把约定固化到机制里，而不是人的自觉里。产品本体是个背单词小程序，微信搜「优词记 Pro」可以直接体验，也欢迎在评论区提出你感兴趣的下一篇主题——比如 AI 发音评测、记忆曲线复习推荐，或者接口性能的实测数据，我挑高赞的写。