吐槽貼-微信公衆號那些讓人想起神獸的坑

       

　　  恍惚之間，距離上次寫博客已通過去差很少兩個月了。最近忙成狗，自從書出版後關注微信接口的時間就不多了，一方面，公司的事情實在太忙，如今是求生存的階段，只能一心紮在項目中。另外一方面，書發行後，好像忽然少了點繼續關注微信的動力，一種被微信折磨了大半年而後終於釋然的感受。最近也不多在羣裏說話了，但也一直關注着羣裏的動態。看着那些被微信一次次坑的體無完膚、茶飯不思的小夥伴，內心頓時一羣神獸（羊駝）飄過，但我有時也挺力不從心的，雖然他們問的問題我基本上都遇到過，大部分也都解決過，也都幫早進羣的夥伴解決過，但每次仍是有不少人絡繹不絕地問着重複的問題，回着回着就麻木了，由於好屢次都是回覆一樣的問題。也曾試着改變這種局面，個人作法是這樣的：首先提供一個能夠問問題的論壇，讓有問題的同窗把問題發到論壇裏，而後把帖子地址發到羣裏，而後我再去羣裏回覆，這樣下次再有人問相同的問題時，就能夠直接把連接地址發他了。但貌似絕大多數人仍是以爲麻煩，如今論壇也沒多少人氣了，也怪我本身沒有運營的經驗。

         額，貌似廢話有點多，開始講重點吧，這篇博客是在開發的過程當中一些比較常見的bug了，或者說是微信設計不合理的地方，我相信有不少人都想吐槽下微信，但我一直沒在園子裏看到相關吐槽的博客，鄙人不才，獻醜了。（這些只是目前我能想到的，以前遇到的坑基本上沒整理，之後儘可能都整理下，先發一部分吧。）。

1、素材管理中的修改永久圖文素材接口

這個接口其實不能說是bug，只能說是設計上的缺陷（從個人角度來看）。下面是此接口的文檔截圖：

 

從上圖能夠看出，要調用此接口，須要傳的參數有media_id（表示一條圖文的id），index（表示要修改的某條子圖文的索引），articles（表示的圖文實體）。表面上看上去沒什麼不對，修改一條圖文素材，須要傳一個素材的ID，這是毋庸置疑的，要修改哪條子圖文，那就須要把對應的索引傳了，貌似也沒問題，問題是修改的內容爲何要用articles呢，這裏已經寫了索引了，那就應該是article了，表示的是修改某條多圖文中的指定索引的自圖文。感受有點繞了吧。不要說我糾結，再仔細想一想，若是我添加多圖文消息時，添加5條子圖文，那麼我如今想修改這個多圖文，我想加一個，變成6條子圖文的多圖文，我發現這個接口沒法知足了，由於這裏要傳的參數有index（索引），找遍了全部文檔，也沒辦法解決這個問題。我也已經無力吐槽了。

2、上傳圖文素材後，不返回圖文url。

這個接口也是設計上的缺陷。你們用過微信圖文消息的應該都知道每一條多圖文的子圖文都包含n（n<=10）個子圖文，每一個子圖文都有一個對應的url（形如：https://mp.weixin.qq.com/…………），按理說添加圖文消息成功後，對應的url應該也已經生成了，但坑爹的是，當咱們調用完添加圖文消息接口時返回的信息卻只有一個media_id，若是您想獲取子圖文對應的url，則必須根據media_id調用獲取永久素材接口來進行獲取。獲取永久素材接口這裏還有一個大坑，你們能夠去試試看。新增圖文素材時每個子圖文都是須要一個縮略圖的media_id的（調用上傳圖片素材接口進行獲取的，形如DFJDFUIEUIURFEORHHz……之類的，反正就是一串比較長的字母數字組合），坑爹的話，當根據多圖文的media_id調用獲取永久素材接口時，每一個子圖文對應的縮略圖的ID神奇的編程了一串相似於時間戳的數字。坑爹至極。

3、測試帳號調用羣發無權限

這個絕對是個bug，相信確定也坑過很多人。 我記得以前這個接口是沒問題的，不知道從何時出現問題的。來講說具體的問題吧。因爲羣發這個接口在開發測試的時候不太方便使用運營中的公衆號，因此大多人都會選擇使用測試號來進行測試，但不知道從何時開始調用測試號的這個接口會出現申請的48003錯誤（user not agree mass-send protocol）意思是用戶不一樣意這個羣發協議，也許部分人應該會留意到，在剛剛申請的公衆號第一次使用羣發功能時，須要贊成一個協議，你們點贊成就能夠了。坑爹的事，測試公衆號沒有這個入口啊，我想贊成也沒辦法贊成啊。真是心累的。

4、添加客服時，不能添加頭像。

這個也是無力吐槽的設計上的問題，簡單說下吧。我不知道你們設計程序的時候習慣。在建立一個用戶或者一個客服時，我確定會把用戶的用戶名，密碼，頭像等其餘信息一個接口實現，由於這些都是基本信息（前臺面向客戶的產品上可能會設置頭像或註冊會分開，可添加客服這功能有必要要分開設置嗎？），微信他們本身提供的後臺再添加新客服的時候就是工號，暱稱，頭像，密碼等信息一塊兒設置的，不明白爲啥寫的接口是分開的，表示心塞的不行了。上圖看看：

 

5、微信支付相關接口

微信支付的坑不知道坑了多少碼農的時間（原本能夠擼下其餘的，卻不得不擼代碼），終於廢了九牛二虎之力解決了簽名錯誤的問題，感受天都亮了。但當遇到js報fail時，感受整我的都很差了。從簽名錯誤到chooseWXPay:fail（有的時候這個fail都不顯示，乾脆沒任何反應，或者閃一下loading，就沒了），再到異步回調和js回調，真是一坑更比一坑深啊。運氣好的搞個三兩天搞好了（筆者先後調試了兩個晚上），運氣很差的恐怕要一個星期，還不必定能搞的定，最後頗有可能會被某些眼高手低的技術領導或者不懂技術的老闆嫌棄。心中又是一羣神獸飄過，程序員何苦爲難程序員呢。

還有一個你們可能不多遇到的狀況，在微信支付的部分接口裏出現了諸如****_$n的參數，以下圖所示：

 

我以爲這個真的要罵街了，微信支付使用的xml格式在進行簽名時，比較好的方法就是現建立對應的實體，而後進行下一步的簽名，獲取返回值時將xml轉換成對應的實體也方便進行開發。坑爹的是，這個$n符號讓咱怎麼建立對應的實體映射，nnd，這個n仍是不固定的。

6、微信支付相關配置

或許不少人在這裏也跌了很多跟頭，明明代碼沒問題，徹底按照文檔作的，什麼預支付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錯誤），那如今獲得的結論是，微信支付不能掛在未認證的公衆號裏。準確的說應該是微信網頁內支付接口是沒辦法在未認證的訂閱號中進行支付的。

 

7、終極bug，騰訊客服

　　說多了都是淚，每次發現微信的坑時，我老是天真的抱着一種拯救騰訊的思想去跟他們反饋bug，騰訊的客服老是很親切說一句：「請閱讀相關文檔」，那時，全世界的羊駝彷彿從我腦海裏通過。哎，人艱不拆啊。

　　不過仔細想一想是不是咱要求過高，人家免費給我們用的東西咱是否是應該抱着寬容的心態來共同來創造將來呢？畢竟騰訊給了咱一衆碼農一個機會，用不了多久咱就會升職加薪、當上總經理、出任CEO、迎娶白富美、走上人生巔峯噠！