背景

今天一個即將完成的項目，測試童鞋跟開發(fā)童鞋講微信支付出bug了，支付完成后訂單卻沒有更新狀態(tài)了。開發(fā)童鞋馬上講，這塊代碼這幾天一直沒更新啊，不一直都好好的么，測試就別給我添亂了。正當測試和開發(fā)準備“吵架”的時候我聽到了，對他們說再測幾遍。

結果開發(fā)自己拿起手機測試這個支付模塊，發(fā)現沒有任何問題，于是他準備懟回測試；但很不幸測試繼續(xù)下單發(fā)現依然不對勁。結果他們兩扯了幾個來回，終于得到了一個共識，也就是發(fā)現了一個這樣神奇的規(guī)律：

“開發(fā)測試的支付金額都是1元、1.5元、2元之類的，所以都是成功的，而測試沒有回調成功的其中就有1.1元、1.11元之類的，而其他的金額也是回調成功的?！?/span>

分析

然后我就跟開發(fā)交代說看看日志，這肯定是異步回調出問題了！由于這位開發(fā)童鞋經驗并不怎么豐富，于是馬上就說如果回調錯了，怎么可能跟邏輯有關系呢？他對我說：

“x哥，你幫我讀讀我的代碼，看到底是哪里的問題？”

沒辦法，小伙伴遇到難題只能上唄，于是打開他的回調通知模塊的代碼，發(fā)現他在整個回調處理上做得還可以，按照了微信支付官方建議的安全措施去做支付后的校驗，而校驗中的一個校驗規(guī)則便是訂單需要支付的金額，跟這筆微信支付訂單微信返回的金額是否一致，如果一致則通過該項校驗，否則不通過。

而上面的問題剛好是跟金額有關系，首先先排除其他的校驗規(guī)則，為了保險起見分析了多筆支付的回調數據日志，發(fā)現其他校驗并沒有問題。也就是問題就初步定位在金額校驗這個步驟上面，如果這一步校驗不通過后續(xù)更新訂單以及其他相關操作都無法執(zhí)行下去。

結果我發(fā)現他的校驗處的核心代碼為：if(100*$order['pay_feel']==$result['total_fee']){},其中$order是訂單信息，而$result是解析微信服務器返回xml解析后的一個數組，而100是微信支付金額的一個比值，100代表1塊錢，這個做過微信支付的同學都知道。

可能對于寫慣了強類型語言（如java、python等）代碼的人來講，這不是一個好的代碼，但實際上有很多phper寫的代碼都是這樣寫的，當然這是一種不是特別嚴謹的寫法。但php作為一種弱類型語言，對于這樣的問題它似乎很多時候都是“睜一只眼閉一只眼”。

解決

首先我們來看看下面幾組php基礎性的知識運行結果：

就是說111在默認情況下php把它當做int處理，而1.11以及它乘以一個數值是當做float來處理的，當然1.21或者1.2也是會當做float來處理的；可以自己多嘗試幾次。接下來我們要回顧編程的基礎知識了。也就是=、==以及===的區(qū)別，至于他們的區(qū)別這里不多說，這里就說==比較的是什么？通俗地講==我們只是比較值，而不比較類型，比如下面的幾個結果：

也就是說，從理論上來講，他上面的代碼執(zhí)行后的結果應該是能夠達到我們的預期目的的，也就是==在這里是成立的。但事實上是：

其實這就是php作為弱類型語言的一些缺陷，實際上有的結果甚至在32位和64位處理器的電腦上執(zhí)行的結果也不一致。這也就是說在面向這些問題的時候，我們應該往更加健壯的目標去發(fā)展，比如最基礎的就是在判斷前把兩者的數據類型強制轉換成為一致（同時請注意php分數計算的坑，哈哈），這個問題即可解決。

后語

其實如果大家了解甚至是寫過很多諸如java、C之類的代碼，就會對上述問題有更深層次的的了解，有興趣的童鞋可以讀讀php的源代碼。

我?guī)н^很多開發(fā)，我發(fā)現特別是一些開發(fā)新手，越是對這些非常基礎的東西不屑一顧。認為這些東西太簡單了，而我一直都強調的是基礎非常重要，我覺得作為一個優(yōu)秀的開發(fā)者，技術基礎、經驗、溝通、產品理解等等缺一不可。遺憾的是，很多開發(fā)者只在乎前沿的技術，而對其他的東西似乎都很不屑！