小伙伴好哇，我是Tom哥。

今天分享一個(gè)寫(xiě)代碼時(shí)遇到的詭異問(wèn)題，如何排查解決的。

從事互聯(lián)網(wǎng)的人都懂，一般遇到問(wèn)題時(shí)，首先會(huì)想用谷歌、百度等搜索引擎，看看前輩們是如何解決的。

但有些問(wèn)題比較抽象，不知道如何來(lái)描述，怎么辦？或者勉強(qiáng)描述清楚了，搜出來(lái)的答案也很難滿足要求，整個(gè)過(guò)程猶如大海撈針。最后求助 ChatGPT 瞬間解決，給大家分享下解決思路。

問(wèn)題的來(lái)龍去脈

正在開(kāi)發(fā)一個(gè)項(xiàng)目，倉(cāng)儲(chǔ)層有一個(gè)接口類（IProductReadRepository），其中一個(gè)方法的入?yún)⑹褂昧?Java 泛型，具體如下：

List<SpuVO> batchQuerySpuBySpuIdsFromDB(ProductQueryWrapper<List<Long>> req);

在上層的領(lǐng)域服務(wù)中，有一處調(diào)用這個(gè)方法的代碼，具體如下：

ProductQueryWrapper productQueryWrapper = ProductQueryWrapper.builder()
        .bizCode(BusinessCodeEnum.SMART.getCode())
        .bizScene(BusinessSceneEnum.RETAIL.getCode())
        .storeId(multiPackageVO.getStoreId())
        .bizParams(spuIds)
        .build();
List<ProductSummaryVO> productSummaryVOS = productReadRepository.batchQuerySpuBySpuIdsFromDB(productQueryWrapper);

if (CollectionUtils.isEmpty(productSummaryVOS)) {
    bizResult.error(BizErrorCode.MULTI_PACKAGE_PRODUCT_NOT_EXIST);
    return bizResult;
}

其中，List<ProductSummaryVO> productSummaryVOS = productReadRepository.batchQuerySpuBySpuIdsFromDB(productQueryWrapper); 這行代碼非常詭異

返回的結(jié)果List<ProductSummaryVO>并不匹配，但在IDEA中卻沒(méi)有報(bào)錯(cuò)，這讓我們感到非常困擾。

這是怎么回事？

當(dāng)時(shí)懷疑是錯(cuò)覺(jué)，仔細(xì)對(duì)比了兩個(gè)方法，確實(shí)是對(duì)的。

又懷疑是 IDEA 的緩存干擾導(dǎo)致，所以將工程重新 build 了一次還是不行！

接下來(lái)，能想到的各種招數(shù)都招呼上，比如：

• 在終端執(zhí)行 mvn clean install -U，重新編譯代碼，并強(qiáng)制 Maven 更新所有依賴的快照版本（Snapshot）
• 手動(dòng)將 maven 的本地倉(cāng)庫(kù)的依賴包全部刪除，重新拉取
• 將本地工程文件中的 target 文件刪除
• .....

最后，使出絕招，將本地的工程代碼全部刪除，然后重新從 git 上拉取最新代碼，編譯，導(dǎo)入到 IDEA 工程。

但，但，但，問(wèn)題依然存在，真讓人崩潰。

難道是 IDEA 中的錯(cuò)誤檢查失效了，于是人為制造了一些錯(cuò)誤，發(fā)現(xiàn) IDEA 也都能識(shí)別出來(lái)。

實(shí)在沒(méi)招了。。。。。。。

最后，還是問(wèn)下 ChatGPT 吧

首先，先把問(wèn)題描述清楚，ChatGPT 特懂人情世故，你跟他講清楚問(wèn)題，他也會(huì)給你一個(gè)清楚的答案。

有一個(gè)接口內(nèi)的方法定義如下：

 List<SpuVO> batchQuerySpuBySpuIdsFromDB(ProductQueryWrapper<List<Long>> req);

使用下面的代碼來(lái)調(diào)用 batchQuerySpuBySpuIdsFromDB，返回的 List<SpuVO> 結(jié)果并不匹配，但在 IDEA 中沒(méi)有報(bào)錯(cuò)，是什么原因？

ProductQueryWrapper productQueryWrapper = ProductQueryWrapper.builder()
        .bizCode(BusinessCodeEnum.SMART.getCode())
        .bizScene(BusinessSceneEnum.RETAIL.getCode())
        .storeId(multiPackageVO.getStoreId())
        .bizParams(spuIds)
        .build();
List<ProductSummaryVO> productSummaryVOS = productReadRepository.batchQuerySpuBySpuIdsFromDB(productQueryWrapper);

if (CollectionUtils.isEmpty(productSummaryVOS)) {
    bizResult.error(BizErrorCode.MULTI_PACKAGE_PRODUCT_NOT_EXIST);
    return bizResult;
}

ChatGPT 很快就給出了答案。

問(wèn)題可能出在泛型擦除和編譯時(shí)類型檢查上。由于Java泛型的擦除機(jī)制，在運(yùn)行時(shí)無(wú)法獲取泛型的實(shí)際類型，這可能導(dǎo)致類型不匹配的問(wèn)題。

那我們就按照它的思路來(lái)，將這行代碼  ProductQueryWrapper productQueryWrapper = ProductQueryWrapper.builder()

修改為  ProductQueryWrapper<List<Long>> productQueryWrapper = ProductQueryWrapper.<List<Long>>builder()

在構(gòu)建 ProductQueryWrapper 對(duì)象時(shí)， 指定泛型參數(shù)的具體類型，以便在運(yùn)行時(shí)能夠正確地識(shí)別參數(shù)類型。

然后，問(wèn)題真的解決了。

如下圖所示，第二處紅框位置的代碼開(kāi)始報(bào)錯(cuò)。因?yàn)榻涌诘囊?guī)范（返回結(jié)果）調(diào)整了，此處確實(shí)應(yīng)該報(bào)錯(cuò)提示。

后面，我們根據(jù)錯(cuò)誤提示，將 ProductSummaryVO 類替換成 SpuVO 類。

最終，不但編譯不報(bào)錯(cuò)，單元測(cè)試也能跑通。問(wèn)題完美解決。

背后的原因

為何在 IDEA 中沒(méi)有直接報(bào)錯(cuò)呢？這里牽扯到Java泛型的類型推斷機(jī)制。

上述代碼中，雖然使用了原始類型 ProductQueryWrapper ，但沒(méi)有指定具體的泛型類型。

Java 7 及以后的版本引入了菱形操作符（Diamond Operator），允許在創(chuàng)建對(duì)象時(shí)不再重復(fù)指定泛型類型，而是通過(guò)上下文進(jìn)行類型推斷。

這就意味著在你的代碼中，雖然沒(méi)有明確指定泛型類型，但由于在 ProductQueryWrapper.builder() 上下文中，編譯器會(huì)嘗試根據(jù)調(diào)用方的期望類型來(lái)推斷泛型參數(shù)。

這種類型推斷機(jī)制使得在 IDEA 開(kāi)發(fā)工具不會(huì)直接報(bào)錯(cuò)，也就出現(xiàn)了上文說(shuō)到的那個(gè)問(wèn)題。

今天的分享就到這里，我們下回再見(jiàn)。