不能說所有的bug都是紙老虎，但往往那種看似很奇葩的bug，導致的原因確實很簡單，煩了你一段時間，找到真相又讓你忍不住一笑。什么是奇葩的bug呢。我的定義是：代碼邏輯都一樣，但在A處是好的，到了B處就不行或者同類的ABC都是好的，D卻不行了的bug。而最終，問題確實不在代碼邏輯上面，往往是配置、權(quán)限或者業(yè)務邏輯之外的地方。

本地都是ok的，服務器還是不行，怪我咯

case1：本地工程改好，推倒服務器上，但一會兒，測試妹妹又叫了，“還是不行，你再看看”。頓時眉頭一皺，怎么可能，自己又run一遍，妥妥的啊。然后又到服務器上push下來，跑一遍，也ok啊。唯獨ccnet 持續(xù)集成編譯不能通過。抓耳撓腮的想了半天。發(fā)現(xiàn)剛剛運行的都是debug版，而ccnet跑到是Release版本。而正是因為Debug寫了些配置，Release卻沒有寫所以錯了。

小結(jié)：不要從一開始就忙錯了，除了debug，Release。git上面還有master，release，prelease，newFunction等諸多版本。這要是改錯了可能回導致更大的麻煩。

case2: 按照客戶需求改好了功能，放到云服務器上之前，我都會在本地的iis發(fā)布確認通過。但有一次突然發(fā)現(xiàn)每次訪問都要登錄認證。就如下圖：

明明是設置了可匿名訪問，也賦予了IUSR_xxxx ，Everone，各種權(quán)限，但就是不行。本地是iis7，服務器上是iis6，這會有什么差別？但是同目錄的其他網(wǎng)站都是ok的。我照著正常的網(wǎng)站配置，也不行，重新部署也沒有解決。然后各種搜羅，各種看帖，心想肯定還是和權(quán)限有關，也許是某個文件，也許是webconfig的配置，但試了發(fā)現(xiàn)還是無效。深更半夜，默默和屏幕對視，窗外，秋風乍起，屋里，室友已經(jīng)熟睡。

    [[154475]]

突然眼前一亮，有個博客說可能是IUSR_xxx賬戶沒有AD權(quán)限，在匿名用戶的地方需要設置一個有權(quán)限的賬戶。我換了成xxxx/Adminstrator ，果然好了。但為什么是這樣，別的網(wǎng)站的匿名用戶是IUSR_xxx都ok，這樣會不會有什么問題。現(xiàn)象是解決了，但真正導致的問題還沒有找到，或許是某個程序，或許是某個文件。還要繼續(xù)跟進。

小結(jié)：表面上相似的個體，還是有各自的差異性。但這個問題只是解決了現(xiàn)象，沒有解決本質(zhì)。

case3：這個問題真真的是奇葩，同事問我說，他webservice調(diào)用不了了。上午還好好的，下午就報407代理錯誤。但又是那句老話：“我其他的服務都能調(diào)用啊，在別的電腦上也能調(diào)用，就這臺電腦突然不行了” ，我和他測來測去，api本身沒有問題，網(wǎng)絡沒有問題，電腦沒有問題，代碼也沒有問題，因為根本沒有進來。那問題在哪？然后他老婆（對，他和他老婆坐一起）無意中在VS中點開了app.config。然后這個文件顯示被自動修改了，然后程序就通了。類似問題我也遇到過，我有一個程序是使用 XDocument.Save方法每次去覆蓋一個文件，但老是沒有成功覆蓋，即使vs提示：“文件已被修改，是否重新加載當前文件” 我點確定，還是沒有改掉，但我把文件內(nèi)容刪掉。卻又可以成功覆蓋。然后同事建議我換成 File.WriteAllText方法，就好了。

小結(jié)：大家有遇到過么，xml文件沒有成功修改。或者是經(jīng)常變動的文件不適合用xml持久化？

 EF開的玩笑

事情是這樣，為了讓內(nèi)容在表格中較好的顯示，我把內(nèi)容較長的截取了一下，但是發(fā)現(xiàn)，用到的地方都被改變了，但一看數(shù)據(jù)庫又沒有改變。

foreach (var note in notes) 
         { 
             var str = CommonHelper.StripHTML(note.Content); 
             if (str.Length > 15) 
             { 
                 note.Content = str.Substring(0, 12) + "..."; 
             } 
         } 

但是并未保存。但是再撈出一條時，內(nèi)容卻變化了。

raw = _respository.GetNoteById(id); 

但數(shù)據(jù)庫沒變變化。

然后重新啟動，先訪問編輯頁面，數(shù)據(jù)又是正常的，明顯受到了前面方法的影響。難道數(shù)據(jù)被緩存了？后來發(fā)現(xiàn)，因為自作聰明搞了個單例，倉庫內(nèi)部的db=xxDB.GetInstance()。結(jié)果因為這兩個頁面都是一個上下文。數(shù)據(jù)被緩存了下來，導致查詢的對象不是來自數(shù)據(jù)庫。這個時候如果保存一下，其他的被縮短的內(nèi)容也都會被保存到數(shù)據(jù)庫中。而最簡單的辦法就是 db=new dbcontext();

小結(jié)：這純粹是自己不了解EF的機制導致的麻煩，弄巧成拙。

ckeditor 也不聽話 

同事做個功能，異步加載一個編輯框，發(fā)現(xiàn)有時候能加載成功，有時候不能。有的頁面一直可以，有的頁面一直不行。

<textarea class="" name="Content" id="Content"> 
 
    CKEDITOR.replace('Content', 
   { 
       toolbar: ... 
   }); 

其實，對于ckeditor，replace后面的這個參數(shù)id也可以，name也可以。但那次發(fā)現(xiàn)他的那兩個參數(shù)不一樣，改成一樣的，就都加載成功了。可能是有的頁面有干擾吧。

還有些“神奇現(xiàn)象”，說不出原委，也就不提了。但往往這些bugs會耗費掉我們很多時間。能找到原因的問題，絕大部分會有解決辦法。找不到原因的問題，才是不好解決的問題。有時候即使解決了現(xiàn)象，但未必解決了問題的引發(fā)的原因，所以我習慣將這些事情都記錄下來，出現(xiàn)一次，可能就會出現(xiàn)第二次。此文，獻給那些我們調(diào)bug的碎片時光。