剛剛修我們魚聰明 AI 助手平臺的一個 Bug，結(jié)局很狗血！趕緊給大家分享一下，順便也分享下標準的排查 Bug 思路。

事情是這樣的，有小伙伴在魚聰明平臺（https://www.yucongming.com）創(chuàng)建了一個 AI 助手，名稱為【軟件開發(fā)人員】。當我搜索 “軟件開發(fā)” 時，能搜出這個模型：

結(jié)果搜索 “軟件開發(fā)人員”，也就是助手的全名稱時，竟然搜不出結(jié)果了？！

遇到這種事，先從前端出發(fā)：第一時間確認前端發(fā)送的請求參數(shù)是否正確。

按 F12 打開網(wǎng)絡控制臺，發(fā)現(xiàn)搜索關鍵詞傳的沒毛?。?/p>

然后魚皮順著網(wǎng)線爬到后端，先要確認一下從數(shù)據(jù)庫中有沒有查出最原始的數(shù)據(jù)，再考慮是不是被業(yè)務代碼過濾掉了。

在本地開啟數(shù)據(jù)庫的查詢?nèi)罩?，用的?MyBatis Plus 框架，開啟日志的代碼如下：

mybatis-plus:
??configuration:
????map-underscore-to-camel-case:?false
????log-impl:?org.apache.ibatis.logging.stdout.StdOutImpl


再次執(zhí)行搜索，打印出的 SQL 記錄如圖：

把參數(shù)拼到 SQL 語句模板中，就是 name like '%軟件開發(fā)人員%'，看上去沒有任何問題。

再次驗證，接下來我們把拼接好的 SQL 放到數(shù)據(jù)庫控制臺進行真實查詢：

結(jié)果查詢結(jié)果為 0：

奇怪了，難道數(shù)據(jù)庫中沒有這條記錄？但是為啥搜索 “軟件開發(fā)” 的時候，能搜出這個助手呢？

然后我又用助手的 id 去數(shù)據(jù)庫中查詢，發(fā)現(xiàn)確實有名稱為 “軟件開發(fā)人員” 的數(shù)據(jù)。

氣了氣了，為啥查不出來啊？！大家也可以猜一猜。

這個時候我其實已經(jīng)有想法了，難道是數(shù)據(jù)庫中存儲的 name 和我們看到的 name 格式（或者字符）不一致？于是我就從數(shù)據(jù)庫中把 name 的值復制出來，如圖：

結(jié)果，從數(shù)據(jù)庫中復制出來的 name 作為查詢條件，是能查出結(jié)果的！

于是就有了下面這張神奇的截圖，兩個 “一模一樣” 的 SQL 語句，一個有結(jié)果，一個沒結(jié)果：

基本就可以確認了，此 “軟件開發(fā)人員” 非彼 “軟件開發(fā)人員”，這兩個字符串是不一致的！

于是我分別用這兩個字符串來生成 MD5 Hash 碼，發(fā)現(xiàn) Hash 碼不同，說明原字符串不同。

再進行更精確地對比，發(fā)現(xiàn)是 “人” 字不同：

坑??！誰能看出來這兩個 “人” 字有區(qū)別！

到底有啥區(qū)別呢？問下魚聰明 AI 吧~

結(jié)果一秒破案：原來第一個 “人” 是全角字符，這真的是。。。泰褲辣！

大概整個案件就是這樣。所以說，我們看到得未必是真實的，這個 Bug 讓我想起了很多朋友初上大學時經(jīng)常把中英文逗號、中英文冒號搞混，這種 Bug 真是讓人哭笑不得。希望各位程序員朋友們，盡量不要遇到吧，遇到了的話，想想我這篇文章，說不定就有了解決的思路呢。