Feathers.js 本地认证与 JWT 串联方式

刚开始接触 Feathers.js 时，很多人会先被 service 和 hook 吸引，但真正把项目落地到后台管理系统，很快就会遇到一个更实际的问题: 登录链路到底怎么搭才不乱。

2021 年最常见的组合还是本地用户名密码登录，再配合 JWT 做后续接口认证。Feathers 在这件事上的优势，不是它“认证功能特别多”，而是它把登录、签发 token、恢复用户上下文这几步拆得比较清楚。

LocalStrategy 负责验证，JWTStrategy 负责续航

如果只记一条原则，我会记这一条:

• LocalStrategy 处理“你是谁”
• JWTStrategy 处理“后续请求还认不认你”

前者通常只在登录接口里触发一次，后者则会在用户后续访问其他 service 时反复使用。把这两个职责分开，项目会清爽很多。

登录链路最好保持短而明确

比较稳的一条链路通常是:

1. 前端提交用户名和密码
2. authentication service 走本地策略校验
3. 校验成功后签发 access token
4. 前端把 token 放到后续请求头里
5. 其他 service 通过 JWTStrategy 恢复当前用户

这样一来，业务 service 不需要自己再去解析 token。它们只需要消费已经挂到 params.user 上的用户信息。

不要把认证逻辑散进每个 service

很多 Node.js 项目一开始喜欢在每个接口里手动判断登录态，写着写着就会变成:

• 某些 service 校验了 token
• 某些 service 只校验了 userId
• 某些地方把密码比对写到了业务方法里

Feathers 的好处就是可以把认证前移到 hook 层。业务 service 只保留“文章创建”“分类编辑”“用户绑定角色”这些核心动作，认证留给统一入口处理。

账户模型要为后续扩展预留位置

如果 2021 年准备做管理后台，我通常会在用户表里提前把这些字段准备好:

• 登录名或邮箱
• 密码哈希
• 是否禁用
• 角色或权限标识
• 最后登录时间

这样后面不管接 RBAC、审计日志，还是限制封禁账号，认证层都不用返工太大。

常见踩坑反而都很基础

最容易踩的坑往往不是框架层面，而是工程细节:

• 把明文密码一路传到 service 深处才处理
• 忘了给 JWT 设置合理过期时间
• 前端拿到 token 后没有统一注入请求头
• 认证失败时把内部错误直接返回给调用方

这些问题和 Feathers 无关，但 Feathers 会放大边界是否清晰。一旦链路搭正，后面扩展权限和实时能力就会顺很多。

小结

Feathers.js 的本地认证和 JWT 组合，本质上是在帮我们把“首次登录”和“后续鉴权”拆成两件事。2021 年做中小型后台时，只要把这条边界守住，认证层就已经比很多手写 Express 路由方案稳定不少了。