WHERE 1=1 是临时语法拐杖，应尽快移除；正确做法是用 MyBatis 的 <where> 标签或 JDBC 中条件集合动态构建 SQL，确保参数安全、逻辑清晰、可维护性强。
WHERE 1=1 本身不需要“优雅处理”，它只是个临时拐杖；真正要做的，是尽快把它从代码里拿掉——尤其在应用层拼SQL时。
为什么 WHERE 1=1 在 Java/Python 字符串拼接中容易出问题
它解决的只是“要不要写 WHERE”这个语法开关问题，但掩盖了更关键的缺陷：
- 无法区分
NULL和空字符串：比如用户没填姓名，你却拼出AND name = ''，结果可能查不到任何记录，而实际意图是“不限制姓名” - 参数顺序和占位符数量必须手动对齐：每加一个
AND status = ?，就得同步调用一次PreparedStatement.setString(2, status)，条件一多就容易索引越界或错位 - 日志难读、调试困难：打印出来的 SQL 是
WHERE 1=1 AND name = ? AND status = ?，你根本看不出哪些条件真正生效了 - 一旦漏了预编译，直接暴露 SQL 注入面：
"AND name = '" + userInput + "'"这种写法在生产环境等于开门揖盗
MyBatis 中应该用 标签，而不是手写 WHERE 1=1
MyBatis 的 <where> 标签不是语法糖，它会自动做三件事：
- 如果内部所有
<if>都不满足，整个<where>块被跳过（不会生成WHERE关键字） - 如果至少一个条件成立，自动添加
WHERE，并剔除第一个AND或OR - 完全解耦条件逻辑和 SQL 结构——你不用操心
1=1，也不用数问号
示例：
<where><br> <if test="name != null and name != ''">name LIKE CONCAT('%', #{name}, '%')</if><br> <if test="status != null">AND status = #{status}</if><br></where>当
name 和 status 都为 null 时，最终 SQL 就是 SELECT * FROM user，干净利落。
纯 JDBC 或脚本场景下，用条件集合替代 1=1
不要在 StringBuilder 里硬写 "WHERE 1=1"，改用显式收集：
- 维护一个
List<String> conditions和一个List<Object> params - 每个有效条件都往两个列表里同时加：比如非空
name→conditions.add("name = ?")+params.add(name) - 拼 SQL 时：
String whereClause = conditions.isEmpty() ? "" : "WHERE " + String.join(" AND ", conditions) - 执行时按
params顺序绑定参数，顺序天然一致，不怕错位
这样既规避了 1=1 的语义冗余，又让逻辑可测试、可审计、可打印调试。
WHERE 1=1 真正合理的使用场景极少
它只在一种情况算“合理”：存储过程中临时调试，或极简脚本里快速补全语法。比如：
- MySQL 存储过程里写
SET @sql = 'SELECT * FROM t WHERE 1=1';，后续用CONCAT拼条件 —— 但值仍必须用?占位，再通过EXECUTE ... USING绑定 - DBA 写一次性查询脚本，想快速验证字段名或表结构，
SELECT * FROM orders WHERE 1=1比删掉整个 WHERE 更快
除此之外，任何需要长期维护、多人协作、涉及用户输入的场景，都该默认视为“不该出现 1=1”。
最常被忽略的一点：WHERE 1=1 不解决 NULL 判断、不处理类型转换、不校验业务语义。它只是一个语法占位符，而动态查询真正的复杂性，全在条件有效性判断和参数安全绑定上。
