orderNo != null 這種非字符串類型的判斷，也能用 Java 靜態(tài)方法來替代，比如用 Hutool 的 ObjectUtil.isNotNull() 或 ObjectUtil.isNotEmpty()。

我?guī)湍惆?字符串 用 StrUtil.isNotBlank()，非字符串 用 ObjectUtil.isNotNull() 的完整 MyBatis updateById 版本寫好，這樣判斷邏輯會很統(tǒng)一。

完整 Hutool 寫法版本

<update id="updateById" parameterType="com.example.NursingProject">
    UPDATE nursing_project
    <set>
        <if test="@cn.hutool.core.util.StrUtil@isNotBlank(name)">
            name = #{name},
        </if>
        <if test="@cn.hutool.core.util.ObjectUtil@isNotNull(orderNo)">
            order_no = #{orderNo},
        </if>
        <if test="@cn.hutool.core.util.StrUtil@isNotBlank(unit)">
            unit = #{unit},
        </if>
        <if test="@cn.hutool.core.util.ObjectUtil@isNotNull(price)">
            price = #{price},
        </if>
        <if test="@cn.hutool.core.util.StrUtil@isNotBlank(image)">
            image = #{image},
        </if>
        <if test="@cn.hutool.core.util.StrUtil@isNotBlank(nursingRequirement)">
            nursing_requirement = #{nursingRequirement},
        </if>
        <if test="@cn.hutool.core.util.ObjectUtil@isNotNull(status)">
            status = #{status},
        </if>
        <if test="@cn.hutool.core.util.StrUtil@isNotBlank(createBy)">
            create_by = #{createBy},
        </if>
        <if test="@cn.hutool.core.util.StrUtil@isNotBlank(updateBy)">
            update_by = #{updateBy},
        </if>
        <if test="@cn.hutool.core.util.StrUtil@isNotBlank(remark)">
            remark = #{remark},
        </if>
        <if test="@cn.hutool.core.util.ObjectUtil@isNotNull(updateTime)">
            update_time = #{updateTime},
        </if>
    </set>
    WHERE id = #{id}
</update>

對比優(yōu)化

原本 MyBatis 寫法

<if test="orderNo != null">...</if>

需要區(qū)分字符串、數(shù)字、對象分別寫不同條件。

現(xiàn)在 Hutool 寫法

字符串 → StrUtil.isNotBlank()（避免空格也被當(dāng)作有效值）

數(shù)字/對象 → ObjectUtil.isNotNull()（僅判斷 null，不管 0/false）

這樣代碼風(fēng)格統(tǒng)一，可讀性也更好。

這個現(xiàn)象其實是 MyBatis + OGNL 的自動類型推斷 惹的禍。

你這里：

<if test="@cn.hutool.core.util.ObjectUtil@isNotNull(price)">
    price = #{price},
</if>
<if test="@cn.hutool.core.util.ObjectUtil@isNotNull(status)">
    status = #{status},
</if>

表面上看用的都是同一個 ObjectUtil.isNotNull()，但實際上 price 和 status 的運行時類型不一樣：

為什么status變成Long？

MyBatis 在 JSON 反序列化（或者參數(shù)綁定）時，如果是整數(shù)值但沒有顯式指定類型，很多情況下會用 Long 表示（尤其是 Map 或動態(tài) SQL 場景中）。
ObjectUtil.isNotNull(1L) 本身沒問題，但在 OGNL 調(diào)用靜態(tài)方法時，有些版本的 MyBatis/OGNL 會先嘗試做類型轉(zhuǎn)換（尤其是如果方法簽名有重載或匹配不明確時），于是會觸發(fā) "Unable to convert type java.lang.Long to java.lang.CharSequence" 這種異常。

為什么 price 沒事？

BigDecimal 類型在 OGNL 里不會被誤判去做字符串轉(zhuǎn)換，因為它本來就不是 CharSequence，且 ObjectUtil.isNotNull() 的簽名 isNotNull(Object) 匹配得很干脆，沒有觸發(fā)額外的類型推斷。

怎么解決？

最穩(wěn)妥的方式就是 不要用靜態(tài)方法去判斷 null，直接用 OGNL 原生的 null 判斷：

<if test="price != null">
    price = #{price},
</if>
<if test="status != null">
    status = #{status},
</if>

這樣不涉及靜態(tài)方法匹配，就不會出現(xiàn) Long 轉(zhuǎn) CharSequence 的問題。

如果你一定要用 ObjectUtil.isNotNull：

<if test="@cn.hutool.core.util.ObjectUtil@isNotNull((Object)status)">
    status = #{status},
</if>

加 (Object) 是為了讓 OGNL 不去嘗試把 Long 當(dāng)作別的類型匹配。

如果單純比較性能，原生 != null 判斷 會明顯比 StrUtil.isNotBlank() 快。

原因很簡單：

舉個例子（粗略對比執(zhí)行步驟）：

1.!= null

• MyBatis OGNL：取值
• JVM：引用地址是否為 null → true/false
• 總耗時 ≈ 一次內(nèi)存地址比較

2.StrUtil.isNotBlank()

• MyBatis OGNL：加載 StrUtil 類
• JVM：調(diào)用靜態(tài)方法
• 方法內(nèi)部：
  • 判斷對象是否為 null
  • 調(diào)用 String.length()
  • 遍歷每個字符判斷是否為空格字符
• 總耗時 ≈ 多次方法調(diào)用 + 字符遍歷

結(jié)論

• 非字符串類型 → != null 是最優(yōu)方案（少步驟、無額外邏輯）
• 字符串類型 → 如果需要判斷空字符串和全空格情況，那必須用 isNotBlank()（功能多，但慢一點）
• 如果字符串允許空格或空值存儲，不做空格判斷，用 != null 會快很多

建議：

• 數(shù)值、日期、枚舉 → 全部用 != null
• 字符串 → 如果必須去掉空格判斷為空，才用 isNotBlank()；否則也用 != null

到此這篇關(guān)于MyBatis的xml中字符串類型判空與非字符串類型判空處理方式的文章就介紹到這了,更多相關(guān)MyBatis xml字符串類型判空內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論