摘要：什么是第三方評論系統博客或系統，一般都是有內容和評論兩部分組成。而且垃圾評論和過濾非法關鍵字難度較大，所以在國內外都有第三評論系統。三評論系統實現預備工作創建。

本文只是介紹如何基于 github issues 實現第三方評論系統，對于 Hexo 介紹，本文并不打算詳述，如果有童鞋之前還沒有了解 Hexo 的，可以先看一下之前文章《靜態博客框架 Hexo 入門 》，或者直接訪問 Hexo 官網 https://hexo.io/

個人博客是基于靜態博客系統（Hexo）搭建的，本身是沒有具備任何后臺功能的，例如搜索、評論系統等。但是，如果你想在靜態博客上加上評論功能，也不是無法實現的，這時候就要借助第三方評論系統了。

什么是第三方評論系統？博客或 cms 系統，一般都是有內容和評論兩部分組成。評論可以增加博主與用戶之間的交流互動，也是博主一對多的傳達自己想法和觀點的交流平臺。所以除了社區平臺外，評論也成為一般博客和cms系統必備功能。大型網站本身自己開發了評論系統和分享系統，而一般中小型網站開發的自己的評論系統，成本高。而且垃圾評論和過濾非法關鍵字難度較大，所以在國內外都有第三評論系統。以下是曾經流行或者正在流行的一些第三方評論系統。

多說。多說是一款追求極致體驗的社會化評論框，可以用微博、QQ、人人、豆瓣等帳號登錄并評論。多說已經成為國內份額最大的所謂“社交評論框”服務，但是這個行業第一并沒有給它帶來更多的收益和發展空間。不過可惜，現在已經停止服務了。

搜狐暢言。搜狐暢言是由搜狐推出的一個簡單而強大的社會化評論及聚合平臺。用戶可以直接用自己的社會化網絡賬戶在第三方網站發表評論，并且一鍵評論同步至社交網絡將網站內容和自己的評論分享給好友。增加第三方網站用戶活躍度，調動好友參與評論，幫助網站實現社會化網絡優化，有效提升網站社會化流量。現在還健在。

友言。友言是國內專業的第三方實時社會化評論系統，“完全社交化”可將評論一鍵同步到各大微博與社區（目前支持10個社交媒體），同時將評論的回復與跟帖同步至使用的網站上，讓網站變得更具有活力和社交性，從而為網站帶來更多的回訪和流量，是一個簡單而強大的社會化評論及聚合平臺。現在還健在。

網易云跟帖。網易云跟貼是網易公司推出的強大而又簡單的評論聚合與分享平臺。坑爹的，在多說發布停止服務聲明之后不久，網易云跟帖也分出了停止服務聲明。

Disqus。說到第三放評論系統，當然不得不提國外第三方評論系統界的老大 Disqus，只可惜由于天朝網絡原因，Disqus 加載很慢，甚至有時候加載不出來，建議用戶自備梯子。

那么回歸主題，市面上那么多第三方評論系統，就算有那么一兩個掛掉了，還是有很多選擇呢，為什么還要自己去做一個呢，這不是造輪子嗎？其實，一開始我一直用多說的，用的不亦樂乎，突然有一天說掛就掛了，沒辦法，那我就選擇其他的唄，然后就改成網易云，坑爹的，剛改造好沒多久，網易云也掛了。

后面我就在網上找啊找啊，發現居然有人用 GitHub Issue 做了一個評論系統，這無疑是一個很好的想法，很有創意啊。當然，我也拿來用了，但是始終覺得有點丑，跟我自己的博客主題不搭，才用了兩天，撤了，打算自己做一個。說干就干，程序員總喜歡造輪子。

經常逛 GitHub 的童鞋，都應該知道這個功能，有人理解 GitHub 的 issue 功能，就如同 TODO list。你可以把所有想要在下一步完成的工作，如 feature 添加、bug 修復等，都寫成一個個的 issue ，放在上面。既可以作為提醒，也可以統一管理。另外，每一次 commit 都可以選擇性的與某個 issue 關聯。比如在 message 中添加 #n，就可以與第 n 個 issue 進行關聯。具體可以看一下知乎里面別人對 《github issue是做什么的？ 》的解答。而本博客的評論數據存儲 issues 倉庫地址為 https://github.com/jangdelong/blog_comments/issues，倉庫里面并沒有放置托管代碼。總之，像我現在要用 github Issues 來制作評論系統的，其實就是把數據存儲到 github issues，簡單的說可以把 github issues 理解為一個免費的數據庫。

預備工作

創建 OAuth applications。評論需要涉及 GitHub 授權登錄，所以在這里你先要有一個 GitHub application。GitHub 授權登錄遵循 OAuth 2.0 標準。OAuth applications 創建如下圖所示，填寫上面相應的內容。

Application name：你的站點名稱；
Homepage URL：你的站點主頁鏈接；
Application description：站點描述；
Authorization callback URL：GitHub 授權成功后返回地址

創建成功之后會生成一個 Client ID 和一個 Client Secret。

GitHub REST API v3

GitHub 提供了很多方便第三方開發的 API，當然，github issues 的增刪改查 API 也在其中，有了這些 API，你才能各種施展奇技淫巧，比如我們現在要寫的評論系統。另外，有人懷疑我們應不應該“濫用”這些 API，但是，個人覺得，既然，GitHub 提供了這些 API，就是說明要開放給大家這些權限，應該就不怕你“濫用”。那么，要滿足我們現在的需求需要哪些 API 呢，下面我列舉一下，以我的賬號為例，jangdelong 為 Github 名，blog_comments 為倉庫名。

GET: https://api.github.com/repos/jangdelong/blog_comments/issues 獲取所有issues信息

GET: https://api.github.com/repos/jangdelong/blog_comments/issues/11 獲取某個issue下的信息 （11 為 issue 編號 ）

GET: https://api.github.com/repos/jangdelong/blog_comments/issues/11/comments 獲取某個issue下的評論

GET: https://api.github.com/repos/jangdelong/blog_comments/issues/comments/111/reactions 獲取評論 ID 為 111 下的所有 reactions（reactions 包含頂[+1]、踩[-1]、喜歡[heart]等字段）

POST: https://api.github.com/repos/jangdelong/blog_comments/issues 創建一個 issue

POST: https://api.github.com/repos/jangdelong/blog_comments/issues/11/comments 在編號為 11 的 issue 下創建一條評論

POST: https://api.github.com/repos/jangdelong/blog_comments/issues/comments/111/reactions 在 ID 為 111 的評論下創建一條 reactions（如 heart）

POST：https://developer.github.com/v3/markdown/ markdown 語法解析接口

整體設計

流程圖：

                                             |--> 顯示已登錄    
                              |--> 已登錄 --> |--> 加載評論列表 --> 分頁加載 
                              |              |--> 其他 
                              |              |--> 評論操作 --> 成功/失敗            |
 開始 --> GitHub 授權登錄 ? --> |                                                   |--> 結束
                              |              |--> 顯示未登錄                       |
                              |--> 未登錄 --> |--> 加載評論列表 --> 分頁加載          
                                             |--> 其他
                                             |--> 評論操作 --> 提示未登錄狀態

效果圖：

因此，我們可以將評論系統分為列表（list）、評論框（box）、頂部登錄狀態欄（signbar）等部分。View 部分的代碼組織為：

// 為了減少全局變量，整個網站就暴露一個全局變量 JELON
var JELON = JELON || {};
;(function (JL) {
    ...
    JL.Renders = {
        // 列表模塊
        list: {
            tpl: ...,
            ...
        },
        // 評論框模塊
        box: {
            tpl: ...,
            ...
        },
        // 頂部登錄狀態欄
        signBar: {
            tpl: ...,
            ...
        },
        ... // 其他模塊視圖
    };
    ...
})(JELON);

視圖部分的代碼組織好之后，根據 GitHub 提供的各種 API，我們將其封裝到 Requests 里面去，組織如下：

// 為了減少全局變量，整個網站就暴露一個全局變量 JELON
var JELON = JELON || {};
;(function (JL) {
    ...
    JL.Requests = {
        // 根據 label 獲取 issue 編號
        getIssueNumberByLabel: function () { ... },
        // 創建 issue
        createIssue: function () { ... },
        // 根據 issue 編號獲取評論列表
        getCommentListByIssueNumber: function () { ... },
        // 根據評論 ID 獲取 reactions （即點贊數據）
        getReactionsByCommentId: function () { ... },
        // markdown 解析
        markdown: function () { ... },
        // 通過 code 獲取 access_token
        getAccessToken: function () { ... },
        // 利用 access_token 去獲取 GitHub 用戶信息
        getUserInfo: function () { ... },
        // 創建評論
        createComment: function () { ... },
        // 創建 reactions （點贊）
        createReaction: function () { ... }
    };
    ...
})(JELON);

接下來是封裝事件操作，我們將其封裝到 Actions 里面去，代碼組織如下：

// 為了減少全局變量，整個網站就暴露一個全局變量 JELON
var JELON = JELON || {};
;(function (JL) {
    ...
    JL.Actions = {
        // 初始加載，如列表、登錄狀態等
        init: function () { ... },
        // 登出操作
        signOut: function () { ... },
        // 列表翻頁跳轉
        pageJump: function () { ... },
        // 編輯預覽
        editPreviewSwitch: function () { ... },
        // 提交評論操作
        postComment: function () { ... },
        // 點贊操作
        like: function () { ... }
    };
    ...
})(JELON);

程序入口：

// 為了減少全局變量，整個網站就暴露一個全局變量 JELON
var JELON = JELON || {};
;(function (JL) {
    ...
    JL.Comment = function (options) {
        JL.options = options || {};
        $("comments").innerHTML = [
            this.Renders.signBar.tpl,
            this.Renders.box.tpl,
            this.Renders.tips,
            this.Renders.list.tpl
        ].join("");
        JL.Actions.init();
    };
    ...
})(JELON);

登錄流程

GitHub 授權登錄是不可或缺的功能，用只有登錄之后才能進行評論。前面有提到，GitHub 授權登錄是遵循一個 OAuth 2.0 標準。以下是 OAuth 2.0 的一個運作流程，可以讓我們更好的理解它。

那么，GitHub 授權登錄是怎么樣按照這個標準來運作的呢，接下來簡單介紹一下，如果要更加詳細深入了解的話，你也可以訪問 GitHub 官方文檔。

用戶發起重定向請求授權服務器換取 code

`GET http://github.com/login/oauth/authorize`

拿到 code 之后，利用 client_id、client_secret 和 code 去換取 token_access。（client_id 和 client_secret 前面的預備工作里有提到）

`POST https://github.com/login/oauth/access_token`

獲取到 token_access 之后，我們就可以用 token_access 去獲取已登錄的用戶的信息了

`GET https://api.github.com/user`

通過以上3個步驟，GitHub 授權登錄就算是完成了。

引入評論系統相關的 css、js 。引入相關樣式和腳本之后，在你的頁面加入以下代碼：

由于這個評論系統是要集成到個人的主題上去的，所以要跟 hexo-theme-xups 搭配使用，hexo-theme-xups 主題鏈接為 https://github.com/jangdelong/hexo-theme-xups，目前最新的主題（帶有GitHub 登錄評論功能），后面會更新上去，往后當然也會陸續進行更新和優化，歡迎多多 star。

遇到的問題主要有三個，一個是創建 label 權限問題，一個是跨域問題，另外一個 GitHub 授權登錄兼容性問題。

創建 label 權限問題（目前未解決）。label 是一個連接文章和 issue 關系的紐帶，因為我們要用 label 去查詢 issue number，后面的流程才能走下去。如今遇到的問題是，對于新文章來說，只能是我自己本人賬號（GitHub Application）創建者才能創建帶有 label 的 issue。參考了 GitHub 的接口（POST /repos/:owner/:repo/issues）文檔，上面說

> Labels to associate with this issue. NOTE: Only users with push access can set labels for new issues. Labels are silently dropped otherwise.

跨域問題（暫時解決了）。主要是通過 code 去換取 token_access 的 POST https://github.com/login/oauth/access_token 這個接口跨域，暫時解決方案是
使用 https://cors-anywhere.herokuapp.com/https://github.com/login/oauth/access_token 進行轉發。參見：https://github.com/Rob--W/cor... 。

GitHub 授權登錄兼容性問題（暫時不解決）。經過簡單的測試，發現 PC 端兼容性問題主要是一些老版本的瀏覽器，其中包括一些老版本的谷歌瀏覽器（版本號55.x.xxxx.xx）；而移動端的主要是 UC 瀏覽器無法實現 GitHub 授權登錄。