微信公眾號開發基本流程

背景：
過年前后做了個微信公眾號項目，已經過去一段時間了，抽空回憶總結下基本流程吧，不然很快估計自己就忘了。。

微信公眾平臺官網：https://mp.weixin.qq.com

---

文章目錄

• 一、注冊公眾號
• 二、了解公眾號管理頁面
• 三、必備開發者工具的使用
• • 1.開發者文檔
  • 2.在線接口調試工具
  • 3.web開發者工具
  • 4.公眾平臺測試賬號
• 四、細讀開發者文檔
• 五、開發流程重點解析
• • 1.開發環境準備
  • 2.服務器基本配置
  • 3.存取access_token參數
  • 4.公眾號消息管理
  • 5.獲取openid以及網頁授權（重難點）
  • • （1）先明確為什么需要網頁授權？我們的目的是什么？
    • （2）既然目的是獲取用戶基本信息，微信不是提供了專門的接口嗎？非要網頁授權？
    • • 微信平臺提供了兩種方式獲取用戶的openid
    • （3）網頁授權有哪幾種機制？分別是怎樣實現？應用于什么場景？
    • （4）想要進行網頁授權，我們需要在公眾平臺配置什么嗎？

---

一、注冊公眾號

首先注冊時可以看到公眾號有三種類型，個人用戶大多數選擇訂閱號，而企業用戶一般選擇服務號和企業號。

我們平常大多數關注的都是訂閱號，他們統一都放置在微信應用的訂閱號消息列表中，沒有微信支付等高級功能，只是用于發布文章等基礎功能。

而服務號和企業號都在會話列表，和我們的微信好友是同級別的位置，具備微信支付等高級功能，一般是某個企業品牌的對外操作窗口，如海底撈火鍋、順豐速運等。

我們前期開發測試只需要注冊個人訂閱號即可，真正開發使用的是開發者工具里的測試號，具體下面會說。

真正生產的話，使用的都是經過微信認證的訂閱號、服務號、企業號。

---

二、了解公眾號管理頁面

我們在微信公眾平臺掃碼登錄后可以發現管理頁面左側菜單欄有豐富的功能：

大概可以分為這幾大模塊：
首頁、功能、小程序、管理、推廣、統計、設置、開發

作為開發人員，首先應該關注的是設置、開發模塊；而作為產品運營人員，關注的是功能、管理、推廣模塊；作為數據分析人員，關注的是統計模塊。

首先我們不妨各個功能模塊都點擊看一看，大概了解下我們能做些什么?？梢源_認的是，這個微信公眾平臺當然不只是給開發人員使用的，它提供了很多非技術人員可在UI界面上交互操作的功能模塊。

如配置消息回復、自定義菜單、發布文章等：

這個時候我們可能會想：這些功能好像非技術人員都能隨意操作，那么還需要我們技術人員去開發嗎？

答案是： 如果只是日常簡單的推送文章，就像我們關注的大多數公眾號一樣，那確實不需要技術人員去開發；但是，如果你想將你們的網站嵌入進去公眾號菜單里（這里指的是把前端項目的首頁鏈接配置在自定義菜單），并且實現微信端的獨立登錄認證、獲取微信用戶信息、微信支付等高級功能，或者覺得UI交互的配置方式無法滿足你的需求，你需要更加自由、隨心所欲的操作，那么我們就必須啟用開發者模式了，通過技術人員的手段去靈活控制公眾號。

這里有一點需要注意，如果我們決定技術人員開發公眾號，必須啟用服務器配置，而這將導致UI界面設置的自動回復和自定義菜單失效！

我們在 開發 - 基本配置 - 服務器配置 中點擊啟用：


我們團隊就遇到過這種情況：兩個項目組共用一個公眾號，結果一個啟用了服務器配置，使另一個項目組手動配置的菜單失效了。所以要注意這點！

至于服務器配置中的選項代表什么意思、如何填寫，我們下面再講。

---

三、必備開發者工具的使用

我們進入 開發 - 開發者工具， 可以發現微信提供了六種開發者工具，其中前四種屬于開發必備：開發者文檔、在線接口調試工具、web開發者工具、公眾平臺測試賬號。

1.開發者文檔

這個不用說！在我們開發中屬于最最最基礎和重要的東西了，我們要想熟練開發公眾號，首先必須熟讀開發者文檔！有些功能的開發甚至非要反復研讀、咬文嚼字一番不可。PS：該文檔吐槽的地方也不少，有些地方的確講的不夠明確！

2.在線接口調試工具

這個工具也算比較實用，包含大多數接口的在線調試，我們可以直接在上面輸入參數，獲取微信服務端的返回結果。

3.web開發者工具

這個工具是一款桌面應用，需要下載，它通過模擬微信客戶端的UI使得開發者可以使用這個工具方便地在PC或者Mac上進行開發和調試工作，一般是前端使用該工具進行頁面、接口調試。

4.公眾平臺測試賬號

這個測試號工具對我們的重要性可以說是僅次于開發者文檔。我們可以創建測試號，無需申請、認證真實的公眾帳號、可在測試帳號中體驗并測試微信公眾平臺所有高級接口。并且所有的配置都可在一個頁面上編輯，使開發測試變得極其便利。

---

四、細讀開發者文檔

文檔地址：https://mp.weixin.qq.com/wiki

需要注意的是，細讀開發者文檔不是讓你所有模塊都去閱讀，而是重點的重復細讀，非重點的選擇性閱讀。

其中前兩個模塊：開始前必讀、開始開發，屬于重點關注對象，也是整個微信開發的基石所在，需要多讀幾遍。其次是微信網頁開發模塊的微信網頁授權，比較難理解，需要特別注意。其他的模塊則根據你們的項目功能需求，有選擇性的閱讀即可。

這里我就不多羅嗦了，大家看文檔去吧！下面我會描述一些重點內容的實際操作情況以及代碼，請確保你已經瀏覽過文檔。

---

五、開發流程重點解析

1.開發環境準備

這里所謂的開發環境準備主要指的是我們項目服務端和微信服務端的網絡通訊環境準備。

我們平常開發可能只需要IP端口就能通訊，頂多配置下白名單放行，但微信公眾號開發我們需要通過域名通訊（微信會訪問我們配置的域名地址：服務器基本配置中的URL，下面會介紹），也就是我們各自開發環境需要擁有獨立的域名，微信就能通過這個域名請求到我們的本地開發服務，各自進行開發測試。

而我們一般都是內網開發，整個內網只有一個對外域名，所以這時就需要 內網穿透 ，為我們每個開發人員配置各自開發機器的域名。

那如何進行內網穿透呢？你首先可以找下你們的網管，看他能不能幫你解決，如果不能，那就安裝內網穿透工具，我們自己動手！

我選擇的內網穿透工具是natapp，這個有免費版、收費版，免費版的域名會隨機變化，而收費版可以擁有固定域名，建議選擇收費版，9元每月并不貴；大家可以對照natapp的文檔安裝使用，并不難。

這樣我們本地開發環境就擁有自己的域名啦！然后就可以在測試號管理頁面配置本地訪問地址URL了。

2.服務器基本配置

無論是在真實公眾號的 開發 - 基本配置 - 服務器配置，還是在 測試號管理 中，我們都可以看到這幾個基本參數：
開發者ID(AppID)、開發者密碼(AppSecret)、服務器地址(URL)、令牌(Token)

AppID 是公眾號唯一開發識別碼，配合開發者密碼可調用公眾號的接口能力，大多數微信接口都需要附帶該參數。

AppSecret 是校驗公眾號開發者身份的密碼，具有極高的安全性。切記勿把密碼直接交給第三方開發者或直接存儲在代碼中。如需第三方代開發公眾號，請使用授權方式接入。其中獲取accessToken就需要同時傳入AppID和AppSecret獲取。

URL 是開發者用來接收微信消息和事件的接口URL，也就是我們服務后端的入口地址，需要注意的是該地址必須以域名形式填寫，且必須以http 或 https 開頭，分別支持80端口和443端口。如：http://yuanj.natapp1.cc/wechat。

Token 可由開發者可以任意填寫，用作生成簽名（該Token會和接口URL中包含的Token進行比對，從而驗證安全性），也就是我們項目和微信服務端進行通信時，必須保證公眾平臺配置的Token和我們后臺代碼配置的Token保持一致，這樣微信就能驗證我們身份。

注：EncodingAESKey 參數由開發者手動填寫或隨機生成，將用作消息體加解密密鑰，我們前期可以采用明文模式進行開發測試，暫時先不用關注。

我們點擊提交時，微信會以GET請求的方式訪問我們配置的URL地址，并附加幾個參數進行驗證，所以你需要在該地址對應的項目后端接口里對這幾個參數進行加工處理，返回微信需要的結果，這樣就可以驗證成功，使微信服務端認可你配置的URL和Token參數，后續就能互相通信了！

具體情況可以閱讀微信文檔 - 開始前必讀 - 接入指南。

這里附上該接口的Java代碼：

/*** 微信對接驗證接口* */ @RestController @RequestMapping(value = "/wechat") public class ValidateController {@AutowiredWechatConfig wechatConfig;@RequestMapping(value = "", method = RequestMethod.GET)public void validate(HttpServletRequest req, HttpServletResponse resp) {System.out.println("-----開始校驗簽名-----");// 接收微信服務器發送請求時傳遞過來的參數String signature = req.getParameter("signature");String timestamp = req.getParameter("timestamp");String nonce = req.getParameter("nonce"); //隨機數String echostr = req.getParameter("echostr");//隨機字符串// 將token、timestamp、nonce三個參數進行字典序排序并拼接為一個字符串String TOKEN = wechatConfig.getToken();String sortStr = sort(TOKEN,timestamp,nonce);// 字符串進行shal加密String mySignature = WechatUtils.shal(sortStr);// 校驗微信服務器傳遞過來的簽名 和 加密后的字符串是否一致, 若一致則簽名通過if(!"".equals(signature) && !"".equals(mySignature) && signature.equals(mySignature)){System.out.println("-----簽名校驗通過-----");try {resp.getWriter().write(echostr);} catch (IOException e) {e.printStackTrace();}}else {System.out.println("-----校驗簽名失敗-----");}}/*** 參數排序* @param token* @param timestamp* @param nonce* @return*/public static String sort(String token, String timestamp, String nonce) {String[] strArray = {token, timestamp, nonce};Arrays.sort(strArray);StringBuilder sb = new StringBuilder();for (String str : strArray) {sb.append(str);}return sb.toString();} }

3.存取access_token參數

access_token是公眾號的全局唯一接口調用憑據，公眾號調用各接口時都需使用access_token。開發者需要進行妥善保存。access_token的存儲至少要保留512個字符空間。access_token的有效期目前為2個小時（7200秒），需定時刷新，重復獲取將導致上次獲取的access_token失效。

access_token這個參數非常重要，幾乎貫穿整個微信公關號項目開發，我們如何在有效期內定時刷新獲取呢？
如果我們的微信公眾號項目是單服務架構，可以直接作為靜態變量存儲在內存里；如果是多服務，可以用中間件存儲，Redis、數據庫都可以。SpringBoot項目內部可以通過@Scheduled注解，執行定時任務，既然access_token有效期是2小時，那我們可以一小時刷新獲取一次，將其存入Redis，覆蓋之前的access_token。

4.公眾號消息管理

很多公眾號都可以通過消息發送來與其進行交互，那這樣的功能如何代碼實現呢？

具體我們可以在微信文檔 - 消息管理 模塊查閱：

在此我要提到的一點就 微信公眾號的消息交互都是通過XML格式進行的！這點就很坑了?！，F在我們前后端、服務端的消息傳輸基本都是Json格式了，也習慣了Json格式的解析處理，所以遇到XMl格式的處理又要多費些事了。

為什么微信采用XML格式呢？我個人猜測是幾年前還是XML格式的天下，當時Json還沒有這么流行，騰訊畢竟是產品業務驅動的，當然選擇當時開發人員最熟悉的XML格式了開發，后面隨著微信平臺的普及，用戶越來越多，想重構改成Json格式估計也十分困難，所以歷史就遺留下來了唄。。

我在此推薦一個GitHub上一個微信開發 Java SDK，里面有整個微信開發平臺很多功能模塊造好的輪子，我們可以參考下直接使用：
https://github.com/Wechat-Group/WxJava

比如現在對于XMl消息解析這個需求，上面就提供了完整詳盡的代碼。

5.獲取openid以及網頁授權（重難點）

注意，這是公眾號開發的重難點之一，請把技術文檔中的微信網頁授權模塊多讀兩遍，然后帶著疑問來看我的解析。

（1）先明確為什么需要網頁授權？我們的目的是什么？

答：用戶在微信客戶端中訪問第三方網頁，公眾號可以通過微信網頁授權機制，來獲取用戶基本信息，進而實現業務邏輯。也就是通過這種授權機制，我們能獲取微信用戶信息，比如：頭像、昵稱、地區、個性簽名等。

（2）既然目的是獲取用戶基本信息，微信不是提供了專門的接口嗎？非要網頁授權？

答：在文檔的 用戶管理 - 獲取用戶基本信息(UnionID機制) 模塊可以看到的確有獲取用戶基本信息接口：

可以看到，這個接口只需要提供openid或者unionid，即可直接獲取用戶基本信息。那么問題來了，openid（unionid）又是如何獲取呢？

微信平臺提供了兩種方式獲取用戶的openid

第一種方式：

用戶與公眾號產生消息交互時，會以POST請求的方式向我們配置的服務器URL地址發送XML格式的消息，并附帶該用戶對應公眾號的openid！關于什么是消息交互我們可以查看文檔中的消息管理模塊，比如我們在公眾號輸入欄中發送文字圖片語音等屬于普通消息交互，我們關注、取關、點擊自定義菜單等屬于事件消息交互，每當前端用戶進行這個操作時，微信服務端都會向我們項目后臺發送POST請求給我們傳達信息：

可以看到，這個推送數據包中就包含了用戶的消息交互類型、時間以及我們需要的openid！也就是說，無論用戶在公眾號里干了啥操作，我們都能知道他這個操作干了啥，以及他是誰（openid），這時就能調用 用戶管理 - 獲取用戶基本信息(UnionID機制) 接口獲取用戶基本信息了。

別高興太早，這種通過消息交互獲取用戶信息的方式，用戶占主動地位，我們項目后端服務被動接受，那么如果我有個基本需求：我想在自定義菜單 - 對應我們網站的前端頁面上展示微信用戶基本信息，能做到嗎？你如何把后臺接收到的消息和前端用戶關聯綁定？
可見，這種被動的方式并不能實現該功能，我們需要主動出擊，在前端就能獲取到當前操作用戶的openid！

第二種方式：

這種方式就是通過網頁授權機制主動出擊！詳情見下文。

（3）網頁授權有哪幾種機制？分別是怎樣實現？應用于什么場景？

答：主要有兩種機制，對應兩種scope：

以snsapi_base為scope發起的網頁授權，是用來獲取進入頁面的用戶的openid的，并且是靜默授權并自動跳轉到回調頁的。用戶感知的就是直接進入了回調頁（往往是業務頁面）。

以snsapi_userinfo為scope發起的網頁授權，是用來獲取用戶基本信息的。但這種授權需要用戶手動同意，并且由于用戶同意過，所以無須關注，就可在授權后獲取該用戶的基本信息。

光看這兩句解釋你可能有一堆疑問，我們逐一分析：

兩種機制的前面授權步驟相同，大概如下：

我們先要按照文檔要求構造一個鏈接：https://open.weixin.qq.com/connect/oauth2/authorize?appid=APPID&redirect_uri=REDIRECT_URI&response_type=code&scope=SCOPE&state=STATE#wechat_redirect
其中重點參數是redirect_uri，這個參數填的既可以是前端項目url，也可以是后端接口url，然后點擊這個鏈接后，微信服務端經過重定向到我們填寫的redirect_uri，會在此redirect_uri后拼接上一個code參數！然后前端或者后端通過code參數就可以調微信接口https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code獲取openid等信息了：

這里講下 snsapi_base 和 snsapi_userinfo 的不同點：

首先snsapi_base是靜默授權，什么意思呢？就是用戶沒有感知；與之對應的就是非靜默授權的snsapi_userinfo了，這個scope公眾號會彈出一個小窗口，需要用戶手動點擊授權，類似這種：

那么這兩種scope授權的優劣勢在哪呢？

snsapi_base 的優勢在于用戶無感知，體驗好，方便快捷；劣勢在于獲取openid后只能通過用戶管理 - 獲取用戶基本信息(UnionID機制) 接口獲取用戶基本信息，而這種方式需要確保用戶已經關注，不然是沒有相關信息的！
snsapi_userinfo 的優勢在于無需用戶關注公眾號，只要用戶點擊了授權確認，即可通過access_token和openid調用專門的拉去用戶信息接口獲取信息，比較暴力。。；劣勢在于需要用戶手動授權，可能影響用戶體驗。

在此說下，我們項目是通過snsapi_base靜默授權的，其中redirect_uri配置的是前端項目首頁地址（前后端分離），并將構造的這個鏈接封裝起來，直接配置在自定義菜單里，那么用戶點擊菜單，就直接重定向到前端項目，然后前端獲取code參數調用后端獲取openid接口，將獲取的openid緩存到客戶端，以便后面使用。

（4）想要進行網頁授權，我們需要在公眾平臺配置什么嗎？

答：需要！
如果是測試號，需要在 測試號管理 - 體驗接口權限表 - 網頁服務 - 網頁帳號 點擊 修改。


在這里配置的是回調頁面即redirect_uri的域名！

如果是正式號（需要微信認證），需要在 開發 - 接口權限 - 網頁服務 - 網頁帳號 - 網頁授權獲取用戶基本信息 的配置選項中，修改授權回調域名。請注意，這里填寫的是域名（是一個字符串），而不是URL，因此請勿加 http:// 等協議頭；

而且正式號其他配置的地方也和測試號不一樣，比如多了IP白名單、域名根路徑下的txt驗證文件，這個稍微摸索下應該沒啥問題的。

---

over 暫時就回憶這么多了。。?？赡苡羞z漏大家可以提出哈 ~ 下一篇博客寫幾個開發時的小問題補充下吧