sql动态拼接条件不安全的核心风险是未过滤的用户输入直接嵌入 SQL，易导致sql 注入；应优先使用预编译参数化查询，结构类参数须白名单校验，必要时双重过滤并禁用多语句执行。
SQL 动态拼接条件本身不安全，核心风险在于 ** 未过滤的用户输入直接嵌入sql 语句**，极易引发 SQL 注入攻击。只要拼接逻辑未严格区分“代码”与“数据”，就存在被绕过验证、执行恶意语句的可能。
常见高危拼接场景
以下写法看似灵活，实则危险：
- 字符串 拼接 + 用户参数：如
"WHERE name = '" + request.getParameter("name") + "'"—— 单引号可被闭合，后续注入任意 SQL - 拼接 ORDER BY 字段名：如
"ORDER BY " + sortField—— 攻击者传入"id; DROP table users--"可能触发多语句执行（取决于驱动） - 拼接表名或列名：这些属于 SQL 结构元素，无法用参数化占位符，但若直接拼入用户输入，风险极高
安全替代方案优先级排序
按安全性与实用性推荐如下：
- 首选预编译参数化查询 ：对red”> 值类条件 （如 WHERE age > ?、IN (?, ?, ?)），全部交由 JDBC/ORM 的 PreparedStatement 处理， 数据库 自动转义
- 白名单校验结构类参数：对必须动态的表名、列名、排序字段，只允许从预定义白名单中选取，例如：
if (!Arrays.asList("name", "age", "create_time").contains(sortField)) throw new IllegalArgumentException(); - 使用成熟表达式引擎 ：如mybatis 的
<if></if>标签、JPA Criteria API、QueryDSL —— 它们在底层已隔离 SQL 结构与数据，避免手写拼接
若必须手动拼接，请守住三条底线
仅在极特殊场景（如复杂报表引擎）下需自行拼接，务必做到：
- 所有值一律参数化 ：拼接时只保留 WHERE、AND、OR 等逻辑关键字和占位符
?，真实值通过setString()等方法绑定 - 结构 标识符 双重过滤：先白名单匹配，再正则校验（如
^[a-zA-Z_][a-zA-Z0-9_]*$），禁止任何特殊字符 - 禁用多语句执行 ：mysql 连接串加
allowMultiQueries=false（默认 false），postgresql 禁用;分隔多语句
不复杂但容易忽略：安全不是“加个过滤函数”就能解决，关键在明确区分“哪里是代码、哪里是数据”，并把控制权交给数据库驱动或框架本身。
