17370845950

多条件动态查询核心是用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时，推荐用标签配合来构建动态SQL。它能自动处理开头的AND/OR，并避免因条件全空导致语法错误。

示例片段：

  SELECT * FROM user
  
    
      AND name LIKE CONCAT('%', #{name}, '%')
    
    
      AND dept_id = #{deptId}
    
    
      AND create_time >= #{startTime}
    
  

用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生成→安全执行”这条主线，就能稳住多条件搜索的开发节奏。不复杂但容易忽略细节。