SQL前端筛选SQL构建方案_SQL后端动态适配过滤

前端应传结构化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 行为映射起来。例如：

立即学习“前端免费学习笔记（深入）”；

星声AI

可分享的AI播客内容生成器和效率工具

185

查看详情

• 声明每个合法字段支持哪些操作符（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 的体力活了。