推荐用条件集合+String.join构建WHERE子句，避免WHERE 1=1；需校验参数有效性并使用预编译占位符防注入，优先采用MyBatis、QueryWrapper等声明式动态SQL方案。
直接用 WHERE 1=1 开头再拼接条件，是动态 SQL 中常见但需谨慎的做法。它本身不解决参数安全或逻辑完整性问题，关键在于如何在 for 循环中**安全、清晰、可维护地追加非空/有效条件**，同时避免 SQL 注入和语法错误。
用 for 循环遍历参数 Map 或 List，只拼接有效条件
不要无差别拼接所有字段，而是先判断值是否“有意义”（如非 null、非空字符串、非默认值），再追加对应 WHERE 子句：
- Java 示例（MyBatis XML 中不推荐写 for，应改用
<if></if>；此处以 Java 字符串拼接说明逻辑）：
// 推荐：在代码中构建条件列表，再 join -->
List
if (params.get("name") != null && !params.get("name").trim().isEmpty()) {
conditions.add("name = ?"); // 占位符，后续设参
}
if (params.get("status") != null) {
conditions.add("status = ?");
}
String whereClause = conditions.isEmpty() ? "" : "WHERE " + String.join(" AND ", conditions);
避免 WHERE 1=1 的真实意图：统一入口，而非留后门
WHERE 1=1 的本质是提供一个恒真起点，让后续 AND xxx 无需判断是否为首条件。但更健壮的方式是：
- 收集所有有效条件到集合（如 List
） - 用
String.join(" AND ", conditions)拼接，天然无多余 AND 或开头空格 - 若集合为空，整个 WHERE 子句可完全省略（比
WHERE 1=1更干净） - 若必须保留 WHERE（如配合 ORDER BY），再补
WHERE 1=1—— 但这是极少数场景
真正要防的不是语法，是 SQL 注入和类型错配
for 循环拼接字符串时，绝不能把用户输入直接插入 SQL：
- ❌ 错误：
"name = '" + params.get("name") + "'"→ 注入风险 - ✅ 正确：用预编译占位符（
?），并在执行时用 PreparedStatement#setXxx() 绑定参数 - ✅ 更优：交给 MyBatis / JPA 等框架处理，用
<if test="name != null and name != ''"></if>自动管理条件与参数绑定
替代 for 循环的现代实践：声明式条件优于命令式拼接
多数 ORM 已内置动态 SQL 支持，无需手写 for：
- MyBatis XML：
<where></where>标签自动处理首 AND、去除多余空格、空条件跳过 - MyBatis-Plus QueryWrapper：链式调用
.eq("name", name).ne("status", null)，内部自动组装 - JPA Criteria API：类型安全、编译期检查，彻底规避字符串拼接
手写 for 拼接适合极简 JDBC 场景，但务必配套参数化查询与严格校验。
