多条件动态查询核心是用Map接收参数并按需拼接WHERE子句，MyBatis推荐+自动处理空条件，也可用Criteria API提升类型安全，须防范SQL注入与空值陷阱。
用Map封装动态查询条件
多条件搜索的核心是让SQL能根据实际传入的参数灵活拼接WHERE子句。最常用且清晰的方式是用Map<string object></string>接收前端传来的多个参数（比如姓名、部门ID、状态、起止时间等），后端判断哪些字段不为空或有效，再决定是否加入查询条件。
例如：
- 用户只填了“姓名”，就只查name LIKE %xxx%
- 同时填了“部门ID”和“状态”，就追加 and dept_id = ? and status = ?
- 日期范围有值才加 between ? and ?，否则跳过
MyBatis中用 + 自动处理SQL拼接
使用MyBatis时，推荐用<where></where>标签配合<if test="xxx != null and xxx != ''"></if>来构建动态SQL。它能自动处理开头的AND/OR，并避免因条件全空导致语法错误。
示例片段：
立即学习“Java免费学习笔记（深入）”；
<select id="listUsers" resultType="User">
SELECT * FROM user
<where>
<if test="name != null and name != ''">
AND name LIKE CONCAT('%', #{name}, '%')
</if>
<if test="deptId != null">
AND dept_id = #{deptId}
</if>
<if test="startTime != null">
AND create_time >= #{startTime}
</if>
</where>
</select>用Criteria API或QueryDSL提升类型安全（适合复杂场景）
当项目对可维护性和编译期检查要求高时，可以考虑JPA Criteria API或QueryDSL。它们用Java代码构造查询，避免字符串拼SQL的风险，支持IDE自动补全和重构。
比如Criteria方式：
- 通过
CriteriaBuilder和CriteriaQuery构建查询对象 - 每个
if逻辑转为Predicate，用criteriaBuilder.and()组合 - 最终
entityManager.createQuery(query).getResultList()执行
缺点是代码稍冗长，适合中大型系统或审计严格场景。
避免SQL注入与空值陷阱的实操要点
多条件搜索容易踩两个坑：一是直接拼接字符串引发SQL注入，二是忽略空字符串、0、false等“假值”的业务含义。
- 永远用#{}占位符（MyBatis）或PreparedStatement参数绑定，不用${}或字符串+拼接
- 对数字类型字段，注意0可能是合法值（如status=0表示“待审核”），不能简单判null就跳过
- 对字符串，建议统一trim()后再判断非空，防止空格干扰
- 时间字段优先用LocalDateTime，数据库对应datetime类型，避免时区和格式混乱
基本上就这些。结构上把握“参数接收→条件过滤→SQL生成→安全执行”这条主线，就能稳住多条件搜索的开发节奏。不复杂但容易忽略细节。
