前端应传结构化JSON过滤协议，后端通过规则驱动映射为参数化SQL片段；需强制字段白名单、操作符枚举、值校验及预编译绑定，确保安全可扩展。
前端筛选条件最终要转成后端可执行的 SQL WHERE 子句，关键不在“怎么拼字符串”，而在于“安全、可维护、能扩展地桥接前后端语义”。核心思路是：前端传结构化过滤描述，后端按规则映射为参数化 SQL 片段。
前端传什么：定义清晰的过滤协议
避免直接传 raw SQL 或字段名+值对。推荐用轻量 JSON 描述意图，例如：
- 字段名（限定白名单，如 user_name、created_at、status）
- 操作符（如 eq、like、gt、in、between）
- 值（单值或数组，不参与 SQL 拼接，只作参数绑定）
示例请求体：
{
"filters": [
{"field": "status", "op": "eq", "value": "active"},
{"field": "created_at", "op": "between", "value": ["2024-01-01", "2024-06-30"]},
{"field": "user_name", "op": "like", "value": "%admin%"}
]
}
后端怎么做：规则驱动的 SQL 片段生成
不硬编码 if-else，而是用配置或策略模式将字段→SQL 行为映射起来。例如：
立即学习“前端免费学习笔记（深入）”；
- 声明每个合法字段支持哪些操作符（status 允许 eq/in，但不允许 like）
- 为每个操作符预设 SQL 模板：eq → ?，like → LIKE ?，between → BETWEEN ? AND ?
- 自动处理类型转换（如日期字段把字符串转为 Date 对象再绑定）
生成结果不是完整 SQL，而是带占位符的 WHERE clause snippet + params list，再安全注入主查询。
防坑要点：边界与安全必须前置考虑
这不是功能问题，是上线前提：
- 字段白名单强制校验 —— 后端绝不信任前端传来的 field 名，未注册字段直接 400
- 操作符严格枚举 —— 禁止传 raw、sql、func 类自定义 op
- 值长度/格式限制 —— 如 like 值超 50 字符截断，in 数组最多 100 项，防 DoS 和慢查询
- 一律使用预编译参数绑定 —— 片段拼完后，所有值只进 PreparedStatement#setXxx()，绝不字符串插值
延伸建议：支持组合与复用
真实业务常需“保存筛选方案”或“多表联动筛选”。可在协议中增加：
- group 字段支持嵌套逻辑（如 and/or 分组）
- alias 支持多表字段消歧义（如 u.name、o.status）
- 后端提供“过滤模板管理”接口，供前端存取常用条件集
基本上就这些。不复杂但容易忽略的是：协议设计要收口、校验要狠、扩展要留钩子——剩下的就是把 JSON 映射成安全 SQL 的体力活了。
