后台角色与权限在 Feathers 里怎么分层

后台系统一开始往往只有“管理员能不能进”这种粗粒度控制，但到 2021 年多数内部平台都已经会继续长出编辑、审核、运营、只读查看这类角色。权限体系复杂度一起来，最容易乱掉的就是概念边界。

角色、权限码和数据范围看上去都在做访问控制，其实并不是同一层东西。

角色更适合表达岗位身份

编辑、审核员、运营管理员，这些概念本质上是岗位归类。角色的价值，是让系统先知道“这个人属于哪类操作群体”，而不是精确回答每个按钮能不能点。

如果把所有细节都直接写死在角色名上，角色数量很快就会膨胀。

权限码负责表达具体动作

像 post:create、post:publish、user:invite 这类更适合做成权限码。它们能被角色组合，也更适合和菜单、接口、按钮这些具体动作一一对应。

这样一来，角色和权限之间就是组合关系，而不是彼此替代。

数据范围要单独看待

“能不能编辑文章”和“能编辑哪些文章”不是一回事。前者更像动作权限，后者更像数据范围控制。把这两层混在一起，会让 Hook 和查询条件越来越难维护。

在 Feathers 里，我更愿意把数据范围控制收进查询边界，而不是只做一个布尔判断。

后台权限最好同时服务菜单和接口

有些团队只做菜单显隐，不做接口校验；也有些只守接口，不维护前端权限表达。更稳的方式是让两边都依赖同一套权限语义，只是作用位置不同。

菜单负责体验层，接口负责安全层，两者不能互相替代。

小结

后台权限分层的关键，是把角色、权限码和数据范围拆开理解。只要这三个概念不混，Feathers 里的 Hook、菜单和 service 查询都会更容易维护。