Feathers.js 查询白名单为什么值得先做

Feathers.js 的一个优点是接口很轻，find 方法配上 params.query 就能做出非常灵活的列表查询。但灵活也意味着风险，如果没有白名单，列表接口最后会变成“只要能拼出来就都能查”。

这种问题在项目刚起步时不明显，到了表越来越大、字段越来越多、前端筛选越来越复杂的时候，风险会一下暴露出来。

白名单首先解决的是可控性

我通常会先列出这个 service 真正允许前端控制的字段，比如:

• status
• keyword
• categoryId
• createdAt 区间
• 排序字段中的有限几个

只有这些字段才会被转换成真正的数据库条件。其余内容一律忽略或报错。

安全问题往往不是“被攻击”，而是被滥用

很多团队一提安全，就只想到恶意攻击。但后台查询白名单更常见的价值，其实是防止正常开发过程中的误用。

前端临时加了一个筛选字段，后端没审过，直接透进 ORM；后来数据库索引没跟上，列表就开始慢。看起来不是安全事故，本质上仍然是入口失控。

排序字段尤其要管住

筛选条件失控已经很麻烦了，排序字段失控更容易把数据库拖慢。因为排序一旦落到没有索引的列上，大表场景下马上就会有明显影响。

所以排序最适合做成枚举映射，而不是让前端传任意列名。

白名单并不妨碍扩展

有人担心加了白名单会让接口不灵活。其实真正的灵活，不是所有字段都开放，而是你可以明确地增加一个字段，并同步补齐:

• 查询参数定义
• 数据库索引评估
• 前端筛选控件
• 测试用例

这样新增筛选能力会慢一点，但可维护性高很多。

小结

Feathers.js 的查询白名单，本质上是在告诉团队: 哪些字段是稳定契约，哪些不是。2021 年做中后台时，这一步越早做，后面越不容易被看似无害的查询参数拖进混乱。