Feathers + Sequelize 登录鉴权与 Hook 顺序

Feathers.js 到了 2021 年已经很适合做内部后台，但真正把它和 Sequelize 组合起来后，团队最容易踩坑的地方之一，就是 Hook 顺序。认证、挂载用户、权限判断、审计记录，这些动作单独看都不复杂，连起来就很考验边界。

顺序一旦乱掉，问题往往不是直接报错，而是偶发地查不到用户、权限判断失效，或者日志信息不完整。

先认证，再谈角色和数据范围

这是最基本的一条。authenticate('jwt') 这种动作应该尽量靠前，让后续 Hook 都面对一个已经确认过身份的上下文。

如果角色判断、租户过滤写在认证之前，代码里就会充满各种空值分支。

挂载当前用户信息要保持单一出口

后台接口经常需要知道“是谁在操作”。如果每个 service 都自己去数据库查当前用户一次，不但重复，还容易产生字段不一致的问题。

更稳的做法是认证后统一把必要的当前用户信息收进 params 或明确的上下文字段里，后续 Hook 直接消费。

业务校验 Hook 不要和权限 Hook 混写

比如“当前角色能不能创建文章”和“文章标题是否重复”是两类问题。把它们塞在同一个 Hook 里，后面阅读和复用都会变差。

Feathers 的 Hook 机制很好用，但越是顺手，越要克制每个 Hook 的职责。

Sequelize 查询范围也最好从 Hook 边界注入

内容后台常见的数据范围控制，比如“编辑只能看到自己创建的稿件”，很适合在查询前统一补条件，而不是每个 service 方法都手写一遍 where.createdBy = user.id。

只要这个边界稳定下来，后续 service 会轻很多。

小结

Feathers + Sequelize 组合里，Hook 顺序本质上就是后台安全边界的执行顺序。先认证，再挂上下文，再做权限和业务校验，这样的链路最稳，也最容易维护。