Feathers before/after Hook 各自该放什么

很多人喜欢 Feathers.js，往往就是因为 Hook 用起来很顺。但到了 2021 年，团队一旦把它大量用于后台服务，很快就会遇到一个副作用：before、after、error 三类 Hook 什么都能写，于是什么都开始往里面塞。

这时候比“会不会用 Hook”更重要的，是 Hook 边界感。

before 更适合做输入收口和查询改写

像参数清洗、权限注入、查询条件补充、默认分页设置，这类动作发生在 service 真正执行前，放在 before 里最自然。它回答的是“请求进入业务前，需要先被整理成什么样”。

如果 before 已经开始拼装返回结构，通常说明边界开始混了。

after 更适合做输出裁剪和附加信息

有些后台接口需要给返回结果补一个展示字段，或者把某些内部字段剔除掉，这种动作放在 after 更顺。因为到这一步，业务已经执行完，结果形态也确定了。

把这层处理集中起来，比在每个 service 方法里手改返回值整洁得多。

别把核心业务决策全放进 Hook 链

Hook 适合横切逻辑，但不适合替代 service 的核心决策。如果“是否允许发布文章”“发布后要更新哪些表”这些关键流程全埋在 Hook 链里，阅读者会很难判断真正的业务入口在哪里。

好用的机制，最怕被用成隐形业务层。

Sequelize 相关转换也要注意位置

比如把查询参数映射成 include、order、where，这些属于 service 执行前的准备动作；而把 Sequelize 实体转成更适合前端的输出对象，通常更接近执行后的处理。

顺着这个时间线理解 before 和 after，会比死记术语更实用。

小结

Feathers Hook 边界清楚之后，后台代码会明显顺很多。before 负责收口输入，after 负责整理输出，核心业务则留在 service 内部，这样最不容易失控。