在MyBatis开发过程中,当使用进行SQL拼接时，如果传入的参数为null，通常会引发org.apache.ibatis.reflection.ReflectionException或SQL语法错误，解决这一问题的核心上文归纳在于：本质是字符串直接替换，不具备预编译的参数处理能力，因此必须在SQL映射文件中通过OGNL表达式进行非空判断，或者在Java业务层赋予默认值，确保SQL语句的语法完整性。
深入解析${} 为null报错的根本原因
要彻底解决这个问题,首先需要理解MyBatis中和的本质区别，对应的是JDBC中的预编译参数（PreparedStatement），它会将传入的数据作为字符串处理，并自动处理JDBC类型的转换，即使传入null，MyBatis也会智能地将其设置为SQL中的NULL，不会破坏SQL结构。
相比之下,仅仅是一种纯粹的字符串替换（String Substitution），MyBatis在处理SQL时，会将${variable}直接替换为变量的字面值，如果SQL为SELECT * FROM user ORDER BY ${columnName}，当columnName为"id"时，生成的SQL就是SELECT * FROM user ORDER BY id，当columnName为null时，替换过程会出现两种极端情况：一是MyBatis内部在解析参数时找不到对应的属性值而抛出反射异常；二是即使替换成功，生成的SQL变成了SELECT * FROM user ORDER BY，这在数据库层面是语法错误的，因为ORDER BY后缺失了必要的排序字段。
专业解决方案与最佳实践
针对上述原因,以下是几种经过实战验证的专业解决方案，按推荐程度排序：
利用OGNL表达式进行默认值赋值（推荐）
这是最优雅、代码侵入性最小的解决方案，MyBatis强大的OGNL表达式允许在XML中直接编写逻辑判断，我们可以在内部使用三元运算符，当参数为null时，提供一个符合业务逻辑的默认值。
在处理动态排序时：
SELECT * FROM product
ORDER BY ${sortField != null ? sortField : 'create_time'}
${sortOrder != null ? sortOrder : 'DESC'} 这种方式确保了无论前端是否传递了排序参数,生成的SQL语句在语法上永远是完整的，如果sortField为null，它会自动降级为使用create_time进行排序，既避免了报错，又保证了系统的健壮性。
结合动态SQL标签<if>进行包裹
如果某个参数在为null时完全不应该出现在SQL语句中（例如动态表名或某些特定的查询条件），可以使用MyBatis的动态SQL标签，虽然<if>标签常用于场景，但配合使用时也能有效规避null风险。
动态表名切换：
<select id="selectList" resultType="map">
SELECT * FROM
<if test="tableName != null and tableName != ''">
${tableName}
</if>
<if test="tableName == null or tableName == ''">
default_table
</if>
</select> 这种方法逻辑清晰,易于维护，特别适用于参数为null时需要切换到备用逻辑的场景。
Java业务层统一处理（防御性编程）
从架构设计的角度来看,SQL映射文件应当只关注数据的查询，而不应包含过多的逻辑判断，在Service层或Controller层，对于必须使用接管的参数（如动态列名、表名），应当进行非空校验。
在Java代码中,可以使用Optional类或简单的if判断：
public List<User> getUserList(String sortField) {
if (StringUtils.isEmpty(sortField)) {
sortField = "id"; // 设置默认排序字段
}
return userMapper.selectList(sortField);
} 这种做法将异常拦截在数据库访问之前,减少了数据库的无用请求，符合分层架构的最佳实践，其缺点是如果调用链路较长，可能需要在多个地方重复进行校验。
安全警示：SQL注入风险
在讨论为null报错的同时,必须严肃指出其伴随的安全风险，由于是直接拼接SQL语句，如果传入的参数不是null，而是恶意的SQL片段（例如'id'; DROP TABLE user; ），将会导致严重的SQL注入攻击。
严禁直接使用接收用户输入的普通参数（如查询条件值），仅应用于以下场景：
- 动态表名（且表名通过白名单校验）。
- 动态列名。
- 动态排序关键字（如ASC/DESC，需校验非空且限定范围）。
对于所有的业务数据查询条件,必须强制使用，在解决null报错问题时，切勿为了方便而牺牲系统的安全性。
MyBatis中为null报错是开发中常见的问题,其本质在于字符串替换机制导致的SQL语法断裂，通过在XML中运用OGNL表达式设置默认值，或利用动态SQL标签进行逻辑控制，可以高效地解决此类问题，开发者应时刻保持安全意识，严格区分与的使用场景，在保证代码健壮性的同时，筑牢系统安全的防线。
相关问答
Q1：为什么MyBatis中${}传参为null时会报“Parameter 'xxx' not found”异常？ A1：这是因为MyBatis在解析SQL语句时，使用OGNL表达式去上下文中查找对应的参数值，当传入的参数为null时，在某些MyBatis版本或特定配置下，OGNL可能无法识别该属性的存在，或者因为参数对象本身为null导致无法获取属性，从而抛出反射异常，这进一步证实了在使用前必须确保参数对象及其属性的有效性。
Q2：在MyBatis中，除了判断null，如何防止${}带来的SQL注入？ A2：防止注入主要依靠“白名单”机制，在Java代码中对传入的动态列名或表名进行校验，只允许预定义的安全值通过，如果前端传入排序字段，后端应检查该字段是否存在于允许排序的字段列表中（如Set<String> allowedFields），如果不在列表中，则直接抛出异常或使用默认值，绝不将其直接拼接到SQL中。 能帮助你彻底解决MyBatis开发中的这一难题，如果你在项目中遇到过更复杂的报错场景，欢迎在评论区分享你的案例和解决方案，我们一起探讨。
