恍惚之間，距離上次寫博客已經過去差不多兩個月了。最近忙成狗，自從書出版后關注微信接口的時間就很少了，一方面，公司的事情實在太忙，現在是求生存的階段，只能一心扎在項目中。另一方面，書發行后，好像突然少了點繼續關注微信的動力，一種被微信折磨了大半年然后終於釋然的感覺。最近也很少在群里說話了，但也一直關注着群里的動態。看着那些被微信一次次坑的體無完膚、茶飯不思的小伙伴，心里頓時一群神獸（羊駝）飄過，但我有時也挺力不從心的，雖然他們問的問題我基本上都遇到過，大部分也都解決過，也都幫早進群的伙伴解決過，但每次還是有很多人絡繹不絕地問着重復的問題，回着回着就麻木了，因為好多次都是回復同樣的問題。也曾試着改變這種局面，我的做法是這樣的：首先提供一個可以問問題的論壇，讓有問題的同學把問題發到論壇里，然后把帖子地址發到群里，然后我再去群里回復，這樣下次再有人問相同的問題時，就可以直接把鏈接地址發他了。但貌似絕大多數人還是覺得麻煩，現在論壇也沒多少人氣了，也怪我自己沒有運營的經驗。
額，貌似廢話有點多，開始講重點吧，這篇博客是在開發的過程中一些比較常見的bug了，或者說是微信設計不合理的地方，我相信有很多人都想吐槽下微信，但我一直沒在園子里看到相關吐槽的博客，鄙人不才，獻丑了。（這些只是目前我能想到的，之前遇到的坑基本上沒整理，以后盡量都整理下，先發一部分吧。）。
一、素材管理中的修改永久圖文素材接口
這個接口其實不能說是bug，只能說是設計上的缺陷（從我的角度來看）。下面是此接口的文檔截圖：
從上圖可以看出，要調用此接口，需要傳的參數有media_id（表示一條圖文的id），index（表示要修改的某條子圖文的索引），articles（表示的圖文實體）。表面上看上去沒什么不對，修改一條圖文素材，需要傳一個素材的ID，這是毋庸置疑的，要修改哪條子圖文，那就需要把對應的索引傳了，貌似也沒問題，問題是修改的內容為什么要用articles呢，這里已經寫了索引了，那就應該是article了，表示的是修改某條多圖文中的指定索引的自圖文。感覺有點繞了吧。不要說我糾結，再仔細想想，如果我添加多圖文消息時，添加5條子圖文，那么我現在想修改這個多圖文，我想加一個，變成6條子圖文的多圖文，我發現這個接口無法滿足了，因為這里要傳的參數有index（索引），找遍了所有文檔，也沒辦法解決這個問題。我也已經無力吐槽了。
二、上傳圖文素材后，不返回圖文url。
這個接口也是設計上的缺陷。大家用過微信圖文消息的應該都知道每一條多圖文的子圖文都包含n（n<=10）個子圖文，每個子圖文都有一個對應的url（形如：https://mp.weixin.qq.com/…………），按理說添加圖文消息成功后，對應的url應該也已經生成了，但坑爹的是，當我們調用完添加圖文消息接口時返回的信息卻只有一個media_id，如果您想獲取子圖文對應的url，則必須根據media_id調用獲取永久素材接口來進行獲取。獲取永久素材接口這里還有一個大坑，大家可以去試試看。新增圖文素材時每一個子圖文都是需要一個縮略圖的media_id的（調用上傳圖片素材接口進行獲取的，形如DFJDFUIEUIURFEORHHz……之類的，反正就是一串比較長的字母數字組合），坑爹的話，當根據多圖文的media_id調用獲取永久素材接口時，每個子圖文對應的縮略圖的ID神奇的編程了一串類似於時間戳的數字。坑爹至極。
三、測試賬號調用群發無權限
這個絕對是個bug，相信肯定也坑過不少人。 我記得之前這個接口是沒問題的，不知道從什么時候出現問題的。來說說具體的問題吧。由於群發這個接口在開發測試的時候不太方便使用運營中的公眾號，所以大多人都會選擇使用測試號來進行測試，但不知道從什么時候開始調用測試號的這個接口會出現申請的48003錯誤（user not agree mass-send protocol）意思是用戶不同意這個群發協議，也許部分人應該會留意到，在剛剛申請的公眾號第一次使用群發功能時，需要同意一個協議，大家點同意就可以了。坑爹的事，測試公眾號沒有這個入口啊，我想同意也沒辦法同意啊。真是心累的。
四、添加客服時，不能添加頭像。
這個也是無力吐槽的設計上的問題，簡單說下吧。我不知道大家設計程序的時候習慣。在創建一個用戶或者一個客服時，我肯定會把用戶的用戶名，密碼，頭像等其他信息一個接口實現，因為這些都是基本信息（前台面向客戶的產品上可能會設置頭像或注冊會分開，可添加客服這功能有必要要分開設置嗎？），微信他們自己提供的后台再添加新客服的時候就是工號，昵稱，頭像，密碼等信息一起設置的，不明白為啥寫的接口是分開的，表示心塞的不行了。上圖看看：
五、微信支付相關接口
微信支付的坑不知道坑了多少碼農的時間（本來可以擼下其他的，卻不得不擼代碼），終於廢了九牛二虎之力解決了簽名錯誤的問題，感覺天都亮了。但當遇到js報fail時，感覺整個人都不好了。從簽名錯誤到chooseWXPay:fail（有的時候這個fail都不顯示，干脆沒任何反應，或者閃一下loading，就沒了），再到異步回調和js回調，真是一坑更比一坑深啊。運氣好的搞個三兩天搞好了（筆者前后調試了兩個晚上），運氣不好的恐怕要一個星期，還不一定能搞的定，最后很有可能會被某些眼高手低的技術領導或者不懂技術的老板嫌棄。心中又是一群神獸飄過，程序員何苦為難程序員呢。
還有一個大家可能很少遇到的情況，在微信支付的部分接口里出現了諸如****_$n的參數，如下圖所示：
我覺得這個真的要罵街了，微信支付使用的xml格式在進行簽名時，比較好的方法就是現創建對應的實體，然后進行下一步的簽名，獲取返回值時將xml轉換成對應的實體也方便進行開發。坑爹的是，這個$n符號讓咱怎么創建對應的實體映射，nnd，這個n還是不固定的。
六、微信支付相關配置
或許很多人在這里也跌了不少跟頭，明明代碼沒問題，完全按照文檔做的，什么預支付id之類的都獲取到了，js調用也沒問題，但就是不是fail錯誤就是沒任何響應，想想都記得抓狂。這里說下我遇到的幾個坑。
首先是授權目錄的設置，官方的說是是，加入你的支付目錄是http://www.cnblogs.com/a/a.aspx，那么授權目錄應該設置成http://www.cnblogs.com/a/，也就是發起支付的上一層目錄。以前在沒有用angularjs時，這個說法完全沒問題，用了angularjs才發現再一次被微信坑。用過angularjs做單頁程序的朋友應該都知道，每個頁面的切換其實只是切換了view，而頁面沒有真實的跳轉，只是根據#后面的信息來加載不同的view，如首頁的地址如果是http://www.cnblogs.com/index.aspx#/，那商城頁有可能就是http://www.cnblogs.com/index.aspx#/shop，支付頁面可能是http://www.cnblogs.com/index.aspx#/pay，正常的理解是這個授權目錄應該就是根目錄（http://www.cnblogs.com/），的確如此，在ios上沒有任何問題，可是在安卓的機器上就必須是http://www.cnblogs.com/index.aspx#/，假如你發起支付的頁面url是http://www.cnblogs.com/index.aspx#/a/b/c，那么你需要設置兩個授權目錄：http://www.cnblogs.com/index.aspx#/和http://www.cnblogs.com/index.aspx#/a/b/。
還有一個很難被發現的坑。說說我是怎么發現的吧。我的一個客戶做了一個商城，這個商城是使用一個認證了的服務號做的，並且開通了微信支付。付款什么都沒問題了，但他的需求是想讓他的訂閱號也可以有這個功能，我當時想的是這很簡單嘛，只需要將那個商城的鏈接搞過來就行了，從訂閱號里跳轉進來應該也是一樣的，支付的時候還是使用原有的服務號對應的商戶信息，邏輯上沒有任何問題。但之前聽說過不能跨號支付的問題，一直沒怎么理解，今天就測試了下。首先從服務號里訪問鏈接是可以正常支付的。然后我就試了下從訂閱號（未認證）里進入，結果報fail錯誤，然后覺得很奇怪，就到別從服務號進入，發現沒有問題可以正常支付，最后我又試了下從認證了的訂閱號進入，發現也可以正常支付（微博認證的報fail錯誤），那現在得到的結論是，微信支付不能掛在未認證的公眾號里。准確的說應該是微信網頁內支付接口是沒辦法在未認證的訂閱號中進行支付的。
七、終極bug，騰訊客服
說多了都是淚，每次發現微信的坑時，我總是天真的抱着一種拯救騰訊的思想去跟他們反饋bug，騰訊的客服總是很親切說一句：“請閱讀相關文檔”，那時，全世界的羊駝仿佛從我腦海里經過。哎，人艱不拆啊。
不過仔細想想是否是咱要求太高，人家免費給咱們用的東西咱是不是應該抱着寬容的心態來共同來創造未來呢？畢竟騰訊給了咱一眾碼農一個機會，用不了多久咱就會升職加薪、當上總經理、出任CEO、迎娶白富美、走上人生巔峰噠！