多谢几位的答复，现在综合几位朋友的建议回答下自己的问题，给后来人做参考，希望能让你们少走些弯路（反正我对代码是一点不懂，对各位工程师大牛来说，这根本不值一提，可我摸索了好久，痛苦。。。）：
修改footer.swig文件（有的扩展名是.ejs），路径存放博客文件夹/themes/next/layout/_partial，在</span>跟</div>之间（这个位置可以确保备案号放在网站作者后面主题信息之前，详见下图）加入以下代码
<a href=https://www.zhihu.com/topic/20036297/"http://www.miitbeian.gov.cn/">粤ICP备14057991号</a>
备案号请自行修改
@Andybroker 的回答照做没问题，现在的话补充一点细节。
2022.7.28 更新
代码略有变动（因为网址又变了）
<a href=https://www.zhihu.com/topic/20036297/"https://beian.miit.gov.cn/">鲁ICP备XXXXXXXX号</a>插在
</span>
{%- endif %}
</div>中 {%- endif %} 的后面。
新版本的 hexo 已经支持公安备案信息了，如 hexo-theme-next 7.7.2 的配置：
footer:
...
# Beian ICP and gongan information for Chinese users. See: http://www.beian.miit.gov.cn, http://www.beian.gov.cn
beian:
enable: false
icp:
# The digit in the num of gongan beian.
gongan_id:
# The full num of gongan beian.
gongan_num:
# The icon for gongan beian. See: http://www.beian.gov.cn/portal/download
gongan_icon_url:身份证图像生成器
身份证图像生成器在线书法生成
说文解字_横幅_书法味九歌——人工智能作诗
九歌我用的 Hexo 主题是 Fluid，这个主题已经添加了「添加备案号」的相关代码，只需要稍微配置一下，就能在博客首页的底部看到。
打开 Hexo 主题 Fluid 下方的配置文件 _config.yml ，搜索 footer 或者 beian，应该就可以找到添加备案号的设置了，譬如下图，我将 beian 下方的 enable 由原来的 false 更改为 true，并且在 icp_text 添加备案号。
修改之后 push 到远端仓库或者服务器，刷新博客首页，在底部应该就可以看到备案号了。
以上，希望有帮助。
可以考虑使用不蒜子。不蒜子是一个访问统计的模块，但与百度统计谷歌分析不同的是，它可直接将访问次数显示在在网页上。因此我们可以通过不蒜子快速便捷地添加访问统计功能。
当然除了不蒜子，valine 评论系统也附带了单页的阅读人数统计。但是由于不蒜子除了单页的阅读人数统计还可以提供全站的访问统计，外加我用的不是 valine 评论系统，所以不蒜子是更加普适且好用的访问统计模块。
在下文中，由于不涉及主题的参数，所以有可能很多的 Hugo 主题都适用，但本文仍以 LoveIt 主题为例。
在your_site\layouts\partials\plugin\路径下添加文件busuanzi.html，并将下面的配置输入至该文件
{{ if .params.enable }}
{{ if eq .bsz_type "footer" }}
{{/* 只有 footer 才刷新，防止页面进行多次调用，计数重复; 只要启用就计数，显示与否看具体设置 */}}
<script async src=" //busuanzi.ibruce.info/busuanzi/2.3/busuanzi.pure.mini.js "></script>
{{ end }}
{{ if or (eq .params.site_pv true) (eq .params.site_uv true) (eq .params.page_pv true) }}
{{ if eq .bsz_type "footer" }}
<section>
{{ if eq .params.site_pv true }}
<span id="busuanzi_container_value_site_pv">
{{- with .params.page_pv_pre -}}
{{ . | safeHTML }}
{{ end }}
<span id="busuanzi_value_site_pv"></span>
</span>
{{ end }}
{{ if and (eq .params.site_pv true) (eq .params.site_uv true) }}
|
{{ end }}
{{ if eq .params.site_uv true }}
<span id="busuanzi_container_value_site_uv">
{{- with .params.site_uv_pre -}}
{{ . | safeHTML }}
{{ end }}
<span id="busuanzi_value_site_uv"></span>
</span>
{{ end }}
</section>
{{ end }}
{{/* page pv 只在 page 显示 */}}
{{ if and (eq .params.page_pv true) (eq .bsz_type "page-reading") }}
<span id="busuanzi_container_value_page_pv">
{{- with .params.page_pv_pre -}}
{{ . | safeHTML }}
{{ end }}
<span id="busuanzi_value_page_pv"></span>
{{- T "views" -}}
</span>
{{ end }}
{{ end }}
{{ end }}找到your_site\config.toml配置文件，在最后面添加不蒜子的参数如下：
# 添加不蒜子计数
[params.busuanzi]
enable = true
# 是否开启全站独立访客数
site_uv = true
# 全站独立访客数前的图标或提示语
site_uv_pre = '<i class="fa fa-user"></i>'
# 全站独立访客数后的图标或提示语
site_uv_post = ''
# 是否开启全站浏览量
site_pv = true
# 全站浏览量前的图标或提示语
site_pv_pre = '<i class="fa fa-eye"></i>'
# 全站浏览量后的图标或提示语
site_pv_post = ''
# 是否开启单页浏览量
page_pv = true
# 单页浏览量前的图标或提示语
page_pv_pre = '<i class="far fa-eye fa-fw"></i>'
# 单页浏览量后的图标或提示语
page_pv_post = ''把your_site\themes\LoveIt\layouts\partials\footer.html复制粘贴到路径your_site\layouts\partials\下。 再修改文件your_site\layouts\partials\footer.html，在最后三行
</div>
</footer>
{{- end -}}的前面添加
{{- /* busuanzi plugin */ -}}
{{- partial "plugin/busuanzi.html" (dict "params" .Site.Params.busuanzi "bsz_type" "footer") -}}添加后代码如下图：
最后的呈现结果如下图：
提示： 如果只想简单地开启全站统计，我们可以忽略## 添加 Html 模板和## 在配置文件中添加参数，直接从开启页脚的全站统计开始，但需把要添加的
{{- /* busuanzi plugin */ -}}
{{- partial "plugin/busuanzi.html" (dict "params" .Site.Params.busuanzi "bsz_type" "footer") -}}换为
<script async src="//busuanzi.ibruce.info/busuanzi/2.3/busuanzi.pure.mini.js"></script>
<span id="busuanzi_container_site_pv">
<i class="fa fa-eye"></i> <span id="busuanzi_value_site_pv"></span> 次
</span> |
<span id="busuanzi_container_site_uv">
<i class="fa fa-user"></i> <span id="busuanzi_value_site_uv"></span> 位
</span>但这种方法不好添加单页阅读量，所以我不想用。
把your_site\themes\LoveIt\layouts\posts\single.html复制粘贴到路径your_site\layouts\posts\下。再在your_site\layouts\posts\single.html中找到第二个<div class="post-meta-line">标签，并在该标签下添加下面的代码
{{- /* busuanzi plugin */ -}}
{{- partial "plugin/busuanzi.html" (dict "params" .Site.Params.busuanzi "bsz_type" "page-reading") -}}添加后代码如下：
最后的呈现结果如下图：
注意： 请忽略这离谱的阅读数据
1. Hugo 网站访问计数插件不蒜子集成
2. 不蒜子
文章来源：Hugo 添加访问统计功能
欢迎来我的小站康康：Stilig's blog
ssr-web project
A fast, simple & powerful blog framework, powered by Node.js and Vue.
一个基于 Node.js 和 Vue 的高效、简单功能强大的静态博客生成器。
- express
- nuxt.js
- NodeJS
git clone https://github.com/xiaofuzi/ssr-web
通过 iat 命令行工具
- npm install iat -g
- iat ssr-web
# 安装依赖
$ npm install # Or yarn install
# 热加载开发
$ npm run dev
# 生产环境编译
$ npm run build
$ npm run start
- npm run start(如未编译请先编译npm run build)
- npm run g(此时 server 还需处于启动状态，即 npm run start命令或 npm run dev命令还在运行)
推送到 github 仓库并设置 github page 地址，因为默认静态文件生成与 docs 目录，所以将该目录设为 github page 根目录即可
* `<a-link></a-link>` 组件是为了替代 `<nuxt-link></nuxt-link>`（在generate 后发现有 bug）组件。
* 若不是处于域名根目录，需要更改导航的根地址，nuxt.config.js 的 router.base 属性和 `<a-link></a-link>` 组件的根地址两处。
client
- 前端代码（详情参考 nuxt.js 文档）
server
- 博客文档存放的目录，source/_posts目录下的会作为博文处理
插件功能
查看mdToJson文档
- 主题功能
如果你正在建一个新的网站，静态页面生成器或许是个正确的选择。
除非你是像艾米莉·狄金森那样深居简出的人，否则，当做了点事情后，你就会想要与这个世界分享。分享你的作品意味着需要一个网站。当然，你可以只是享受数字时代的便利，使用任何不同的社交网站来将你的作品呈现在观众面前。还有很多选择，不仅仅是传统的社交网站，例如 Artstation、Flickr、Soundcloud、Wattpad，不管你的媒介是什么，总有一款属于你的网站。
实际上，你应该使用这些网站，毕竟，人们都在这些网站上。然而，没有一个地方是真正属于你的。没有一个网站是你能保证不管社交趋势如何，人们都能在该网站上找到你的作品的。
控制权，这是拥有一个在网上属于自己的地方的意义。
但是这篇文章不打算介绍注册域名和托管你的网站。要介绍的是后续的步骤，真正地制作网页。对于很多人来说，典型的选择是使用像 WordPress 那一类的软件。在大多数主机托管商上，只需一次点击即可安装，然后就会有海量的插件和主题可供选择。插件和主题的选择取决于你想要制作的网页的类型。但是 WordPress 不仅对于大部分网站来说有点过犹不及，还给了你一个有许多活动部件的动态页面。如果你没有保持这些部件最新，这些部件可能造成重大安全隐患，你的页面因此被劫持。
替代方法是拥有一个静态网页，在服务端没有任何动态内容生成。只有一些原先的 HTML 和 CSS （或许还有点 Javascript 也挺好）。这种选择的不好的一面是以后你要亲自动手编写所有的代码。虽然可行，但你只是想要个地方来展示你的作品而已，你并不想知道底层网页设计的特性（和重要的但却令人头疼的跨浏览器兼容性）。
使用静态页面生成器。你得到了静态 HTML 页面的速度与安全，但是是以有着接近于动态页面的便利性的工作流程完成的。在静态页面生成器世界的两大先驱是 Hugo 和 Jekyll ，（顺道说下，Paolo Bonzini 的文章 《Jekyll 起步》 写得不错）但是哪一个才是你的正确选择？希望阅读完这篇文章，你会更加了解。我们将基于易上手性、主题可用性、编辑方式和拓展性这几点评估这两个静态页面生成器。
公平地提醒一下，这两个都需要你在命令行下使用他们。大部分命令都很直接和易于记忆，但是让我们相应地调整下我们的期望吧，这不是点击几下鼠标就能做事的界面。
Jekyll 和 Hugo 的安装都相当的简单。 Jekyll 以 RubyGem 的方式安装，Hugo 提供了一个方便的集成的二进制文件让你迅速上手。因为安装包单一，Hugo 以微弱优势领先。虽然 Jekyll 的 RubyGems 安装方式本身就很简单，但是它确实需要你已经在你的电脑上正确安装并且配置好 Ruby 环境。除了社区设计者和网页开发者，大部分的使用者并没有提前安装好。
虽说是这样，但是一旦安装好，Hugo 和 Jekyll 都很好用。它们都有良好的文档和快速开始指南。你用一个简单命令新建一个页面（在 Jekyll 里是 jekyll new <your_site> ，在 Hugo 里是 hugo new site <your_site>，译者注：<your_site> 指代你网页的名称）。这一步新建了一个通用目录结构和你网站的大致内容。目录结构和基本的配置都十分相似。Jekyll 使用一个 _config.yml 文件，Hugo 使用 config.toml（虽然你能在 Hugo 的配置里使用 YMAL 或者 JSON 语法，如果觉得其中一个使用起来更舒服的话）。每个内容文件的前置配置front matter元数据使用相同的配置语法。然后，所有的内容都是用 Markdown 写的。
我想说就帮助你开始第一个静态网页这一点来说，Jekyll 稍微领先于 Hugo ，因为它能以一些基本的内容和一个默认主题开始着手使用。当在建设网页时，你能使用这些内容作为一个样板。Hugo 没有样例内容，甚至没有一个默认主题。即便如此，样例内容和默认主题是我在用任何工具建设网站时第一个删除的内容，因此 Hugo 事实上帮我节省了这一步。
正如我所提到的，Hugo 根本没有默认主题，所以主题可能是你打算最先设置的。Jekyll 有一个得体的默认主题，虽然它只是个骨架。你或许也会想去为你的 Jekyll 页面找一个主题。
Hugo 和 Jekyll 都有多种多样的各类主题，网页样式从单页面的主题到带有博客和评论的完善的多页面主题都有，一应俱全。尽管如此，想找到满足你需求的主题事实上并不简单。无论使用哪个，主题网站——Hugo 的 themes.gohugo.io 和 Jekyll 的 jekyllthemes.org ，基本上都是一个充满主题截图的巨大页面。一旦你点击主题，你能得到关于该主题的一些十分详细的信息，但是对于初步搜索相当困难。Hugo 的主题站有一些基本的标签分类，但是大体上在我看来，主题搜索和展示都是这两个项目需要继续努力的。
主题管理也是一个有趣的主题。在两个项目中，几乎每一个主题都是一个 Git 仓库（经常是托管在 Github 上），你需要克隆clone下来到你的网页建设地。在 Jekyll 里，有额外的使用 RubyGems 的 bundle 的步骤来确保主题是由网站管理的。大部分主题都有一个 Gemfile，使得这一步骤轻松不少。如果主题没有一个 Gemfile，添加也相当简单。在 Hugo 里没有捆绑这一操作，只要在 config.toml 指向你的主题即可。
我发现我偏爱 Hugo 的主题处理。你可以克隆clone（或者新建）主题到 themes 里它们自己的子文件夹里。这不仅使得当你开始时能轻松地切换主题，而且也能让你用自己的文件替换主题里的任何组件。这意味着你能根据自己的品味自定义主题，而不用弄乱原始主题，使得这主题也可以通用于其他人。当然如果有一个你觉得其他用户会觉得值得的改变，你仍然可以编辑源文件，提交一个 PR（拉取请求pull request）给主题维护者。
一旦你设置好初始的配置，Jekyll 和 Hugo 的网站建设流程都很相似。两者都有一个实时的 serve 命令，能在你的电脑上运行一个小型、轻量级的网页服务器，所以你能在在本地测试你的网站而不用上传到哪里。很棒的是无论你是运行着 jekyll serve 还是 hugo serve，都默认配置为当你为之开发时，监视你对网站的任何修改。当你在浏览器里看本地版的网站时，它会根据你的修改自动更新，不管你改的是内容、配置、主题、还仅仅是一张图片。这确实很方便和节约时间。
在两个系统中都是用 Markdown 写你的网站内容。如果碰巧你不熟悉 Markdown，（我来解释下，）它是种很简单的纯文本编写方式，还能有一些很好用的格式化符号。它很容易使用而且可阅读。而且因为是纯文本，你的内容（其实是你的网站）很容易进行版本控制。这是我最近写几乎所有东西的主要方式。
新内容能通过在正确的地方手动创建文件添加到网站里。新的文件只需要是有恰当的前置配置front matter元数据的 Markdown 文件即可。至于配置文件，Jekyll 对于前置配置使用 YAML 语法，Hugo 接受 TOML、YAML 或者 JSON（默认是 TOML）。新文件需要放置在正确的文件夹内，在 Jekyll 里你需要把你编写中的文件和已经完成了的内容页分别放在 _drafts 和 _posts 目录中。在 Hugo 中只有单独一个 content 目录。你可以根据文件的前置配置判断这是否是一个草稿。
现在，虽然可以手动完成所有这些事情，但是 Hugo 提供了一些方便的功能确保你的新文件创建在正确的文件里，那些文件也用恰当的前置配置预先配置好了。简单地在终端中进入你网站的目录，输入 hugo new content/<page.md> ， <page.md> 代表着你想新建的新页面。你甚至可以设置些包含为不同页面自定义的前置配置、叫原型的模版（例如在你的网页上同时有博客和播客）。
当你的网页弄好后，你能关闭你的预览服务器，并用一个命令来建立你网站的真正页面。在 Jekyll 里是 jekyll build，Hugo 就仅仅是 hugo，Jekyll 把完成好的页面放在 _site 的子目录中。然而 Hugo 把这些文件放在名为 public 的子目录中。不管哪种情况，一旦你完成后，你就有了一个完整的静态网站，你能上传并把它托管在几乎任何地方。
Hugo 和 Jekyll 都能让你自定义你自己的网站上哪怕最小的一个点。然而就可拓展性而言，现在 Jekyll 因其插件 API 而远远领先。因为这种插件结构，很容易为你用 Jekyll 生成的网站添加功能，通过 Jekyll 社区或者你自己写的相当短的代码片段就能完成。
Hugo 现在根本没有插件 API，所以添加功能有点难。希望以后支持编写并包含插件。但是现在看不出有人在做这一点。
大体上讲，Hugo 和 Jekyll 十分相似。归根结底由你工作体验和你的网站需求决定。如果你已经设置好了 RubyGems 环境而且你需要插件的可拓展性，Jekyll 是你的选择。然而，如果你看重一个简单的工作流程，一个直接自定义网站的方式，那你首选 Hugo。
我发现我更喜欢 Hugo 的方法，而且在建设一个小型网站，我不需要任何插件。当然，每个人的需求都不同。你会为你的网站选择哪一个静态页面生成器？
（题图：http://opensource.com）
via: Hugo vs. Jekyll: Comparing the leading static website generators
作者：Jason van Gumster 译者：ypingcn 校对：wxy
本文由 LCTT 原创编译，Linux中国 荣誉推出
现在有越来越多的开发者选择把自己的博客以静态网站的方式托管在 GitHub 上, 这样的方式只需要一个域名就可以通过诸如 Jekyll, Hexo, 纸小墨 等等现有的静态博客生成工具, 非常便捷地搭建出一个样式美观的静态博客.
目前传统的软件项目, 可以通过 Travis CI 等等工具来进行编译, 测试等等持续集成任务, 但是对于一个静态网站来说, 其最主要的产物是 HTML 文件. 而主流的持续集成工具都不支持对静态的页面进行构建的预览. 这篇文章主要介绍了 Netlify, 一个可以用来做静态网站的持续集成与持续部署的工具. 通过 Netlify, 用户可以非常简单地为其静态网站项目引入持续集成, 并且允许其他成员对静态网站进行 UI 层面的 review.
东岳团队博客 是一个使用纸小墨构建的静态博客网站, 其托管在 github.com/dyweb/blog 下. 因为我们的博客采取投稿制, 每个项目成员都可以为这个博客进行投稿, 所以对于投稿的审核是一个非常重要的需求.
目前我们的投稿是以 Pull Request 的方式进行, 作者会首先提交自己的文章, 这是以 Markdown 的格式书写的. 然后会基于 Markdown 文件, 构建出对应的 HTML 文件并加入到 docs/ 目录下. 因此我们对于投稿的审核是在 Pull Request 下进行的.审核包括但不限于对博客样式是否被新的投稿破坏, 投稿内容是否贴合博客方向, 有无 typo 等等.
而因为在 Pull Request 中, 我们只能看到所有文本文件的变动, 而看不到变动后的博客页面. 这在之前只能在文章被合并后, 再次访问东岳团队博客, 才可以进行效果的审核, 而这时文章已经是合并状态了, 再次修改需要提交新的 Pull Request 才能继续, 这样无疑延长了审核的周期.
因此我们需要一个工具, 可以帮助我们为每个 Pull Request 构建出静态网站, 并且是允许所有成员都可以访问的.
Travis CI 是一个非常成熟的持续集成工具, 通过它, 用户可以执行自定义的脚本任务, 测试等等. 在之前我们使用它来确认我们的代码是可以完成构建出静态网站这一步操作的. 但是 Travis CI 存在一些问题, 它不能为每个 Pull Request 构建出静态网站供我们审核, 而只能简单地返回构建的成功与否, 这个信息对我们而言是不充分的. 而其他此类的服务也往往具有这个问题.
Netlify 对自己的描述是:
Netlify is a unified platform that automates your code to create high-performant, easily maintainable sites and web apps.
Netlify 与 Travis CI 等等都是持续集成工具, 但是它更加关注前端, 或者说网站或者 web app 的持续集成与持续部署, 这也是它与其他持续集成工具最大的区别. 我们目前对于 Netlify 的使用也非常简单, 但是这是其他持续集成工具没有的.
为了能够在每个 Pull Request 中看到新的博客文章预览, 我们需要在 Netlify 中为我们的 repository 做一些设置. 在我们的使用中, 设置过程非常地简单:
- 为 repository 启用 Netlify
- 设置发布目录为 docs/
首先最重要的是为 repository 启用 Netlify, 这一部分与其他持续集成工具并无二致. 这一环节最主要的是让 Netlify 在 GitHub 中建立 web hook, 使得它可以监听到整个 repository 的事件. 当然这是自动的, 对于用户而言是不感知的. 随后 Netlify 会要求用户去设置构建的命令以及发布的目录.
对于我们的博客来说, 因为我们的博客会被编译好放置在 docs/ 目录下, 因此不需要 Netlify 为我们进行构建, 如果你的项目并不是这样操作的, 比如只是有源文件而没有提交构建后的静态网站, 那你可以利用它的这一功能进行远端的构建. Netlify 默认支持 Jekyll 等等静态博客生成工具的命令, 因此可以满足绝大多数的应用场景.
在配置结束后, 就可以利用 Netlify 来进行持续集成了. 在大多数情况下, 用户甚至不需要像 Travis CI 那样在 repository 里放置配置文件, 直接通过网页操作来搭建起对一个 repository 的持续集成.
每当一个新的 Pull Request 被创建的时候, Netlify 会为这个请求运行一个构建任务, 这个任务最终会生成一个预览, 通过 URL 可以访问到基于这一 Pull Request 的构建结果.
而 URL 是可以自定义的, 比如 https://deploy-preview-26--blog-dongyueweb.netlify.com. 不同 Pull Request 会有不同的 URL, 因此基于此还可以去做 Split Testing. 目前 Netlify 支持两个 branch 之间的 Split Testing, 但还是 beta 阶段, 我们没有进行过尝试.
如此以来, 我们可以利用 Netlify 的预览功能, 来对 Pull Request 进行内容和格式的审核. Netlify 本身有更多的功能, 它的愿景是为前端引入持续集成. 限于篇幅, 停笔于此.
目前我们知道的使用 Netlify 服务的网站有:
- 统计之都
- 东岳团队博客
- Processing.R 网站
- headlesscms.org
PS: 这是一篇免费的安利文, 我们与 Netlify 利益不相关
欢迎关注我们的 GitHub 以及博客 :)
今天给大家分享一款对话生成器工具，超级好用，该工具自动生成聊天内容，进行宣传和推广，免费的哦
http://weixin.xiuzuche.com/wechat/cchat/ (二维码自动识别)
生成步骤
1、编辑群名称
2、添加需跳转指定连接，若不填或填写非有效地址，默认跳转生成页面
3、编辑聊天内容：选择发言人，编辑发言内容
4、可点击继续添加按钮添加一条新发言
5、编辑完成后点击马上生成即可
这是一个开源的，基于 electron-vue、iview 开发的一个静态博客客户端工具，正在开发和内测中，目前只有 Mac 版，目前只有 Mac 版，目前只有 Mac 版
欢迎使用 Hve，本文档将帮助你快速上手。如果使用过程中遇到问题，请加群或提 Issues，我会尽力帮你解答。
项目地址：hellohve/hve
博客预览地址：
Hve 是一个快速、易用、交互友好的静态博客客户端工具。基于 Markdown 渲染文章，依托 Github Pages 进行静态博客部署。目前只有 Mac 版，Windows版敬请期待。
首先确保您已经安装了Git，Hve 使用 Git 进行版本控制和博客发布。
下载 Hve，并进行安装即可。
登录自己的 GitHub 依次进入到 Settings -> Developer settings -> Personal access tokens, 然后点击 Generate new token 按钮进行 token 生成，只需勾选上 repo 相关权限即可。生成后复制保存到本地，以备后用。
此步用于评论系统——Gitment 相关配置信息，如果不需要评论系统，可跳过此步，不过我们还是建议你配置一下，我们认为利用评论来交朋友或对自己文章进行反馈，是个不错的体验。
打开 Hve，按照欢迎页的提示，进行 一、二、三步操作。
1. 设置源文件目录，点击更改目录，进入系统文档（Documents）文件夹，选择 hve-blog 文件夹，这个文件夹是首次打开 Hve 时自动生成的，里面包含了博客的初始化相关文件夹和文件；
2. 输入 Domain，例如：//eryouhao.github.io/hve-blog, 即网站对应的域名，若是初次使用 Github Pages，可直接新建一个 用户名.github.io 的仓库，直接使用 Github Pages 服务，或开通任意仓库的 Pages 服务；
3. 输入 Repository，例如：hve-blog 或 eryouhao.github.io, 即网站发布后静态文件存放的仓库；
4. 输入 Branch，例如：master, 即 Github Pages 对应的分支；
5. Username, 例如：EryouHao, 即 Git 提交时使用的用户名；
6. Email, 例如：haoeryou@qq.com, 即 Git 提交时使用的邮箱；
7. Token, 即准备时生成的 Personal access tokens；
8. 点击保存。
1. 设置网站头像，可以选择一张心仪的图片来作为网站的头像；
2. 输入网站标题；
3. 输入每页文章数;
4. 输入 Gitment Owner，例如：EryouHao
5. 输入 Gitment Repo，例如：hve-blog, 即评论 Isssue 存放的仓库
6. 输入 Gitment Client ID，即准备时注册 Oauth application 时的 Client ID；
7澳门正版资料免费大全精准. 输入 Gitment Client Secret，即准备时注册 Oauth application 时的 Client Secret；
8. 点击保存。
现在你可以用 Hve 来进行文章创作，也可以直接点击 Publish 进行测试，因为我们已经为您准备了一篇测试文章。
发布后，可直接打开浏览器访问你的博客啦，例如：http://fehey.com/hve-blog
此项目还在开发中，目前只是一个内测版本，勉强可以使用了，诚邀内测，并欢迎各种 Star、Issues、PR，也欢迎小伙伴一起开发
项目地址：hellohve/hve
博客预览地址：
TODO:
- [x] 新建、编辑、删除文章
- [x] 文章插入图片
- [x] 预览文章
- [x] 预览博客
- [x] 基本网站设置
- [x] 评论系统
- [x] 页面管理
- [] 自定义页面添加
- [] 主体按标签分类、文章归档
- [] 社交信息管理
- [] 切换主题
- [] 主题在线更新
- [] 网站备份
- [] 网站备份恢复
- [] 工具在线更新
- [] 自定义域名绑定
- [] 浏览统计
最近想要给自己搭建一个博客网站，货比三家后，决定选择http://Hexo.io来建站，Netlify来进行代码托管和部署2024澳门天天好开彩大全。
长话长说，在转行写前端之前，我曾做过一段时间网站内容编辑，当时主要使用的是Wordpress。作为传统动态网站生成器的代表，Wordpress拥有超高市场占有率，很多大型出版媒体的网站都是基于Wordpress。对于非技术人员来说，其内容撰写及维护门槛较低。但和任何传统动态网站生成器一样，对于轻量级小建站平台，Wordpress显得过分臃肿。过时的插件容易被黑客攻击，形成安全漏洞。由于需要频繁访问数据库，其速度难以保证。
于是乎，近年来如日中天的静态网站生成器成了替代方案。对于靠写代码吃饭的程序猿朋友们来说，在保留Git工作流程基础上，利用Markdown来撰写博客内容相比之通过内容管理系统的用户界面来创建内容要方便高效很多。
什么是静态网站生成器？具体优势为何？
网友Chikara Chan在静态网站生成器是如何工作的中总结到：
一个静态网站生成器的工作流程通常有以下几个步骤：
读取源文件（e.g. 约定 markdown 格式）
资源预处理
模板引擎渲染
生成目标文件
和传统动态网站生成器相比，静态网站生成器的主要优势体现在：
- 响应速度：静态博客站点页面都是静态页面，访问时无需查询数据库，因此响应速度相对快很多
- 安全性：同样由于不需要访问数据库，静态网站免疫了很多网页攻击，其安全性令动态网站生成器望尘莫及
最受欢迎的静态网站生成器有Jekyll, Hugo, Gatsby，以及我们今天的主角Hexo等。详见StaticGen了解最新权威排名。
Hexo是一款基于Node.js的静态博客网站生成器，由台湾的Tommy Chen创建并维护。其卓越的速度，丰富的插件系统（支持大部分Octopress插件），友好的语言支持（拥有简体中文及繁体中文版本的文档），使其备受国内用户亲赖。
在开始安装Hexo前，请确保你的本地环境已安装如下应用程序：
- Git
- Node.js
打开终端，输入npm命令安装Hexo：
$ npm install -g hexo-cli安装完成后，输入以下指令创建项目文件夹路径：
$ hexo init /PATH/TO/hexo切换至刚刚创建的文件夹：
$ cd /PATH/TO/hexo建站
安装Hexo会在你所制定的文件夹里安装必要组件，以提供给你一个基本的网站雏形。通过npm来操作完成Hexo初始化:
$ npm install恭喜你！网站雏形已建成！启动hexo服务器来预览你的成果：
$ hexo server你现在可以前往 http://0.0.0.0:4000/ 访问你的最新网站了！
这么简单？没错，就是那么简单。
当然，别忘了给你的网站添加文章内容！
新建博客文章，只需运行以下指令:
$ hexo new "我的最新日志"你会发现在你的文件夹_posts下已生成了一个新的md文档，其中已包含了文章的标题和创建日期。
---
title: 我的最新日志
date: 2018-07-03 11:54:41
tags:
---下一步，生成静态文件:
$ hexo generate如果你的hexo服务器还在运行中的话，刷新网页，便可看到你新创建的博客文章！
网站发布前准备工作
添加完网站内容后，我们接下来来看如何发布网站。
有一个细节值得一提，在默认情况下，Hexo将生成的网站内容存储至public文件夹。鉴于我们不需要对该文件夹的内容进行版本控制，我们可将该文件夹添加至.gitignore文档中:
$ echo "/public" >> .gitignore接下来便可将你的内容推送至你习惯使用的代码托管服务，以GitHub和GitLab为代表。我们会以GitHub为例来进行步骤讲解。
新建仓库
首先，在GitHub上新建仓库。为了避免出错，在新建仓库时，请不要在创建Initialize this repository with a README前打勾，Add .gitignore和Add a license处请选择None。
鉴于我们的demo基于Hexo和Netlify，在Repository name处填写hexo_netlify来命名仓库。
打开你的电脑终端，切换至你的项目所在的本地文件夹路径：
$ cd ~/PATH/TO/hexo_netlify/初始化仓库
$ git init该命令将创建一个名为.git的子目录，其中包含了你初始化的Git仓库中所需的文件，这些文件是Git仓库的核心。此时，我们仅作了一个初始化的操作，你的项目文件还未被跟踪。
通过git add 来实现对指定文件的跟踪，然后执行git commit提交:
$ git add .
$ git commit -m "initial commit"回到之前我们创建GitHub仓库完成的页面，复制远程仓库链接，在终端输入:
$ git remote add origin <远程仓库链接>你可以通过git remote -v来验证你的链接是否正确。
验证完毕，确认准确无误后，用以下指令推送本地仓库内容至GitHub
$ git push origin master现在，你的源代码已被成功上传至GitHub，接下来我们可以通过Netlify来发布网站。
为什么选择Netlify来发布网站？Netlfily和GitHub Pages有什么区别？
大约一年前，在网上闲逛时发现这篇文章GitHub Pages is Dead, Long Live Netlify!。
转身尝试了下Netlify，感觉如获至宝。如文章所言, Netlify的Continuous Deployment持续部署功能使其鹤立鸡群（后面具体讲述部署过程的时候会有更详细解释）。且Netlify支持大部分静态网站生成器（Github Pages仅支持Jekyll）。此外，GitHub Pages对redirects，重定向（也称URL转发）支持并不友好，如果你哪天改变主义，不再需要GitHub Pages所提供的*.github.io子域名，那你可有得麻烦了。相形之下，你可以轻松简单得从*.netlify.com重定向至你的新地址(Netlify 的重定向编码是301或302)，这样一来，搜索引擎可以清楚识别你的页面已被转移，从而对你的新页面进行重新排名。所以即使哪天Netlify车毁人亡，只要设定好了重定向，你的网站便不会受到任何影响。
1. 添加网站内容
首先，你需要注册一个Netlify账号，Netlify提供邮箱注册和包括GitHub在内的第三方验证登陆。注册过程和一般网站注册过程大同小异，你会收到一封来自Netlify的邮件，确认你的注册信息，点击邮件中的链接登陆你的账户。
2. 关联GitHub账户
登陆后，在 https://app.netlify.com/account/sites 页面下，点击New site from Git进入下一步。
点击GitHub关联Netlify和你的仓库
3. 授权验证
首次关联时，你会看到以下窗口，点击Authorize netlify同意授权后，Netlify可以有权访问你在GitHub上的仓库内容了
4. 选择仓库
授权完毕后，页面会跳转回Netlify。通过搜索栏来快速找到你所创建的hexo_netlify仓库，选中该仓库。
5. 配置发布设置
Netlify允许你自定义你的部署设置，我们的demo只需使用默认设置即可。
6. 构建并发布网站
此时此刻，万事具备，只欠东风。
点击完Deploy site之后，Netlify会构建并发布你的网站内容。你可以放心得伸个懒腰，泡杯咖啡，剩下的就交给Netlify处理。你可以通过Deploy log实时观察部署过程。
进行到这一步，Netlify的主要特色终于得以浮出水面。我们知道，任何超过一个人的项目都需要经历以下过程：某a分支的内容需要通过pull request进行审核，审核完后合并到主分支。Netlify支持分支部署（ branch deployment )和部署预览( deploy preview )，也就是说，你可以在不触及production code的情况下，预览你的成果。这两样功能大大提高了团队合作效率，降低了发布风险和成本。
7. 发布成功
不到一杯茶的时间，网站上线。Netlify会在网站发布成功的同时提供给你一个*.http://netlify.com为后缀以及随机生成的英文名为前缀的子域名。假如你不喜欢Netlify给你的前缀，并且还未来得及购买域名，可以通过Domain settings > Edit site name来快速美化你的网址：
上线！撒花！2024新奥资料免费精准109
在建站过程中，你可能最常需要用到以下指令：
hexo n #添加新内容
hexo g #生成静态文件
hexo d #部署 #可与hexo g合并为 hexo d -g
hexo s == hexo server #启动服务预览更多指令请参考Hexo文档。
唯一遗憾的是，和GitHub一样，Netlify没有中文版！不过幸好整个建站过程总体很顺畅，没有遇到任何障碍。
希望这篇文章能对有兴趣的童鞋有所帮助，有任何问题，建议，想法，质疑，欢迎留言或邮件交流。
我的博客之前一直托管在 coding 上，图片等静态资源放在七牛云的 cdn 上，这样国内国外访问速度都还可以。
去年七牛云的 cdn 强制需要做域名备案，备案是不可能的，这辈子都不可能，所以把所有静态资源都直接扔到 coding 上。coding 也发生了几次博客推送后不更新问题，一怒之下，就直接把博客迁到 GitHub Pages，不过对国内用户来说，访问速度和稳定性不是很好。
正当我在想怎么办的时候，发现了 Netlify。
Netlify 是一个提供静态资源网络托管的综合平台，提供CI服务，能够将托管 GitHub，GitLab 等网站上的 Jekyll，Hexo，Hugo 等代码自动编译并生成静态网站。
Netlify 有如下的功能:
- 能够托管服务，免费 CDN
- 能够绑定自定义域名
- 能够启用免费的TLS证书，启用HTTPS
- 支持自动构建
- 提供 Webhooks 和 API
首先使用你的 GitHub 账号登陆 Netlify，登陆后进入空间管理中心，，点击New site from git按钮开始部署你的博客：
然后根据自己的托管平台，可以选择GitHub、GitLab或者BitBucket（这里以 GitHub 为例）：
点击GitHub之后会弹出一个让你授权的窗口，给 Netlify 授权后，就会自动读取你 GitHub 的仓库：
选择仓库后，Netlify 会自动识别到 hexo，并填入相关信息，这时候只要无脑点击 Deploy site就可以：
稍等一段时间就可以看到你的博客已经部署成功，并且给你分配了一个二级域名（先记下这个二级域名）：
如果你要绑定自己买的域名，就直接点击第二步Set up custom domain。添加自定义域名，先添加不带www的域名作为主域名：
设置完，Netlify 会提示你去域名DNS解析处，修改域名的CNAME记录：
去你的 DNS 解析提供商里面，将 CNAME 记录值更改为 Netlify 给你的二级域名：
修改完，就可以看到 Netlify 状态更新：
Netlify默认会启用 HTTPS，而且不能关闭，如果你没有证书，它会帮你去Let’s Encrypt申请免费的证书，当然你也可以自己申请证书，以阿里免费的 ssl 证书为例，下载证书证书时选服务器类型为Apache的证书，Netlify 配置填写如下：
上面流程走完，其实已经可以自动化部署，只要 push 了代码，就会自动更新，你可以在下面地方查看部署的信息：
如果你不想用 Netlify 的服务，也可以用 Circle 的服务，它和 GitHub 关联，提供 CI 服务。你需要做的事在根目录下新建一个.circle文件夹，里面新建一个config.yml文件（注意把相关信息替换成自己的）：
# Javascript Node CircleCI 2.0 configuration file
#
# Check https://circleci.com/docs/2.0/language-javascript/ for more details
#
version: 2
jobs:
build:
docker:
# specify the version you desire here
- image: circleci/node:7.10
# Specify service dependencies here if necessary
# CircleCI maintains a library of pre-built images
# documented at https://circleci.com/docs/2.0/circleci-images/
# - image: circleci/mongo:3.4.4
working_directory: ~/repo
steps:
- checkout
# Download and cache dependencies
- restore_cache:
keys:
- v1-dependencies-{{ checksum "package.json" }}
# fallback to using the latest cache if no exact match is found
- v1-dependencies-
- add_ssh_keys:
fingerprints:
- "你的 ssh key的fingerprints"
- run: git config --global user.email "user@domain.com"
- run: git config --global user.name "user"
- run: npm install
- run: sudo npm install hexo-cli -g
- save_cache:
paths:
- node_modules
key: v1-dependencies-{{ checksum "package.json" }}
# run tests!
- run: hexo clean
- run: hexo g
- run: hexo d这时候，你只要提交代码到这个仓库，circle 就会帮你自动部署了。
前天，我使用 GitHub Actions 实现了静态博客的自动化部署，觉得它非常强大，方便，只要你提交到 GitHub，后面的部署完全由 GitHub 自动完成。
这里提到静态博客，所谓静态博客，就是通过生成工具（eg：Hexo、Hugo、VuePress 等），直接将作者所书写的博文编译成最终的 html、css、js 等静态文件。然后只需将生成的文件部署在服务器（eg：GitHub、Gitee、自建服务器）上面即可被在互联网中访问。
一般这类静态博客部署的流程是：
- 写一篇 markdown 文章。
- 执行命令生成静态文件，比如
npm run build。 - 将静态文件推送到博客仓库，比如说 GitHub、Gitee 或者服务器，如果是 Gitee，还要手动点击重新部署按钮。
- 访问网址验证是否成功
- 为了备份你的博客，你可能要将你写博客的项目也推送到仓库。
博客就是用来写文章的，每次写篇文章还要搞这么多操作，时间长了你一定会觉得很累。
现在，你不会觉得累了，使用了 GitHub Actions 之后，流程可以简化为：
- 写一篇 markdown 文章。
- 提交到 GitHub。（这一步相当于上面的第 5 步，不需要上传 node_modules 文件夹)
结束了，是不是很方便？
当然了，不止博客的部署，任意软件的持续集成，都可以由 GitHub Actions 来完成，比如拉取代码、运行测试、登录远程服务器，发布到第三方服务等。因此 GitHub Actions 是实现自动化发布最便捷的方式了，值得每一个程序员学习和使用。
接下来，我以 GitHub Actions 实现静态博客的自动化部署为例，带你入门 GitHub Actions，如有任何问题，欢迎文末留言讨论。
本文的方法可以大大简化静态博客的部署流程，从机械的流程中解脱，专注于写作，岂不美哉！那么现在就开始 GitHub Actions 之旅吧。
假如有以下四个仓库：
- git@github.com:somenzz/push_blog：写博客的项目仓库，里面有用于生成博客的 md 文件，和生成静态博客的脚手架，比如 VuePress，hexo 等，该仓库可以私有。
- git@github.com:somenzz/http://somenzz.github.io：存放博客的静态资源文件，用于 GitHub Pages 展示博客，必须开源。
- http://git@gitee.com/somenzz/somenzz：存放博客的静态资源文件，用于 Gitee Pages 展示博客，必须开源。
- ip 地址：http://xxx.xxx.xxx.xxx，或者域名 http://somenzz.cn，路径 /xxxx/public/，是自己购买的服务器，用于存放静态博客资源文件。
现在的目标就是，写好一篇文章，向仓库 1 推送之后，仓库 2、3、4 自动更新静态资源文件。当然了，你也可以根据自己情况，选择性的更新 2、3、4 中的一个或多个，只需要将对应的步骤从 GitHub Actions 配置中注释或删除即可。
这里说下我对 GitHub Actions 的理解，你提交到仓库 1 后，GitHub 会监控到，然后分配一台虚拟机先将你的项目 checkout 过去，然后按照你指定的 step 顺序执行定义好的 action，这些 action 就包括 npm run build 生成静态文件，push 到你指定的仓库等动作。
这就不可避免的涉及一些访问权限的控制，你要向 GitHub 证明你对这些仓库有控制权限，有些操作，还需要你提供 RSA 的私钥，登录的口令，当然了，这些口令都是加密存放的，不会泄漏，可放心使用。
为了实现上面的小目标，我们要让 GitHub 替我们做的事情如下：
- 编译项目，生成静态文件。也就是对仓库 1: git@github.com:somenzz/push_blog，执行 npm run build 生成博客的静态资源。
- 将静态资源 push 到 GitHub，也就是 push 到仓库 2: git@github.com:somenzz/http://somenzz.github.io，这一步完成后 GitHub Pages 就部署完成了。
- 将仓库 2 同步给仓库 3，也就是 git@github.com:somenzz/http://somenzz.github.io 同步给 http://git@gitee.com/somenzz/somenzz，这样两个项目的静态资源就一致了。
- 部署 Gitee Pages，因为 Gitee 的限制，需要手动点一下更新，现在把这一步变成一个 GitHub action。
- 使用 rsync 增量同步工具，将静态资源同步的自购服务器的对应目录上。
现在，我们一步一步来。
首先在仓库 1 的根目录下，创建 .github/workflows/main.yml 文件，这就是 GitHub Actions 功能的配置文件，用于告诉 GitHub 要做哪些事情，写入以下内容
name: Deploy GitHub Pages
# 触发条件：在 push 到 master 分支后
on:
push:
branches:
- master
# 任务
jobs:
build-and-deploy:
# 服务器环境：最新版 Ubuntu
runs-on: ubuntu-latest
steps:
# 拉取代码
- name: Checkout
uses: actions/checkout@v2
with:
persist-credentials: false
# 1、生成静态文件
- name: Build
run: npm install && npm run build
# 2、部署到 GitHub Pages
- name: Deploy
uses: JamesIves/github-pages-deploy-action@releases/v3
with:
ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }}
REPOSITORY_NAME: somenzz/somenzz.github.io
BRANCH: master
FOLDER: public
#注意这里的 public 是仓库根目录下的 public，也就是 npm run build 生成静态资源的路径，比如有的人是 `docs/.vuepress/dist`
# 3、同步到 gitee 的仓库
- name: Sync to Gitee
uses: wearerequired/git-mirror-action@master
env:
# 注意在 Settings->Secrets 配置 GITEE_RSA_PRIVATE_KEY
SSH_PRIVATE_KEY: ${{ secrets.GITEE_RSA_PRIVATE_KEY }}
with:
# 注意替换为你的 GitHub 源仓库地址
source-repo: git@github.com:somenzz/somenzz.github.io.git
# 注意替换为你的 Gitee 目标仓库地址
destination-repo: git@gitee.com:somenzz/somenzz.git
# 4、部署到 Gitee Pages
- name: Build Gitee Pages
uses: yanglbme/gitee-pages-action@main
with:
# 注意替换为你的 Gitee 用户名
gitee-username: somenzz
# 注意在 Settings->Secrets 配置 GITEE_PASSWORD
gitee-password: ${{ secrets.GITEE_PASSWORD }}
# 注意替换为你的 Gitee 仓库，仓库名严格区分大小写，请准确填写，否则会出错
gitee-repo: somenzz/somenzz
# 要部署的分支，默认是 master，若是其他分支，则需要指定（指定的分支必须存在）
branch: master
# 5、部署到 somenzz.cn 服务器
- name: rsync deployments
uses: burnett01/rsync-deployments@4.1
with:
# 这里是 rsync 的参数 switches: -avzh --delete --exclude="" --include="" --filter=""
switches: -avzh
path: public/
remote_path: /home/ubuntu/public/
remote_host: somenzz.cn
remote_port: 22
remote_user: ubuntu
remote_key: ${{ secrets.MY_UBUNTU_RSA_PRIVATE_KEY }}稍微有点长，为了便于你理解，每一步我都有注释，这就是实现这个小目标，GitHub Actions 工作流需要的全部内容，遵循 YAML 格式，这里我做一个大致的说明：
- on 表示触发条件
- jobs 表示要做的工作
- jobs 下的 step 表示要做的步骤，前一步失败，后面不会继续执行。
- jobs 下的 step 下有 name、uses、with 等，表示一个 action。
- name 表示 action 的名称，uses 表示使用哪个插件，with 表示传给插件的参数。
secrets.XXX这个 XXX 表示本仓库的环境变量，配置在仓库设置里面的 secrets 菜单拦，都是加密的。
uses 中用的就是别人写好的插件，持续集成由很多操作组成，比如抓取代码、运行测试、登录远程服务器，发布到第三方服务等等，这些操作都用共性，GitHub 就允许其他人把写好的插件共享到插件市场供其他人使用，因此如果你需要某个 action，不必自己写复杂的脚本，直接引用他人写好的 action 即可，你说方便不方便，插件市场见本文的学习资源小节。。
上述文件 .github/workflows/main.yml 写好之后，先别着急 push，一旦 push，这些 actions 就会执行，在参数正确的配置之前，报错那是肯定的。
接下来我说一下一些参数的意义以及如何确定这些参数的值。
对应的配置代码：
# 部署到 GitHub Pages
- name: Deploy
uses: JamesIves/github-pages-deploy-action@releases/v3
with:
ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }}
REPOSITORY_NAME: somenzz/somenzz.github.io
BRANCH: master
FOLDER: public这个 ACCESS_TOKEN 是访问 GitHub API 的令牌，可以在 GitHub 主页，点击个人头像，Settings -> Developer settings -> Personal access tokens 进行生成或更新，第一次生成后你可以看到这个令牌，然后再也不会显示，因此你需要记下来，假如这个字符串是 aaa，然后打开仓库 1 的设置页面，设置 secrets，加入环境变量， name 是 ACCESS_TOKEN，value 是 aaa。如下图所示：
这一段配置文件的作用就是，将 public 目录内的文件 push 到 somenzz/http://somenzz.github.io 的 master 分支，其中 public 就是 npm run build 生成的静态资源所在的位置。
没错，这里就是 RSA 的私钥，这里如果你不熟悉 RSA，可能会产生困惑，不是说公钥在网上传输，私钥不公开吗？ 没错，确实是这样，Gitee 上保存你账户对应的公钥，GitHub 仓库的 secrets.GITEE_RSA_PRIVATE_KEY 保存着私钥，因为 GitHub 的服务器不会让你亲自登录设置密钥对，因此需要配置 secrets.GITEE_RSA_PRIVATE_KEY 来告知 GitHub，解密操作需要的私钥并不是在网上传输，只有自己知道。
GitHub Actions 的服务器会使用你的账户登录 Gitee，Gitee 使用你的公钥加密后传输给这台服务器，这台服务器使用你设置的私钥才能解密成功，通讯完成。如果想搞懂 RSA 算法可以看我之前些的文章一文搞懂 RSA 算法，是全网讲的最明白的文章。
这里说下如何生成 RSA 的公钥和私钥。
打开终端，输入以下命令：
ssh-keygen -t ed25519 -C "your_email@example.com"这里的邮箱是你 Gitee 的注册邮箱。如果服务器不支持 ed25519 算法，可以这样：
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"我这里使用的就是第二种，然后一路回车即可。执行完成后，在 ~/.ssh 目录下可以看到 id_rsa、id_rsa.pub 等文件，其中私钥就是 id_rsa，公钥就是 id_rsa.pub，这就是密钥对，一个可用于加密，另一个可用于解密。
打开 http://gitee.com 并登录，点击自己头像右下角，选择设置-> ssh 公钥，将 id_rsa.pub 的内容复制到公钥的输入框里，公钥的标题可以自己填写，如下图所示：
接下来设置 secrets.GITEE_RSA_PRIVATE_KEY ，在 GitHub 上打开仓库 1 的设置页面，点击 secrets，增加环境变量，name 就填写 secrets.GITEE_RSA_PRIVATE_KEY，value 就填写 id_rsa 文件的内容，如下图所示：
注意 id_rsa 文件的内容通常如下所示：
$ cat id_rsa
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAACFwAAAAdzc2gtcn
NhAAAAAwEAAQAAAgEA4v2D0sH/puF4GWZdCfeontuoInVna7jxmtrnHxiOHkoIt5Mp/lMO
6kHWxpSxumQ+CAuqdVYGcsE+8FL0wCBBolpAK7jmX+S7l9wTkPJxYduOPxRBbKFKZp07R/
......
C2FVan1VGNpJ/wAAAA9zb21lbnp6QDE2My5jb20BAg==
-----END OPENSSH PRIVATE KEY-----注意第一行和最后一行也是要添加进去的，不然 GitHub actions 会提示 id_rsa 格式不正确。
对应的配置文件代码段：
# 4、部署到 Gitee Pages
- name: Build Gitee Pages
uses: yanglbme/gitee-pages-action@main
with:
# 注意替换为你的 Gitee 用户名
gitee-username: somenzz
# 注意在 Settings->Secrets 配置 GITEE_PASSWORD
gitee-password: ${{ secrets.GITEE_PASSWORD }}
# 注意替换为你的 Gitee 仓库，仓库名严格区分大小写，请准确填写，否则会出错
gitee-repo: somenzz/somenzz
# 要部署的分支，默认是 master，若是其他分支，则需要指定（指定的分支必须存在）
branch: master这里就很简单了，用户名可以明文，密码一定要放在 secrets 环境变量中，即使仓库开源，也不至于泄漏自己的登录密码信息，这一步依然是在仓库 1 的设置页面添加 secrets 环境变量，和前述的操作一样，不在赘述。
对应的配置文件代码段
# 5、部署到 somenzz.cn 服务器
- name: rsync deployments
uses: burnett01/rsync-deployments@4.1
with:
# 这里是 rsync 的参数 switches: -avzh --delete --exclude="" --include="" --filter=""
switches: -avzh
path: public/
remote_path: /home/ubuntu/public/
remote_host: somenzz.cn
remote_port: 22
remote_user: ubuntu
remote_key: ${{ secrets.MY_UBUNTU_RSA_PRIVATE_KEY }}这个是自购服务器的私钥，一般情况下云服务器都会提供一个私钥文件，推荐你使用私钥登录服务器，和第二个参数的原理是一致的，如果服务器没有给你这个私钥，请自行生成一个可用于登录的私钥。
这里用到了 rsync，是一个增量同步工具，可以只传输有变化的文件，大大减轻网络带宽，具体的使用方法可参考阮一峰老师的教程
以上 4 个参数配置完成之后，就可以对仓库 1 push，然后点开 GitHub 上的 actions 看下执行过程。
$ cd xxx/push_blog/
$ git add -u
$ git commit -m "add article"
$ git push打开 GitHub 上的 push_blog 仓库，点击 Actions，可以看到部署的结果，结果的标题就是 commit 信息，如下图所示：
点击标题，可以看到详细情况：
再点击，可以看到每一个 action 的详情：
接下来就是访问下网站是否正常：
https://somenzz.github.io
https://somenzz.gitee.io
https://somenzz.cn强制刷新下，看看新增的文章是否已经到位。
你会问了，如果报错了怎么收到通知？ 点击 Notifications 添加接受通知的邮件即可，如下图所示：
如果觉得邮件不方便，想发送到微信，可以自己编写 Python 爬取 Actions 的结果，再使用 Server酱发送到微信，使用方法参考前文为什么很多开源项目都使用了 Server酱
如果要学习 GitHub Actions 来实现自己的部署流程，以下学习资源供你参考：
- GitHub Actions 入门教程。
- GitHub Actions 官方文档。
- GitHub Actions 官方插件市场。
- awesome-actions。
GitHub 的 Actions 除了支持 push 触发，也支持 schedule 触发，这就可以玩出很多花样了，比如你可以在仓库中写一个脚本，然后编写 workflow 让 GitHub 每天定时执行，相当于免费获得了服务器的计算资源，可以参考阮一峰老师的文章GitHub Actions 教程：定时发送天气邮件, 对于没有服务器跑定时任务的人来说真的是一大福利。
本文讲述了如何编写 workflow，让 GitHub Actions 自动化部署静态博客，可以让程序员专心的写博客，无需处理重复的部署操作，提升写作效率。在这里抛砖引玉，供各位博客大佬参考使用，不写博客，也可以修改下，变成自己的部署工作流。最后，GitHub Actions 是一个 CI/CD（持续集成/持续部署）工具，值得每一个程序员学习使用。
如果你觉得本文有价值，请点赞或分享给需要的朋友，谢谢支持。
2022年5月17日，作者终于更新了Gridea，可以去下载新版本使用新功能解决同步失败
作者已弃用一年多未更新的 Gridea 转用 Hugo，已无 Gridea 写作环境，以下内容仅做存档，请勿私信问我相关问题
此方法用于同步失败，控制台报错：ETIMEOUT与ECONNREST
基于原开发者一直没有更新解决办法。Github 同步失败又多半是国内网络情况原因，所以我只好自己动手丰衣足食找到其中一个适合我的解决办法了，也希望对某些特殊情况的不想使用梯子的有所帮助。
由于 Gridea 0.9.2 使用的是新的内置 git，使用开发者边车工具没法代理它。所以我们得改一下
注意：需自己已单独安装了 Git ，并且去 Gitee/dev-sidecar 或 Github/dev-sidecar 安装开发者边车辅助工具，为什么非要安装这个工具你去它主页看就知道了，对这软件对以后也有帮助。
安装我已做好修改的版本安装包地址，卸载原先的再安装这个。不放心的继续看下面
已安装 Node.js、Git、yarn
Node.js 版本需大于 v10.0.
git clone https://github.com/getgridea/gridea.git
cd gridea此时把文件packege.json里的"isomorphic-git": "^0.78.3",替换为"simple-git": "^1.107.0",。
未安装 yarn 先 npm install -g yarn安装，然后到 Github 切换 Tags 把 0.9.1 版本的 gridea\src\server\deploy.ts 复制到新版本里覆盖。
yarn
yarn electron:serve
yarn electron:build命令行跑完后在\gridea\dist_electron找到安装包
转载自 Github Gridea 仓库下 issue #886
在Python中，一边循环一边计算的机制，称为生成器：generator。
列表所有数据都在内存中，如果有海量数据的话将会非常耗内存。
如：仅仅需要访问前面几个元素，那后面绝大多数元素占用的空间都白白浪费了。
如果列表元素按照某种算法推算出来，那我们就可以在循环的过程中不断推算出后续的元素，这样就不必创建完整的list，从而节省大量的空间。
简单一句话：我又想要得到庞大的数据，又想让它占用空间少，那就用生成器！
第一种方法很简单，只要把一个列表生成式的[]改成()，就创建了一个generator：
>>> L = [x * xforxinrange(10)]
>>> L
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
>>> g = (x * xforxinrange(10))
>>> g
<generator object <genexpr> at 0x1022ef630>创建L和g的区别仅在于最外层的[]和()，L是一个list，而g是一个generator。
方法二， 如果一个函数中包含yield关键字，那么这个函数就不再是一个普通函数，而是一个generator。调用函数就是创建了一个生成器（generator）对象。
（1）生成器(generator)能够迭代的关键是它有一个next()方法，工作原理就是通过重复调用next()方法，直到捕获一个异常。
（2）带有 yield 的函数不再是一个普通函数，而是一个生成器generator。
可用next()调用生成器对象来取值。next 两种方式 t.__next__() | next(t)。
可用for 循环获取返回值（每执行一次，取生成器里面一个值）
（基本上不会用next()来获取下一个返回值，而是直接使用for循环来迭代）。
（3）yield相当于 return 返回一个值，并且记住这个返回的位置，下次迭代时，代码从yield的下一条语句开始执行。
（4）.send() 和next()一样，都能让生成器继续往下走一步（下次遇到yield停），但send()能传一个值，这个值作为yield表达式整体的结果
——换句话说，就是send可以强行修改上一个yield表达式值。比如函数中有一个yield赋值，a = yield 5，第一次迭代到这里会返回5，a还没有赋值。第二次迭代时，使用.send(10)，那么，就是强行修改yield 5表达式的值为10，本来是5的，那么a=10
感受下yield返回值的过程（关注点：每次停在哪，下次又开始在哪）及send()传参的通讯过程，
思考None是如何产生的（第一次取值：yield 返回了 i 值 0，停在yield i，temp没赋到值。第二次取值，开始在print，temp没被赋值，故打印None，i加1，继续while判断，yield 返回了 i 值 1，停在yield i）：
好了，话不多说，翠花，上栗子：
#encoding:UTF-8
def yield_test(n):
for i in range(n):
yield call(i)
print("i=",i)
print("Done.")
def call(i):
return i*2
for i in yield_test(5):
print(i,",")结果：
>>>
0 ,
i= 0
2 ,
i= 1
4 ,
i= 2
6 ,
i= 3
8 ,
i= 4
Done.
>>>理解的关键在于：下次迭代时，代码从yield的下一条语句开始执行。
什么是生成器？
生成器仅仅保存了一套生成数值的算法，并且没有让这个算法现在就开始执行，而是我什么时候调它，它什么时候开始计算一个新的值，并给你返回。
练习题：
def count_down(n):
whilen >= 0:
newn =yield n
print('newn', newn)
if newn:
print('if')
n = newn
print('n =', n)
else:
n -= 1
cd = count_down(5)
for i in cd:
print(i,',')
ifi == 5:
cd.send(3)结果：
https://sojo.im/slscq/?continueFlag=7b9f9135f6f94810da7f1d2a95d4686c
申论生成器
这个静态博客的工具主要是把md文档转为html静态网站/博客。github链接：
rust-md-site-tool首先说明md文档转为静态网站/博客的原理，就是先做一个目录文档，叫做summary.md，然后其他文档都会链接到这个目录文档里。当把md文档转为html时，需要对链接进行处理，保证链接可以正常跳转，这样就完成了一个简单的md转静态博客工具。
这个简易的博客/站点工具主要是模仿gitbook，可以认为是gitbook的简易版。页面布局也是gitbook一样，左边是目录，右边是内容。
首先需要定义一个博客的静态目录结构，如下图所示： 1. docs目录是所有md文档源文件； 2. static目录是所有静态文件的存放目录，比如js，css，image文件； 3. md_config.toml是全局配置文件， 4. summary.md是全局站点的目录； 5. index.md是全局首页内容
├── docs
│ ├── chapter1
│ │ ├── chapter1.html
│ │ ├── chapter1.md
│ ├── chapter2
│ │ ├── chapter2.html
│ │ ├── chapter2.md
│ ├── index.md
│ └── summary.md
├── md_config.toml
└── static
├── css
│ └── style.css
├── images
└── jssummary.md格式如下：
* [章节1](chapter1/chapter1.md)
* [小节1.1](chapter1/section1.1.md)
* [小节1.2](chapter1/section1.2.md)
* [章节2](chapter2/chapter2.md)
* [小节2.1](chapter2/section2.1.md)
* [小节2.2](chapter2/section2.2.md)配置文件结构如下：
title = "My Blog"
author = "Your Name"
description = "This is my blog."
port = 9900
static_dir = "static"
md_source_dir = "docs"
output_dir = ".site"
default_css_header = "<link rel=\"stylesheet\" href=https://www.zhihu.com/topic/20036297/\"https://www.zhihu.com/topic/20036297/css/style.css\">"
default_code_header = "<link rel=\"stylesheet\" href=https://www.zhihu.com/topic/20036297/\"https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.3.1/styles/default.min.css\"><script src=https://www.zhihu.com/topic/20036297/\"https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.3.1/highlight.min.js\"></script>"
default_code_plugin = "<script>hljs.highlightAll();</script>"本质上是一个命令行工具，依赖clap=4.4.0来创建，第一版支持三个命令： 1. init，初始化一些目录和配置文件 2. build，构建所有的文件，转为html到指定的输出目录 3. run，本地运行，在本地预览
由于要实现md文件转为html，需要借助依赖pulldown-cmark = "0.9"。
创建main.js，把三个命令写出来：
fn main() {
let matches = Command::new("rust-md-blog-tool")
.version("1.0")
.author("Your Name")
.about("A simple static site generator")
.subcommand(Command::new("init")
.about("Initializes the blog with default configuration"))
.subcommand(Command::new("build")
.about("Builds the static site from markdown files"))
.subcommand(Command::new("run")
.about("Runs a local server to view the blog"))
.get_matches();
match matches.subcommand() {
Some(("init", _)) => init_lib::init_command(),
Some(("build", _)) => build_lib::build_command(),
Some(("run", _)) => server_lib::run_command(),
_ => println!("Invalid command or no command provided"),
}
}
init命令就是创建一个默认的配置文件，以及六个目录和一个css文件。 核心代码如下： 1. config_content是默认的配置文件内容，可以自定义字符串或者使用模板文件； 2. get_style_content是默认的css文件，可以自定义字符串或者使用模板文件； 3.
let _ = File::create("md_config.toml").and_then(|mut file| file.write_all(config_content.as_bytes()));
// 创建所需的目录
let _ = fs::create_dir_all("docs").map(|_| println!("created 'docs' Success"));
let _ = fs::create_dir_all(".site").map(|_| println!("created '.site' Success"));
let _ = fs::create_dir_all("static").map(|_| println!("created 'static' Success"));
let _ = fs::create_dir_all("static/js").map(|_| println!("created 'static/js' Success"));
let _ = fs::create_dir_all("static/css").map(|_| println!("created 'static/css' Success"));
let _ = fs::create_dir_all("static/images").map(|_| println!("created 'static/images' Success"));
let _ = File::create("static/css/style.css").and_then(|mut file| file.write_all(get_style_content().as_bytes()));
println!("Blog initialized with default configuration.");
构建所有的md文件流程也很简单：
graph TB
A(开始build) --> B(扫描配置文件)
B(扫描配置文件) --> C(解析配置文件)
C(解析配置文件) --> D(扫描md文件目录)
D(扫描md文件目录) --> E(扫描配置文件)
E(扫描md文件目录) --> F(遍历解析md文件)
F(扫描md文件目录) --> G(复制静态资源)核心代码如下：
pub fn build_command() {
// ... 读取配置文件和设置目录 ...
let config = fs::read_to_string("md_config.toml").expect("Unable to read config file");
let parsed_config = config.parse::<Value>().expect("Unable to parse config");
let source_dir = parsed_config.get("md_source_dir").and_then(Value::as_str).unwrap_or("docs");
// .....
println!("load config source_dir :{}, output_dir:{}", source_dir, output_dir);
let md_source_dir = Path::new(source_dir);
let summary_path =format!("{}{}", source_dir, "/summary.md");
// 解析 summary.md 并构建目录HTML
let toc_html = build_toc_content(summary_path.clone());
// 解析每个.md文件 转为HTML
let md_files = read_dir_recursive(md_source_dir).expect("read md dir failed");
// 为每个Markdown文件生成HTML页面
for entry in md_files {
let path = entry;
if path.ends_with("summary.md"){
continue;
}
let output_file_path = transform_path(&path, source_dir, output_dir);
if path.extension().and_then(|s| s.to_str()) == Some("md") {
let mut md_content = String::new();
File::open(&path).and_then(|mut file| file.read_to_string(&mut md_content)).expect("Failed to read Markdown file");
let parser = Parser::new(&md_content);
let mut html_content = String::new();
html::push_html(&mut html_content, parser);
let _ = html_content.replace(".md", ".html");
let output_file = output_file_path.with_extension("html");
println!("output file:{}", output_file.as_path().display());
let mut full_html;
// 处理index页面逻辑
full_html = format!("<html><head></head><body><div class=\"toc\">{}</div><div class=\"content\">{}</div></body></html>", toc_html, html_content);
full_html = append_html(&full_html, "</head>", &[default_css_header, default_code_header]);
// 增加highlight.js处理代码块
full_html = append_html(&full_html, "</body>", &[default_code_plugin]);
// 处理相对路径
if contains_sub_dir(&output_file, output_dir){
full_html = full_html.replace("https://www.zhihu.com/topic/20036297/", "https://www.zhihu.com/topic/").replace("<a href=https://www.zhihu.com/topic/20036297/\"", "<a href=https://www.zhihu.com/topic/20036297/\"https://www.zhihu.com/topic/")
}
if let Some(parent) = output_file.parent() {
// 创建所有必要的父文件夹
fs::create_dir_all(parent).expect("create html parent dir failed");
}
fs::write(output_file, full_html).expect("Failed to write HTML file");
}
}
// ... 复制静态资源 ...
// 定义静态资源目录和目标目录
let static_dir = Path::new(static_dir);
let output_dir = Path::new(output_dir);
// 复制静态资源
if static_dir.exists() {
copy_dir_all(static_dir, output_dir).expect("Failed to copy static files");
}
println!("Site built successfully.");
}
生成html文件这里需要注意几个点： 1. 第一个是文件路径，需要把html生成到配置的输出目录，需要一个path转换逻辑； 2. summary里面的链接需要处理，默认是.md，需要转为.html； 3. 所有链接的相对路径需要处理，根据目录都是用相对路径； 4. 复制静态资源时，也需要注意文件路径，以及文件夹是否存在。
这里由于只是本地运行查看html，所以选择tiny_http，启动一个简单的http服务。核心代码如下：
pub fn run_command() {
// 读取配置文件
let config = fs::read_to_string("md_config.toml").expect("Unable to read config file");
let parsed_config = config.parse::<Value>().expect("Unable to parse config");
let port = parsed_config.get("port").and_then(Value::as_str).unwrap_or("9900");
let output_dir = parsed_config.get("output_dir").and_then(Value::as_str).unwrap_or(".site");
let address = format!("0.0.0.0:{}", port);
let server = Server::http(address).unwrap();
println!("Running local server on port {}", port);
for request in server.incoming_requests() {
let url = if request.url() == "/" {
"/index.html" // 使用 index.html 作为根路径的默认页面
} else {
request.url()
};
let file_path = PathBuf::from(output_dir).join(&url[1..]); // 移除 URL 的首个斜杠
match fs::read(&file_path) {
Ok(contents) => {
let response = Response::from_data(contents).with_header(
Header::from_bytes("Content-Type", "text/html; charset=utf-8").unwrap(),
);
request.respond(response).unwrap();
}
Err(_) => {
let response = Response::from_string("Not Found").with_status_code(404);
request.respond(response).unwrap();
}
}
}
}
这里需要注意的是，直接返回html会中文乱码，所以统一都加了Content-Type", "text/html; charset=utf-8。
新建一个用于测试的博客目录：
1. 在博客工具目录执行cargo run生成执行的命令文件;
2. 复制博客工具命令，cp target/debug/rust_md_site_tool ~/.cargo/bin;
3. 执行 rust_md_site_tool init初始化博客；
4. 在docs目录新建summary.md和index.md，并在summary里创建好测试的md文档和链接;
5. rust_md_site_tool build构建目录;
6. 打开浏览器 http://localhost:9900/ ;可以访问index.html;
京公网安备11000000000001号
京ICP备11000001号
还没有评论，来说两句吧...