SQL动态拼接条件不安全的核心风险是未过滤的用户输入直接嵌入SQL，易导致SQL注入；应优先使用预编译参数化查询，结构类参数须白名单校验，必要时双重过滤并禁用多语句执行。

SQL动态拼接条件本身不安全，核心风险在于**未过滤的用户输入直接嵌入SQL语句**，极易引发SQL注入攻击。只要拼接逻辑未严格区分“代码”与“数据”，就存在被绕过验证、执行恶意语句的可能。

常见高危拼接场景

以下写法看似灵活，实则危险：

• 字符串拼接+用户参数：如 "WHERE name = '" + request.getParameter("name") + "'" —— 单引号可被闭合，后续注入任意SQL
• 拼接ORDER BY字段名：如 "ORDER BY " + sortField —— 攻击者传入 "id; DROP TABLE users--" 可能触发多语句执行（取决于驱动）
• 拼接表名或列名：这些属于SQL结构元素，无法用参数化占位符，但若直接拼入用户输入，风险极高

安全替代方案优先级排序

按安全性与实用性推荐如下：

• 首选预编译参数化查询：对值类条件（如WHERE age > ?、IN (?, ?, ?)），全部交由JDBC/ORM的PreparedStatement处理，数据库自动转义
• 白名单校验结构类参数：对必须动态的表名、列名、排序字段，只允许从预定义白名单中选取，例如：if (!Arrays.asList("name", "age", "create_time").contains(sortField)) throw new IllegalArgumentException();
• 使用成熟表达式引擎：如MyBatis的标签、JPA Criteria API、QueryDSL —— 它们在底层已隔离SQL结构与数据，避免手写拼接

若必须手动拼接，请守住三条底线

仅在极特殊场景（如复杂报表引擎）下需自行拼接，务必做到：

• 所有值一律参数化：拼接时只保留WHERE、AND、OR等逻辑关键字和占位符?，真实值通过setString()等方法绑定
• 结构标识符双重过滤：先白名单匹配，再正则校验（如^[a-zA-Z_][a-zA-Z0-9_]*$），禁止任何特殊字符
• 禁用多语句执行：MySQL连接串加allowMultiQueries=false（默认false），PostgreSQL禁用;分隔多语句

不复杂但容易忽略：安全不是“加个过滤函数”就能解决，关键在明确区分“哪里是代码、哪里是数据”，并把控制权交给数据库驱动或框架本身。