真正安全的做法是避免字符串拼接，改用参数化查询+条件逻辑分离：用户输入只作参数、不入SQL模板，动态WHERE条件通过启用标记控制生成，字段名与操作符须白名单校验。
动态拼接SQL条件本身不安全，真正安全的做法是避免字符串拼接，改用参数化查询 + 条件逻辑分离。核心原则：用户输入永远不进SQL模板，只作为参数传入。
用参数化 + 构建WHERE子句逻辑
根据业务参数是否存在，动态决定是否加入某个条件，但所有值都走预编译占位符（如 ?、:name、@p1）。
- Java（JDBC）中用 PreparedStatement，调用 setString() 等方法绑定值，不拼SQL
- Python（sqlite3 / psycopg2）用 ? 或 %s 占位，传元组/字典执行，不使用 f-string 或 format 拼接
- Go（database/sql）用 $1, $2 占位符，Query() 或 Exec() 传参，不 fmt.Sprintf
构建可复用的条件组装器
把 WHERE 条件抽象为结构体或对象，每个字段带“是否启用”标记和值，最后统一生成合法SQL片段和参数列表。
- 例如：{ field: "status", op: "=", value: "active", enabled: true } → "status = ?"
- 跳过 enabled=false 的项，不生成对应SQL片段，也不追加参数
- 支持 in、between、like（注意 % 由代码加，不是用户输）等常见操作符
严格过滤字段名与操作符
若需动态列名或操作符（极少数场景，如排序字段、高级筛选），必须白名单校验，禁止直接代入用户输入。
- 允许的排序字段限定为 ["id", "created_at", "name"]，用 map 映射到真实列名
- 操作符只接受 ["=", "!=", ">", "
- 绝对不用 `order by ${userInput}` 或 `"where " + key + " = ?"` 这类写法
用ORM或Query Builder更省心
现代框架（如 MyBatis-Plus、SQLAlchemy、Knex.js、Diesel）已内置安全的动态查询能力，优先选用。
- MyBatis-Plus 的 QueryWrapper：wrapper.eq("status", status).like("name", name) —— 自动跳过 null 值
- SQLAlchemy 的 and_() + 表达式：and_(User.status == status, User.name.ilike(f'%{name}%'))
- 关键：所有方法内部均走参数化，不会拼接用户数据进SQL字符串
