静态博客文件头&Typecho邮件发送&图床问题

（一）静态博客文件头问题

在2019年4月6日发表的《静态博客搭建方法》中，我曾提到，主流的静态博客系统Jekyll、Hexo、Hugo是互相高度兼容的。Jekyll、Hexo针对markdown文档的格式是100%兼容，Hugo则有个别地方不兼容。例如，Jekyll和Hexo的:title在Hugo中对应的是:slug；Hugo需要在date里标注时区。

为了保证静态博客之间互相迁移时不出现问题，我建议在静态博客写作时，对文件头格式进行兼容。常见的文件头格式包括title、date、categories、tags，我建议再增加slug，以便迁移到hugo时能够不改变文章的永久链接，除非你给每篇博文都使用了permalink参数来自定义永久链接。

个人建议的文件头格式如下：

title: 题目
date: 2019-04-25 10:20:00+0800
categories:
- 分类
tags:
- 标签1
- 标签2
- 如果有更多标签，按格式添加
slug: ti-mu

可以在文件头中使用permalink参数来自定义永久链接，强烈建议使用相对路径；如果不需要评论，使用comments: false；如果不需要使用主题的页面格式，而是自定义，使用layout: false，然后在md文档的正文中来写有关的css、js等定义页面格式和有关的页面外观。更多的文件头参数，可参见静态博客程序的官方文档；部分主题模板也有自定义的参数，可见模板的官方文档。

（二）Typecho邮件发送问题

Typecho目前有三个SMTP邮件发送插件，按发布的时间顺序排列，分别为：CommentToMail、LoveKKComment、Comment2Mail。用户在安装插件时，通常会先安装第一个。

有些博主安装第一个插件后，发送邮件可能会失败。再安装后面的插件则成功了，于是认为是插件问题。这个思维没什么问题，换做我，也会直接这么想。后来有一天，给主机进行维护时，我发现，插件在背锅。最近，经过多次测试，我认为，如果出现这种情况，很有可能不是插件的锅。

在使用插件之前，我们要选对邮箱。这几个插件都依赖一个库：PHPMailer。这个库，对邮箱的安全性要求较高。境内的电子邮件服务商中，QQ邮箱广为人知。但据网友反映，QQ邮箱的安全性低，无法达到PHPMailer的要求，邮件不会发送成功，我也亲自试验过，确实不成功。腾讯域名邮箱，是QQ邮箱内的功能，因此安全性同样不达标，我也试验过。网易邮箱安全性达标，但对发送频率做了限制。海外的Outlook、Gmail这些可以满足要求。我推荐腾讯企业邮箱、Zoho商务邮箱（国际版和境内版只有数据存储位置的差别，带来的其他差别你懂的）和Yandex。

下面，我简单叙述对三个插件进行测试的过程。我建立了三个typecho博客，已启用我常用的一些其他插件。

我测试所使用的主机是VPS。运行环境：PHP 7.2，Centos 7.3。邮件服务商：腾讯企业邮箱。分别给三个博客后台上传CommentToMail、LoveKKComment、Comment2Mail这三个插件。这三个插件中，每个博客第一次启用的插件均不同。分别启用插件后，进行有关信息的配置。经确认，信息输入无误。对LoveKKComment进行配置时，如果发现网页卡死、崩溃，按照这篇文章（点击查看）的方法进行操作。

接下来，分别在三个博客进行几次的评论和回复评论操作，每次间隔3分钟。这时候发现，这三个博客都没有发出我们想要的邮件。CommentToMail有个邮件发送测试功能，通过这个功能可以发出邮件，但评论和回复评论的邮件没有发出。

登录腾讯企业邮箱账号，在已发送—登录查询—最近30天登录记录中，可以看到“esmtp登录”的记录，还有类似于“(20:15到22:17，共15次)”这样的文字。这就说明，插件连接腾讯企业邮箱没有问题。

在三个博客分别禁用这三个插件，再启用另外两个插件的其中一个，三个博客分别启用不同的插件。再次重复上述操作。结果：三个博客的邮件发送均成功，收件人收到了相应的电子邮件。

接下来，在三个博客分别禁用这三个插件、启用之前的那个插件。重复上述操作。结果：三个博客的邮件发送均成功了。

为了验证这个测试结果的准确性，我将Apache换成Nginx，然后再换回Apache，或者更换PHP版本（均在5.6以上），另外还在虚拟主机上面重复测试。结果均是如此。每次更换运行环境时，各个博客均在删除文件、数据库后重装。

综上得出结论：无论这三个插件中的哪个最先安装，都可能存在邮件无法发出的问题。但，即便是PHPMailer版本相对较老的CommentToMail，也是能成功发送邮件的。这个插件如果安装在PHP 5.5及以下版本的主机上，后台的配置界面会变形，但不影响邮件发送。

当然，还是有很多人，在使用支持SMTP的虚拟主机或VPS上，第一次安装插件就能正常发送邮件。

再顺便说一下：后两个插件发出的邮件，在手机端查看时，发现页面无法自适应。这是因为它们发出的邮件不支持自适应。这个邮件的页面是可以修改的：LoveKKComment在四个html文件中；Comment2Mail在plugin.php中。如需修改，可参照第一个插件的邮件模板（位置：博客后台—控制台—评论邮件提醒—编辑邮件模板）进行模仿。

三个插件的下载地址如下：

• CommentToMail：https://github.com/visamz/CommentToMail
• LoveKKComment：https://github.com/ylqjgm/LoveKKComment
• Comment2Mail：https://gitee.com/HoeXhe/typecho-Comment2Mail

（三）图床问题

在2019年4月23日晚，开始有博主反映“新浪图床”防盗链了，部分博主遇到了上传到新浪图床的图片无法显示的问题，有博主开始替换图片。随即我提醒十年之约的成员，如果使用了新浪图床，请注意你的博客。当时，没人相信我说的话。4月24日，这一现象蔓延到了几乎所有使用新浪图床的博主身上，此时他们蒙圈了。

在这里我不得不夸自己有先见之明（斜眼笑）。其实这种先见之明是建立在已有的经历上。博客重建的时候，为了防止再经历2013年9月17日的意外，我决定将图片存储在第三方专业图床。可惜，某防线越建越高，一切的拦截“规则”均不透明、不公开、不可预知、变化无常。本博客引用的图片，也因此，于2017年9月2日上午开始，在某地区全部无法显示。因为我没有使用互联网的特殊技术手段，所以我无法从图床取回图片。由于没有备份（然后懂得了备份的重要性），部分图片就这样没了，部分图片我重新找来原图进行填补。

目前，我保存图片的方法是，在静态存储服务中开设存储仓库，通过浏览器在线上传图片，在接入全球CDN之前，使用其pages服务绑定的域名进行访问。图片所在的文件夹结构与目前使用的Typecho程序的附件路径结构完全相同，可以保证随时迁移回主机后台，并通过一条SQL命令一键替换所有的图片链接。2019年5月1日，我通过这种方式，帮助@汀彵の汐 博主搭建了一个图床。先帮助她把新浪图床的图片拉入本地，再导入图床。不过，因怕她不会用，我没有把她的图床的目录结构设计为Typecho程序的附件路径结构。

为了保证不浪费免费资源，并提高图片加载速度，我把每张图片都进行了高强度压缩，有不少图片从2M左右压缩到了200 KB以下，甚至几十KB。并且，为了减少对公共资源的计算能力及带宽的消耗，我给图床接入了全球CDN，由CDN存储全部数据，并全球分发，不再使用静态存储服务的pages服务。

备份图片时，在浏览器中访问自己的仓库，在线“打包下载为zip”，就可以下载到本地了。

当然，在未来，我可能会在博客引用一些视频数据。目前已经注册了Amazon S3，这部分视频数据我会上传到此。

我知道肯定会有人推荐什么oss、cos、七牛云、又拍云这些。这些我都用过。在不考虑SMRZ和信息泄露的各种风险的情况下，我觉得这些服务当中又拍云的服务最好，因为支持FTP方式管理文件，我可以使用开源软件FileZilla的Linux客户端进行图形化文件管理，不存在其他的对象存储服务针对非程序员群体“上传容易下载难”的现象。目前，账号也都在那放着呢，因为七牛云、又拍云等账号是无法注销的。另外，还有一个问题需要考虑：的对象存储服务规则难以控制，已经发生的事情非常明显的表明，服务规则的变化会导致用户陷入被动。其中之一便是测试域名问题：目前提供测试域名且测试域名支持https的服务中，未来不一定什么时候出现像七牛那样回收测试域名，或者像又拍云那样关闭测试域名的https。

我不针对谁，只是泛泛而说：某些人，你可以把你全部的图片、视频等放在的对象存储，你也许有能力用命令行工具批量管理他们，但这不是你秀优越的资本。无论每个博主用什么方式存储图片，都是个人选择，没有优越感可言。请不要秀你那自以为是的优越感，这只会刷低你的人品下限。