多条件动态查询核心是用Map接收参数并按需拼接WHERE子句，MyBatis推荐+自动处理空条件，也可用Criteria API提升类型安全，须防范SQL注入与空值陷阱。
用Map封装动态查询条件
多条件搜索的核心是让SQL能根据实际传入的参数灵活拼接WHERE子句。最常用且清晰的方式是用Map接收前端传来的多个参数（比如姓名、部门ID、状态、起止时间等），后端判断哪些字段不为空或有效，再决定是否加入查询条件。
例如：
- 用户只填了“姓名”，就只查name LIKE %xxx%
- 同时填了“部门ID”和“状态”，就追加 and dept_id = ? and status = ?
- 日期范围有值才加 between ? and ?，否则跳过
MyBatis中用 + 自动处理SQL拼接
使用MyBatis时，推荐用
示例片段：
立即学习“Java免费学习笔记（深入）”；
用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生成→安全执行”这条主线，就能稳住多条件搜索的开发节奏。不复杂但容易忽略细节。
