經過兩個多月的開發，一個微信第三方應用在我手上逐漸成形，下一階段進入測試和上線階段。剛開始的一無所知，認為其很是高大上，到了現在回頭看看，卻也沒見得有太復雜的東西，但是爬過的那一個個坎現在都記憶非常深刻，開發微信第三方應用，其主要分為兩個部分，授權部分和業務部分，業務部分的調用過程都需要授權部分所拿到的授權令牌，那我慢慢講述。

一、授權部分，在授權的過程中需要對微信沒十分鐘推送的信息進行AES解密，得到ticket數據， 隨著通過調用微信接口拿到componenttoken，這樣反復取到數據有返回調用他的借口拿到新的授權數據，這麽一個流程在最後一步的時候會是拼接出一個url，這個url會根據你傳入的參數生成一個二維碼供管理方進行掃碼授權，當掃碼通過後悔跳轉到我們在url中配置的回調url，問題在於當時並不知道，這個url必須是生成在配置的域名下，並且附加參數會在掃碼之後在回調的url後面拼接出來給我們，為此我請求多路大神，決定將回調的url寫成接口，當掃碼跳轉之後我便通過在掃碼跳轉觸發調用接口後在http請求頭中拿到相關信息。

二、業務中，未保證各部分穩定性，需要細分成三個工程，callback處理部分，上架部分，還有補倉部分，callback主要是接收用戶支付成功或者領取成功後微信給我們推送過來的相關通知，為了保證數據和微信方的一致性，方便以後額雙方對賬，為此通過相關訂單查到的信息我們必須在我們自己的庫中進行保存存檔，後來公司財務反映導入自身的支付碼給微信具有安全不可控性，這對上上市公司會有要求，為此我們在保存數據的基礎上再加上了激活動作，只有激活後用戶才能夠正常使用商品。當然，在這一部分還要開發一套能兼容多個產品的兼容性代碼上架產品其實可以通過main方法直接調用接口進行，其主要麻煩點在於json結構體太過復雜，難於拼接，並且在更新貨架的時候需要帶上所有產品參數，不然的話新上傳的產品直接覆蓋之前的產品，這一點我認為微信放需要對接口進行改進及其退貨申請、發票申請一些簡單的能夠兼容多個產品的html5頁面，其主要難點在於每個品牌令牌是不一樣的並且在很短時間內會進行更新變化，而調用微信段接口都需要此令牌，難點在此。補倉部分，則是通過定時調度的方式，每隔一定時間就是輪詢執行調用微信接口查詢庫存情況，如果不足則需要從我庫中取出數據對微信端進行導入。

這樣回頭看看所做的部分其實並沒有太多困難的地方，但是在開發的時候還是會遇到很多問題，畢竟菜鳥一枚，作為幾乎全是接口調用的一個部分，我認為和接口提供方做到充分溝通是很有必要的，並要有一份詳細的接口文檔，快速發現問題，這樣才能夠加速開發進程。

記微信第三方應用開發所遇到的坎