Feathers.js 里的 params 什么时候该内部传递

Feathers.js 用久了以后，params 会变成一个既好用又危险的对象。好用在于请求上下文、当前用户、provider、query 都能顺手带进 service；危险在于它太方便了，方便到什么都想往里放。

如果这个边界不收住，后面 service 之间互相调用时，就很容易把原始请求上下文一路传得到处都是。

先分清楚外部调用和内部调用

外部调用通常来自 HTTP 或 Socket，请求里会带着用户、provider、headers 这些上下文。内部调用则更像业务流程的一部分，比如文章发布后顺手写一条审计日志，或者同步更新分类计数。

这两类调用的关注点完全不同，不应该用同一份 params 生搬硬套。

provider 是个很有用的分界线

我很喜欢用 params.provider 来判断调用来源。因为它能提醒我们: 现在这次调用到底来自真实客户端，还是来自服务内部协作。

一旦是内部调用，很多外部输入相关的假设都不成立了。比如 query 可能不是用户传的，headers 也不应该被业务层继续依赖。

内部调用最好显式挑选上下文

比较稳的做法不是把整个 params 透传，而是只带上真正需要的内容，比如:

• 当前操作用户的 id
• traceId 或 requestId
• 某个内部标志位

这样 service 的依赖更明确，也不容易让后续 hook 因为拿到一堆意外字段而出现分支混乱。

params 里塞太多东西会让测试变差

一旦 service 过度依赖完整 params，写单测时就得构造一大坨上下文，稍不留神就漏字段。反过来，如果 service 只依赖少数明确字段，测试就会简单很多。

这也是我越来越倾向于把 params 当作“边界信息载体”，而不是“万能数据袋”的原因。

小结

Feathers.js 的 params 很强，但真正让项目长期稳定的，不是传得越多越好，而是知道哪些上下文属于外部请求，哪些属于内部流程。把这条边界站稳，service 协作会轻很多。