静态博客本身是无法支持评论的，因为没有服务端程序接收请求，只能求助于系统外的服务。大概搜了下，选取几款主流评论系统Disqus/Talkyard/Staticman/Gitalk/Vssue作为PK候选人。
由于第三方服务的域名肯定和博客的域名不一样（当然你也可以把评论系统部署在同一个域名下），评论系统首先要解决的是跨域请求问题，禁止跨域请求是浏览器的一项安全策略。现在实现跨域请求的方式有很多种，本质上是要目标服务器同意才能实现，这很好理解。
对技术选型来说不是大家说好就是好，到底好在哪儿？就算是真的好，适不适合当前的需求？下面从几个维度来比较这几个评论系统
官网 
：号称第一的评论系统，官网显示每个月接收五千万条评论，但国内加载缓慢，官网也打开困难。实现方式没什么亮点，由于是自己的程序，自己的服务器，这类评论系统的重心放在了精细（花哨
）的功能上。
价格比较高大上，分成几个档次
详情参见Pricing
评论直接发送到Disqus服务器，所有的数据和服务都在第三方，评论者需要注册Disqus账号。
提供全套JS，CSS，开箱即用，不操心。
支持互动功能，threaded comments：
评论框直接GIF搜索，右上角是折叠评论，拉黑，举报，够丰富吧
官网 ：比Disqus更轻量并且开源，也是自己独立的系统，方便实现各种功能。综合各方面真是业界良心
由于是开源的，如果你有自己的服务器就可以免费部署在上面。如果嫌麻烦就用Talkyard提供的服务，当然就要付费了
Talkyard的定价分得很细，为了照顾到不同的群体主要分三大类，下面又根据不同的条件再细分成子类
详情参见Plans
评论直接POST到Talkyard服务器，数据在第三方，评论者需要Talkyard账号。
常用功能都有，并不比Disqus逊色：
专门适配手机的评论框：
电脑版评论框，左边输入右边即时预览：
后台管理页面也不差喔：
并且还支持添加自己的Javascript插件，比如MathJax或Prism.js用于语法高亮。
全套提供JS，CSS，开箱即用，不操心。
还没想到
官网 ：和上面两种评论系统有本质不同，它在你的repository上做文章，思路很巧妙，就像螺蛳壳里做道场。当然，就会有很多掣肘不能像上面的系统随心所欲。
自己搭建服务器FREE，使用它提供的服务FREE。
但其实只能自己搭建服务器，这和它的实现方式有关，请继续往下看。
Staticman收到你的评论请求后，用它的GitHub账号调GitHub API把评论提交到你的repository。所以需要添加它的GitHub账号到你的repository并赋予写权限。
现在的问题是如果大家都用它提供的服务（相当于都是同一个GitHub账号调API），很容易就达到GitHub每天每账号5000次API调用的限制，各部署各的Staticman服务器就没这些问题。
浏览了下Staticman GitHub主页，作者准备改成APP的方式，基本能解决调用次数限制的问题。
自由度最高，它只commit yml格式（可指定）的评论到你的repository的_data/comments/文章名目录（可配置），剩下的不管了
评论是repository的一部分，很容易迁移，数据整体性最好。
如果激活评论审核，Staticman将会发起pull request，同意就merge到branch，不同意discard这个pull request就是了。
评论者不需要任何账号就能评论。
配置文件里暴露的所有API Key和密码都是RSA公钥加密的。
下面两篇文章使用Staticman的方式很聪明，有兴趣的同学可以深入研究下：
Improving static comments with Jekyll & Staticman
Hugo + Staticman: Nested Replies and E-mail Notifications
）
官网 ：使用Preact开发并利用了GitHub的Issues功能，是一个非常聪明的思路。
免费
每篇文章对应一个Issue，通过两个Label来匹配：Gitalk和文章唯一ID，当前文章的所有评论都在这个Issue下面。Label是可以自定义的，默认配置是labels: ['Gitalk']，那我们可以定义一个更通范的名字让Issue可以和其它评论系统共享，比如Vssue。
评论者新加评论的时候，先OAuth登录授权给GitHub Apps，JavaScript code就代表你添加评论到对应的Issue下面。
注意现在Label有50个字符的限制，中文标题编码后很容易超过，可以用下面这段代码：
1
2
3
4
5
var issueLabel = decodeURI(location.pathname);
...
//Ensure uniqueness and length less than 50
id: issueLabel.length > 50 ? issueLabel.substring(0,50) : issueLabel,
...
GitHub Issue body里文章中文链接显示编码的问题，继续做了个小改进：
1
2
3
//GitHub issue content
body: decodeURI(location.href) + '\n\n'
+ document.getElementsByTagName('meta')['description'].content,
GitHub OAuth登录的时候有callback URL验证，我认为不用担心暴露Client ID和Client Secret。
分页加载评论：
评论列表动画：
支持Markdown语法，全屏遮罩效果，太酷了
：
评论预览：
评论管理功能也具备，GitHub Issue本身提供了：
提供全套JS，CSS，开箱即用，也不操心。
官网 ：作者的灵感来自于Gitment和Gitalk ，基于Vue开发。和Gitalk的实现思路一样也是利用了GitHub的Issues功能，但各有所长。
同样免费
查找对应Issue的方式不同，根据Issue Title和Issue Label Vssue查找。但要给Title强制加个前缀[Vssue]
而Gitalk是和Title无关的，那么要想我们的Issue兼容这两个评论系统，一种思路是：
当然，也可以写段程序自动化上面的步骤。
PS感谢Vssue作者的指正
Label和Title前缀是可以自定义的，默认配置是prefix: '[Vssue]', labels: ['Vssue']，那我们可以定义一个更通范的名字让Issue可以和其它评论系统共享，比如Gitalk。注意，Label不要有空格，不然Vssue找不到Issue。更多配置请参见这里 。
1
2
prefix: '',
labels: ['XXX']
灵感来自于文西的集合十种杀人武器于一身的超级武器霸王，亲测有效请看About
支持多个代码托管平台，包括 GitHub、GitLab、Bitbucket、Gitee和Gitea，相当于5in1，不同的平台需要引入不同的JS。
可以在博客页面内编辑和删除评论，而不用跑到GitHub Issue去操作自己的评论，同时还能比心、喜欢和不喜欢，非常不错
在顶部，评论者可以选择每页加载数量和页数跳转。
也是提供全套JS，CSS，开箱即用，不操心。
上次更新: 2020-02-18