Hexo & Next 的配置，做自己的主人

Hexo 篇

什么是 Hexo？

这是官方解释：

Hexo 是一个快速、简洁且高效的博客框架。Hexo 使用 Markdown（或其他渲染引擎）解析文章，在几秒内，即可利用靓丽的主题生成静态网页。

安装（详细过程这里就不再阐述）：

• 安装 Git，分散式版本控制软件
• 安装 Node.js，一个基于 Chrome V8 引擎的 JavaScript 运行时
• 使用 npm 安装 Hexo，npm 是 node.js 的包管理器

常用命令

这里是从官网上摘录的一些我们日常中经常使用的命令：

• hexo init [folder]：新建一个网站。
  • 如果没有设置 folder ，Hexo 默认在目前的文件夹建立网站。
• hexo new [layout] <title>：新建一篇文章；
  • 如果没有设置 layout 的话，默认使用 _config.yml 中的 default_layout 参数代替；
  • 如果标题包含空格的话，请使用引号括起来；
  • hexo publish [layout] <filename>：发表草稿
• hexo g：生成静态文件；
  • hexo g -f：效果接近 hexo clean && hexo generate
• hexo d：部署网站
  • 常用组合：hexo g -d
• hexo server:启动服务器。
  • 默认情况下，访问网址为： http://localhost:4000/
• hexo clean：清除缓存文件 (db.json) 和已生成的静态文件 (public)
  • 在某些情况（尤其是更换主题后），如果发现您对站点的更改无论如何也不生效，您可能需要运行该命令

文件组织结构

1
2
3

$ hexo init <folder>
$ cd <folder>
$ npm install

Hexo 在指定文件夹中初始化完毕后，会出现如下文件结构：

1
2
3
4
5
6
7
8

.
├── _config.yml
├── package.json
├── scaffolds
├── source
|   ├── _drafts
|   └── _posts
└── themes

在后面的实际使用过程中还会创建一些其他文件或文件夹，后面都会进行说明。

_config.yml

网站的配置信息，在此修改大部分的配置参数；

• 这里直接查看内容，就能理解大部分的配置内容，如果实有不懂，更建议可查看官方文档，如下；

详见：『配置 | Hexo』

package.json

应用程序的信息。可以查看 hexo 的版本以及安装的扩展版本。

scaffolds

模版 文件夹。当新建文章时，Hexo 会根据 scaffold 来建立文件。
详见：『模版 | Hexo』

source

资源 文件夹是存放用户资源的地方。

_posts 文件夹

存放博客文章的地方，其中的 Markdown 文件、Html 文件、org 文件等会被解析并放到 public 文件夹，发布到站点。

• 建议在这个文件夹下，按照文章分类创建子文件夹（按分类正常命名即可，不要加_(下划线)，便于文章过多时进行管理和维护；

其他开头命名为 _ (下划线)的 文件/文件夹 和隐藏的文件

会被忽略；

• 建议在 source 目录下：
• 创建 _drafts 目录：存放未完成的草稿，其中内容不会发布到网站；
  • 可以再在这个目录下创建个子目录 img，便于 blog 草稿书写时利用 ./img/picturename.png 引用本地图片，然后可以直接将整个文件夹上传至图床，然后再用匹配，一键替换 ./img 为完整的图床 url；
• 创建 _images 目录：图片一般会用图床，但是这样可以保存文章里的图片备份，后期可以上传到 coding 等平台进行 Blog 备份，避免数据丢失；

其他文件/文件夹

会被拷贝到 public 目录并上传到站点；

• 如果要添加新的页面（例如：about），执行 hexo new page PageName 命令即会在 source 中自动新建子目录 PageName

themes

主题 文件夹。默认安装 landscape 主题，可以安装新主题到 themes 目录，也可以自己新建主题。

这也是我们下面要讨论的 Next 主题文件存放的文件夹；

.deploy_git

在部署到 github 后自动创建：

• 此目录中的内容 == github 站点中对应 repository 中的内容 == 最近一次上传到站点的public目录中的内容

因此，该目录的结构和 public 目录基本一致；

• 不一致的情况是由于重新生成，但是没有发布站点造成，此时 public 内容新于 .deploy_git 内容；

node_modules

存放安装的 Hexo 扩展；

• Hexo 会默认安装一些扩展，在使用过程中自己安装的扩展也会在此新建目录；

public

存放生成的静态网页内容；

• 执行 hexo g 命令，Hexo 程序会解析 source 、当前使用的 theme，将生成的静态网页内容保存到 public；
• 执行 hexo d 则将该目录内容复制到 .deploy_git 目录，然后由 Hexo 的部署插件 hexo-deployer-git 根据 _config.yml 里的 deploy 配置，完成上传；

.git 和 .gitignore

这个主要是用于 Blog 源资源的备份，防止电脑故障后数据丢失，也便于 Blog 的迁移；

• 直接在 coding（这个源文件往往比较大，coding速度快） 新建仓库，然后在本地 blog 源文件夹下初始化，生成 .git；
• .gitignore：整个 Blog 源文件夹下，往往有许多文件是不需要我们去备份的，于是，我们就把这些不需要备份的文件/文件夹写到这里；

db.json

db-json 是完全在 json 中的数据库。数据库，查询和结果都是 json 数据。它在客户端和服务器端均可使用。
数据库结构化，表由类型化字段组成，并带有可选验证（模式，长度，范围）
该库在浏览器和节点上均可使用。
dabase 的 json 代码是人类可读的，并且可以方便地在手边进行编辑。 如果发生任何错误，则在使用该 json 代码实例化新的 Database 对象时将检测到它们。

package-lock.json

package-lock.json 是在 npm install 时候生成一份文件，用以记录当前状态下实际安装的各个 npm package 的具体来源和版本号；

以下是引用的知乎@周载南的解释：

• 因为 npm 是开源世界，各库包的版本语义可能并不相同，有的库包开发者并不遵守严格这一原则：相同大版本号的同一个库包，其接口符合兼容要求。
• 这时候用户就很头疼了：在完全相同的一个 node.js 的代码库，在不同时间或者不同 npm 下载源之下，下到的各依赖库包版本可能有所不同，因此其依赖库包行为特征也不同有时候甚至完全不兼容；
• 因此 npm 最新的版本就开始提供自动生成 package-lock.json 功能，为的是让开发者知道只要你保存了源文件，到一个新的机器上、或者新的下载源，只要按照这个 package-lock.json 所标示的具体版本下载依赖库包，就能确保所有库包与你上次安装的完全一样。

所以也就是说，原先的 package.json 只能帮助我们锁定大版本号（即：第一位），但是由于有的库包开发者并没有严格遵守规则，从而可能出现大版本号下的小版本不兼容等问题，让我们在更新或者迁移到新机器进行环境安装时出现各式各样的问题，package-lock.json 由此赢然而生，当我们每次安装一个依赖的时候就锁定在你安装的这个版本。

NexT 篇

首先要说的是，很多人在网上查找的 NexT 主题安装和配置教程都比较早，他们给出的 NexT 地址是 「 https://github.com/iissnan/hexo-theme-next 」，但这个项目在 2017 的时候就宣布不再维护了，之后 2018-2019 年将 NexT 的地址变更为：「 https://github.com/theme-next/hexo-theme-next 」，2020 年最新的地址为：「 https://github.com/next-theme/hexo-theme-next 」

经过不断的版本迭代，NexT 目前已经提供了非常丰富的配置来满足使用者的个性化需求，在配置主题时，如果你像我一样对前端不是特别擅长，那么我更推荐使用官方推荐的方式配置主题，多挖掘博客自带的功能，尽可能少得修改源码。

我使用的 NexT 版本号为 7.8.0，请先到 themes -> Next -> package.json 里查看一下你的 NexT 版本，酌情考虑升级。新版本的官方主题配置内容会比以前会丰富，也更加简单。

安装和使用

直接到你的 Blog 的 themes 文件夹下 git clone 整个 NexT 仓库即可；
官方给出的教程：

1
2

$ cd hexo
$ git clone https://github.com/next-theme/hexo-theme-next themes/next

下载后，打开 Hexo 站点配置文件，找到 theme 部分，然后将其值更改为 next（或另一个主题目录名称）；使用 hexo clean 清理缓存，然后 hexo s ，就可以去验证主题了。

文件组织结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

.
├── .github         # git 信息
├── docs            # 官方的一些文档说明信息，不用管
├── languages        # 多语言，我们常关注的是下面几个个
|   ├── default.yml    # 默认语言
|   └── zh-CN.yml      # 简体中文
|   └── zh-HK.yml      # 繁体中文
|   └── zh-TW.yml      # 繁体中文
├── layout             # 存储相关的布局信息
|   ├── _macro        # 可以自己修改的模板，覆盖原有模板
|   |   ├── post.swig    # 文章模板
|   |   ├── sidebar.swig   # 侧边栏模板
|   |   ├── post-collapse.swig    # 没动过，理解为文章崩溃后显示的模板文件
|   ├── _partial       # 有关文章、标题、页面等更加细节的局部布局，如果不是很懂建议不动
|   ├── _script        # 一些脚本的局部布局
|   ├── _third-party   # 第三方模板
|   ├── _layout.swig   # 主页面模板
|   ├── index.swig     # 一些索引模板
|   ├── archive.swig   # 一些解题实现的模板
|   └── page.swig / tag.swig / post.swig / category.swig    # 相应模块的主控制模板
├── scripts            # script 源码
├── source             # 源码资源
|   ├── css            # *.styl 的 css 源码
|   ├── images         #图片
|   ├── js             # javascript 源代码
|   └── lib            # 其他的库文件
└── _config.yml        # 主题配置文件

Stylus 比较年轻，是一个 CSS 的预处理框架，2010 年产生，来自 Node.js 社区，主要用来给 Node 项目进行 CSS 预处理支持，可以创建健壮的、动态的、富有表现力的CSS。默认使用 .styl 的作为文件扩展名，支持多样性的 CSS 语法。

SWIG 是一种简化脚本语言与 C/C++ 接口的开发工具。SWIG 是一个通过包装和编译 C/C++ 语言程序来达到与脚本语言通讯目的的工具。推荐个学习地址：『Swig：一个适用于 Node.js 和浏览器的模板引擎』

看了上面的文件结构后，我们大致就知道所需要修改的信息应该在哪部分。通常，只需要修改 NexT 的 _config.yml 文件即可，配置初建议把这个文件都过一遍，然后根据自己的需求更改，里面也会有许多网上可能没提到过的配置。
记住不要一味的参照网上各式各样的配置教程，许多时候因为版本不同，配置的方式也不同，可能导致修改许多本没必要的位置，加入杂乱的代码等等，长时间后，我们可能自己都忘了曾经修改过啥，这样十分不利于后期的维护，和 NexT 的更新。

官方配置教程

详见：『官方配置文档』

看完官方文档，发现我的 Blog 也还有一些配置的地方，不说了，我先行一步！别光看了，do it，加油！