Mybatis IF TEST判断Long参数时触发Getter获取异常求助

这个问题我之前也碰到过，原因其实很简单——当你传入单个基本类型（或其包装类，比如这里的Long）作为参数时，MyBatis并不会把它当作一个带有auctionId属性的对象来处理，而是直接持有这个值本身。所以你在<if>标签里用auctionId != null去判断时，MyBatis会尝试在Long类里找auctionId的getter方法，自然就抛出找不到属性的异常了。

下面给你几个可行的解决方案：

方案1：使用MyBatis默认的参数占位符_parameter #

MyBatis对单个参数会默认提供一个名为_parameter的占位符，用来指代这个参数本身。你只需要把<if>标签里的判断条件改成_parameter != null即可：

<select id="selectAvailableForAuction" resultMap="BaseResultMap" parameterType="Long">
  SELECT <include refid="Base_Column_List" />
  FROM lot
  WHERE id NOT IN (
    SELECT lot_id FROM auction_lots
    <if test="_parameter != null">
      WHERE auction_id != #{auctionId}
    </if>
  )
</select>

这个方案不需要修改Mapper接口的代码，适合快速解决问题。

方案2：用@Param注解给参数显式命名 #

在Mapper接口的参数前加上@Param注解，指定参数的名称，这样MyBatis就会把这个参数绑定到你指定的名字上，XML里的判断条件就可以正常使用auctionId != null了：

首先修改Mapper接口方法：

List<Lot> selectAvailableForAuction(@Param("auctionId") Long auctionId);

XML映射语句可以保持你原来的写法不变：

<select id="selectAvailableForAuction" resultMap="BaseResultMap" parameterType="Long">
  SELECT <include refid="Base_Column_List" />
  FROM lot
  WHERE id NOT IN (
    SELECT lot_id FROM auction_lots
    <if test="auctionId != null">
      WHERE auction_id != #{auctionId}
    </if>
  )
</select>

这个方案的优势是可读性更好，其他开发者看代码时能直接明白参数的含义，推荐在团队协作中使用。

方案3：将参数包装成DTO对象（适合参数较多的场景） #

如果后续你的查询条件可能增加多个参数，建议把参数封装成一个DTO（数据传输对象）类，比如：

public class AuctionQueryParam {
    private Long auctionId;
    // 可以添加其他查询参数
    // getter和setter方法
    public Long getAuctionId() {
        return auctionId;
    }
    public void setAuctionId(Long auctionId) {
        this.auctionId = auctionId;
    }
}

然后修改Mapper接口方法：

List<Lot> selectAvailableForAuction(AuctionQueryParam queryParam);

XML映射语句中修改parameterType，并保持判断条件不变：

<select id="selectAvailableForAuction" resultMap="BaseResultMap" parameterType="com.yourpackage.AuctionQueryParam">
  SELECT <include refid="Base_Column_List" />
  FROM lot
  WHERE id NOT IN (
    SELECT lot_id FROM auction_lots
    <if test="auctionId != null">
      WHERE auction_id != #{auctionId}
    </if>
  )
</select>

这个方案扩展性更强，适合未来需求变化的场景。

总结 #

• 单个参数场景：优先选择@Param注解方案，兼顾简洁性和可读性；
• 多参数或未来可能扩展参数：使用DTO包装方案；
• 快速临时解决：使用_parameter占位符。

内容的提问来源于stack exchange，提问作者jsertx