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

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

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

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

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

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

    [[154475]]

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

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

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

小結(jié)：大家有遇到過么，xml文件沒有成功修改?；蛘呤墙?jīng)常變動(dòng)的文件不適合用xml持久化？

 EF開的玩笑

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

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

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

raw = _respository.GetNoteById(id); 

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

然后重新啟動(dòng)，先訪問編輯頁面，數(shù)據(jù)又是正常的，明顯受到了前面方法的影響。難道數(shù)據(jù)被緩存了？后來發(fā)現(xiàn)，因?yàn)樽宰髀斆鞲懔藗€(gè)單例，倉(cāng)庫(kù)內(nèi)部的db=xxDB.GetInstance()。結(jié)果因?yàn)檫@兩個(gè)頁面都是一個(gè)上下文。數(shù)據(jù)被緩存了下來，導(dǎo)致查詢的對(duì)象不是來自數(shù)據(jù)庫(kù)。這個(gè)時(shí)候如果保存一下，其他的被縮短的內(nèi)容也都會(huì)被保存到數(shù)據(jù)庫(kù)中。而最簡(jiǎn)單的辦法就是 db=new dbcontext();

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

ckeditor 也不聽話 

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

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

其實(shí)，對(duì)于ckeditor，replace后面的這個(gè)參數(shù)id也可以，name也可以。但那次發(fā)現(xiàn)他的那兩個(gè)參數(shù)不一樣，改成一樣的，就都加載成功了?？赡苁怯械捻撁嬗懈蓴_吧。

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