Feathers.js 用 Hook 做访问控制的稳妥方式

很多后台项目在权限设计上都会经历一个阶段: 一开始觉得只要登录就够了，后来页面越来越多、角色越来越多，接口权限判断开始四处散落。

Feathers.js 的 Hook 机制在这里特别顺手，因为它天然适合在业务动作前插入一层统一的访问控制。

先决定权限是“角色型”还是“资源型”

如果只是简单后台，角色型权限就够用，比如管理员、编辑、访客。判断规则也比较直观。

但如果已经进入多团队协作、租户隔离或者“本人只能修改自己的内容”这类场景，就会逐渐走向资源型权限。也就是除了看角色，还得看这条数据是不是你能操作的对象。

Hook 适合做第一道门槛

我比较认可的方式是:

• before hook 先判断用户是否登录
• 再判断角色或资源范围是否允许访问
• 通过之后才进入 service 执行真实业务

这样可以保证未授权请求根本进不到核心逻辑里，service 也不用到处重复“你有没有权限”。

权限判断要尽量靠近业务语义

一个常见误区是只按 URL 做权限。比如 /posts 可以访问、/users 不可以访问。表面上简单，但一旦同一个 service 里既有公开查询，又有管理操作，这种规则马上会失真。

更稳的做法是围绕动作来写: 谁能查询、谁能创建、谁能审核、谁能删除。Hook 的粒度刚好可以落在这些 method 上。

复杂规则别全塞到一个 Hook 里

访问控制虽然适合进 Hook，但不代表所有权限判断都要写成一个巨大的函数。真正长期维护时，我更建议:

• 登录校验一个 hook
• 角色判断一个 hook
• 资源范围判断一个 hook

拆开以后，请求链路更容易读，也更容易定位是哪一层挡住了请求。

小结

Feathers.js 的 Hook 很适合做访问控制，不是因为它“够灵活”，而是因为它让认证、角色判断、资源判断都能在进入业务前被统一收口。权限规则一旦入口一致，后面的维护成本会低很多。