前置说明

本文中将会使用到 Hexo 作为博客框架生成静态文件，GitHub Page 用来存储托管静态网页，Markdown 作为博客的写作语言，Typora 作为本地的 Markdown 编辑器，PicGo 作为图床上传工具。

为什么要搭建个人博客

• 创作教程向的博客是对费曼学习法的很好实践，在输出知识的过程中帮自己很好地梳理知识并查漏补缺，从而真正掌握它。
• 将学习所得总结成博客，给自己一个积极的成果反馈，增加学习的快感。
• 将本地博客上传到网络可以随时随地通过浏览器访问，相比云笔记软件，博客更加开放正式，给人以仪式感，也能让执键盘者能认真对待。
• 有一个个人专属的空间可以写一些东西，或是记录自己的学习心得体会，或是写一些碎碎念输出自己的观点，面对匿名访客不会像空间和朋友圈一样有心理负担。
• 发扬互联网分享的精神，向互联网分享自己的经验，有可能会帮助到他人。
• 搭建自己的博客站点相比使用平台提供的博客托管服务，自主性更高，可以随意定制，大胆折腾，可玩性更高。
• 可以绑定自己的专属域名，逼格更高。
• 在搭建博客的过程学习顺带网站的构建部署以及一些前端知识。
• 高质量的博客可以给简历加分。

为什么是 Hexo

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

以上是 Hexo 的官方中文文档中的介绍，由于此前并没有任何使用其他博客框架的经历，所以也说不出相对 WordPress、Hugo 等其他框架的优缺点。之所以使用 Hexo 完全是因为网上的安利以及教程很多，所以也就跟风选择了 Hexo。

为什么是 Markdown

Markdown 是一种轻量级的标记语言，使用 Markdown 写作可以让创作者专注于文字内容本身而不用过多的关心排版。Markdown 格式的文档介于纯文本和富文本之间，相比无格式的纯文本，Markdown 可以渲染出样式辅助表达必要的排版逻辑让文章结构美观清晰，相比富文本例如 Word 文档，不用在文字输入和复杂的排版之间来回切换，沉浸感更强。而相比其他的标记语言例如 HTML，Markdown 语法更加简单，容易上手，使用起来也更加灵活方便。此外 Markdown 还有以下优点：

• 越来越多的互联网创作平台如「知乎」、「简书」都提供了对 Markdown 格式的支持，在各个平台都能有相对统一的渲染效果。
• 使用的是纯文本格式存储，可以使用任何文本编辑器打开和编辑。
• 必要时可以很方便的导出成 HTML 、Word 和 PDF 文档。

花几十分钟学习一下简书官方的 Markdown 教程：献给写作者的 Markdown 新手指南，利用简书的在线 Markdown 编辑器体验几种常用的标记语法，熟练后就足以应付绝大多数 Markdown 应用场景。

为什么是 Typora

上面提到任何文本编辑器都可以打开和编辑 Markdown 文档，普通文本编辑器虽然能显示 Markdown 文本和编辑，但是却无法渲染出我们想要的格式，所以还是很有必要选择一款专用的 Markdown 的编辑器。而 Typora 就是一款为 Markdown 而生的编辑器。它有以下优点：

• 支持 Markdown 即时渲染，不用分屏预览，所见即所得。
• 功能强大，对 Markdown 所有的语法都支持，虽然有很多复杂语法可能以后永远都用不上。
• 软件颜值很高，自带 6 个主题，官网还有更多主题可供选择。
• 即使不熟悉一些 Markdown 语法也能使用菜单或者快捷键来添加格式。
• 最大可能的遵循 GitHub Flavored Markdown 的渲染标准，此标准在原有 Markdown 语法的基础上添加了少量新特性使用起来对程序员更加友好，并且这些特性在 GItHub 的页面上都能完美的显示，所以用 Typora 来写项目的 Readme.md 文档会很合适。
• 有复杂排版需求时可以直接嵌入 HTML 代码到 Markdown 文件中，也能渲染显示出来。
• 通过开发者选项可以自定义 CSS，深度修改定制属于自己的渲染样式。
• 最新版支持 PicGo 插件，可以一键调用 PicGo 自动上传图片到图床。

Hexo 的安装和配置

Hexo 的安装

安装 Hexo 相当简单，只需要先安装下列应用程序即可：

• Node.js (Node.js 版本需不低于 10.13，建议使用 Node.js 12.0 及以上版本)
• Git

Node.js 的安装只需到官网下载安装包一路下一步即可，安装后建议把 npm 的镜像源切换到国内，能极大提高 npm 包的下载安装速度。

Git 安装和配置可以参考我这篇博客：Git 和 GitHub 学习笔记。

确保成功安装并配置号以上两款软件后，在适当位置创建一个空的文件夹作为自己的 Hexo 博客项目的工作目录。

在该目录下打开终端，使用 cmd 或者 git bash 作为 shell 均可。

在终端中输入以下命令运行来安装 Hexo 命令行工具。

npm install -g hexo-cli 

如果中途出现终端长时间无响应的情况请检查网络状况或使用管理员模式打开终端再次尝试上面命令安装。

安装成功后不要退出终端，也不要切换路径，继续输入以下命令并运行，在当前目录下初始化一个 Hexo 博客项目。

hexo init 

初始化过程因为要克隆远程 GitHub 仓库，可能出现以下错误。请确保自己的网络能正常访问 GitHub，必要时手动修改 hosts 文件或者使用网络代理。

初始化完毕后依次运行下面三条命令。

#生成名为 my first blog 的文章
hexo new "my first blog"

#根据 Markdown 文档生成博客静态文件，可以简写成 hexo g
hexo generate

#在本地启动一个 http 服务器，默认情况下，访问网址为： http://localhost:4000/
hexo server

如果上面三条命令运行成功，接下来可以打开浏览器访问 http://localhost:4000/ 来预览自己的博客页面了。终端可能会弹出一些警告，不用理会它，可以在终端使用 Ctrl + C 手动结束掉 Hexo 的服务器模块。

部署到 GitHub Pages

以上我们使用 Hexo 框架搭建了一个本地博客站点，不过只有在自己计算机的所在局域网才能访问到这些页面。接下来我们要把博客部署到 GitHub Pages 上。GitHub Pages 是 GitHub 官方提供的静态页面托管服务，我们可以通过 GitHub Pages 直接预览我们仓库中的一些静态网页。

首先我们需要在 GitHub 上创建一个空的公开的仓库，仓库名要严格符合格式：username.github.io，username 换成自己的 GitHub 用户名，请注意区分用户名和昵称的区别。

创建完仓库后我们要修改 Hexo 的配置文件来将远程的 GitHub 仓库绑定到我们本地的 Hexo 项目。

Hexo 项目的根目录下有一个名为 _config.yml 的配置文件，里面是我们的博客站点各种配置。

打开配置文件，在最后面填上部署方式和我们的刚才创建的仓库 地址以及分支名。

注意：YAML 格式的键值对在英文冒号后面一定要有一个空格，否则 YAML 将不能正常被解析。并且 YAML 依靠缩进来确定元素间的从属关系。请确保缩进长度相同，并且使用空格缩进。

deploy:
  type: git
  repo: git@github.com:Kiku-CN/Kiku-CN.github.io.git
  branch: master

部署方式填 git，仓库地址更改成自己的仓库地址，进入我们刚才创建的仓库页面即可看到地址。

仓库地址使用 HTTPS 或者 SSH 都可以，使用 HTTPS 需要在第一次部署时输入账号密码，使用 SSH 方式不需要输入账号密码但需要提前绑定自己的 SSH 公钥到 GitHub 上面。有关 SSH 公钥的配置请参考：使用 SSH 连接到远程仓库。

改好配置文件后，安装 Hexo 的 Git 自动部署插件。终端中输入以下命令并运行。

npm install hexo-deployer-git 

使用插件可以利用部署命令一键将本地静态页面推送到远端的 GitHub 仓库。

#将本地页面部署到远端仓库，命令可以缩写成 hexo d
hexo deploy

当执行 hexo deploy 时，Hexo 会将 public 目录中的文件和目录推送至 _config.yml 中指定的远端仓库和分支中，并且完全覆盖该分支下的已有内容。

提示部署成功后就可以通过 Github Pages 来访问自己博客了。访问的域名为：username.github.io。也就是我们之前创建的仓库名。

绑定域名

将自己的域名和 GitHub Pages 绑定起来，这样就可以通过自己的个性化域名来访问博客。没有域名的同学可以跳过这步。

首先我们需要到域名服务商购买一个自己喜欢的域名，然后进入服务商的域名管理界面。以 namesilo 为例，管理入口在右上方。

进入管理界面后删除原有所有的解析记录，然后添加一条 CNAME 记录指向自己的 GItHub Pages，再添几条 A 记录直接解析到自己的 GItHub Pages 的 IP 地址。

可以通过 Windows 自带的 nslookup 命令获取自己的 GitHub Pages 对应的 IP 地址。每个人对应的 IP 地址可能不一样。

绑定好解析记录后进入之前创建的名为 user.name.io GitHub 仓库的设置界面，请注意是仓库的设置界面，不是 GitHub 账号的设置界面。

在后面找到 GitHub Pages 设置项，填上注册的域名然后保存。

这样就可以通过自己的域名来访问博客页面了。

注意：在域名服务商页面修改 DNS 解析记录需要一段时间才能生效，如果通过自己的域名不能访问到博客页面，在检查上面几步操作无误的前提下耐心等待 DNS 记录生效就好。

回到仓库页面可以发现，刚才 GitHub 自动为我们在仓库下创建了一个名文 CNAME 文件，里面是我们刚才绑定的域名。我们到设置页面绑定域名的实质只是让 GitHub 帮我们自动生成了一个域名映射文件。

但是注意一点，这个文件是 GitHub 自动帮我们生成的，我们本地的仓库中是没有这个 CNAME 文件。如果我们将 Hexo 博客重新部署一遍过后，GitHub 仓库里的这个 CNAME 文件就会被同步而消失掉，又需要进入仓库设置页重新配置域名。

为了能让每次部署都能自动绑定自定义域名，我们需要创建一个名为 CNAME 的文本文件置于 Hexo 项目的 source 目录下，只有这样 hexo deploy 时才能将 CNAME 文件一并推送至远程 GitHub 仓库。

注意：CNAME 是一个纯文本文件，要和 GitHub 帮我们自动生成 CNAME 完全一致：文件名中不能带有任何后缀，文件内容为自己的域名，一定要放在 Hexo 项目的 source 目录下。

更改主题

到 Hexo 的主题页选取自己喜欢的主题，我们以 Fluid 主题为例进行下面的操作。

使用 git 命令克隆主题文件到自己的 Hexo 项目下的 themes 目录。

git clone https://github.com/Fluid-dev/hexo-theme-Fluid.git themes/Fluid

clone 结束后进入 themes 目录，除了 Hexo 自带的默认主题 landscape 外，应该还有一个名为 Fluid 的主题文件夹。

打开站点目录下的 _config.yml 配置文件，修改主题为 Fluid，注意：是 Hexo 项目目录下的 _config.yml 配置文件，而不是 themes 里面的主题配置文件。

theme: fluid

修改后保存配置，使用以下命令重新生成并部署博客。

#生成静态文件并立即部署网站，相当于依次运行 hexo generate，hexo deploy
hexo g -d

等待部署完毕后就可以看到更换主题后的效果了。

注意：如果发现自己对站点的更改无论如何也不生效（尤其是更换主题后），尝试运行下面的命令再重新生成部署。

#清除 Hexo 项目的缓存文件和已生成的静态文件 
hexo clean

站点配置

在 Hexo 项目的根目录下的 _config.yml 文件中可以修改有关博客站点的配置。下面对常用的配置项进行说明，更详细的配置请参考 Hexo 官方文档中的配置部分。

title: Hexo 	#网站的标题
subtitle: '' 	#网站的副标题，可以为空
description: '' #网站的简单描述，主要用于SEO
keywords:		#网站的关键词，主要用于SEO
author: Kiku  	#网站作者，用于主题显示文章的作者
language: zh-CN	#网站使用的语言，建议改成简体中文。
timezone: ''	#网站时区。Hexo 默认使用您电脑的时区。不用修改

注意：语言的配置需要和自己使用的主题文件夹中提供的一致， 不同的主题可能需要设置成不同的值，常见的有 zh-Hans 和 zh-CN。以 Fluid 主题为例，进入主题的 language 文件夹，里面提供了四种语言支持，中文对应的是 zh-CN.yml。

下图是 Fluid 主题的导航栏在language: en 和 language: zh-CN 下的效果示例。

本地调试

在调试博客样式的过程中，每次修改都部署到远程仓库是很不必要的。一是这样每次部署到远程需要等待上传文件更新完成，再查看修改后的效果，效率很低；二是这样会在 GitHub 上增加了很多无意义的 commit 记录，污染了时间线。

所以应该多多利用 Hexo 提供的本地服务器功能，在本地调试博客，等修改满意后再部署到 GitHub 仓库。

#启动服务器。默认情况下，访问网址为：http://localhost:4000/
hexo server

注意：Hexo 服务器模块会监视文件变动并自动更新，这样不用每次改动都重新生成部署才能预览改动后的效果。但是如果是修改了 Hexo 项目或者主题的配置文件，可能需要先使用 hexo g 重新生成静态文件才能看到更新后的效果。

配置 Fluid 主题

Fluid 官方提供了十分详实的中文配置文档，直接阅读官方文档，按需修改配置即可。

部署

将 Markdown 文章发布到博客

将在其他位置编辑好的 Markdown 文档直接复制到 Hexo 项目下的 source/_posts 目录下，这样在使用 hexo g 命令时这篇文档就会被解析生成一篇文章页。

也可以使用以下命令，或者手动在 source/_posts 目录下新建一个 Markdown 文档用来写作。

#可以在命令中指定文章的布局（layout），默认为 post，title 是文档的名称
hexo new [layout] <title> 

注意：Markdown 文档的文件名一定不能以空格结尾，例如 README .md，在解析时一篇 Markdown 文档会生成一个文件夹，而文件名末的空格会被带到文件夹中，而在 Windows 中文件夹末尾是不允许有空格的，这将导致该文件夹将无法被访问，也就无法被提交到远程 Git 仓库

使用 Front-matter 为文章指定属性

Front-matter 是 Markdown 文档文件最上方以 --- 分隔的区域，用于指定这篇文章的一些属性，优先级最大，也就说这些变量的值会覆盖掉 Fluid 的主题配置和 Hexo 的项目配置。

layout: 		#指定 Markdown 文档的渲染模板，默认是 post，会渲染成博客文章页，指定false则是不使用主题，直接解析 Markdown 文档生成网页。不同的主题的提供一些额外的布局模板，例如 Fluid 提供了 index，page，archive，category，about 这些模板。但是这些模板很少有机会手动指定，使用最多的就是 post，用来生成一篇文章
title:			#文章主标题，默认 Markdown 文档的文件名
author:  		#文章作者
date: 			#文章发布日期，时间日期格式：2019-10-10 10:00:00，默认为 Markdown 文档的创建日期
updated:		#文章更新日期，时间日期格式：2019-10-10 10:00:00，默认为 Markdown 文档的修改日期
comment:  		#开启文章的评论功能，默认值为 true，前提是已经在主题配置中已经配置好评论模块的参数，否则不显示
tags: 			#给文章添加标签
categories: 	#指定文章所属分类
excerpt: 		#指定摘要，也可以在 Markdown 文档使用 <!-- more --> 来划分摘要区域，不指定则默认自动选取摘要。优先级: excerpt 摘要 > Markdown 划分摘要 > 自动摘要
permalink: 		#指定 Markdown 文档解析后生成的路径，默认按照文章年月日来生成路径

注意：分类具有顺序性和层次性，也就是说 Foo, Bar 不等于 Bar, Foo；而标签没有顺序和层次。分类类似文件夹的组织方式，标签则使用起来更加灵活。

categories:
  - Diary
  - Life

会使分类Life成为Diary的子分类，而不是并列分类。如果你需要为文章添加多个分类，可以尝试以下 list 中的方法。

categories:
- [Diary, PlayStation]
- [Diary, Games]
- [Life]

此时这篇文章同时包括三个分类： PlayStation 和 Games 分别都是父分类 Diary 的子分类，同时 Life 是一个没有子分类的分类。

接下来这些属性均是在使用 Fluid 主题的前提下，使用其他主题不保证能产生相同效果。

subtitle: 		#子标题，默认值等于 title，更好的理解是详细标题，进入文章页后显示的是子标题而不是标题
index_img: 		#文章在首页的封面图，如果没在主题配置中设置默认封面，则默认不显示文章封面
banner_img: 	#文章页顶部大图，默认使用主题配置的图片
hide:			#把某些文章隐藏起来，会使文章在首页和分类里都不显示，隐藏后依然可以通过文章链接访问,默认值为 false
sticky:  		#为文章设置权重，可以用来给首页文章排序。数值越大，则权重越高，该文章在首页越靠前，默认值为0，设定正数来置顶文章，置顶文章标题会带有一个置顶图标，设为负数保证置尾

下面给出我们经常会用到的 Front-matter 属性，可以当做模板使用。

注意：使用 Fluid 主题不指定 title 属性会使文章的标题为空。如果想使用自动摘要，就不要添加 excerpt 这个属性，添加了这个属性必须指定一串字符值，否则解析时会报错。

title: 			#标题
date:  			#日期
excerpt: 		#摘要
tags: 			#标签
categories:		#分类
index_img: 		#封面
banner_img: 	#顶图

为 Typora 配置图床

如果在上面发布的 Markdown 文档里面引用了本地图片，会发现文章页中的图片没有正常显示。因为 Markdown 文档本质上还是一个纯文本，它只是引用了本地或者网络上的图片，而我们在 Markdown 中插入的本地图片并没有一同随文档上传到 GitHub 仓库。所以我们需要把图片也上传到网络（图床）上，这样才能在博客中正常显示。

如果只是简单地把图片和 Markdown 文档一同放在了 _post 目录下，并不能上传图片，因为 Hexo 默认是不会处理 _post 目录下的图片的。

现在为了让 Hexo 把图片也一起上传到远程 GitHub 仓库，我们有两种选择，一是修改 Hexo 的配置文件中 post_asset_folder 属性，这样 Hexo 在生成静态文件时会把和 Markdown 文档同名的文件夹里面的内容也一起复制到 public 目录，并在部署时一同上传。

这种上传图片的方式可以参考 Hexo 官方文档中的 资源文件夹说明，网上也已经有很多教程，但是这个方法有个问题就是使用 Typora 粘贴剪切板中的图片时生成的路径会多出一个 / 造成路径错误。

接下来分享的是另外两种配置图床方式。以下两种方法均使用 Typora 作为 Markdown 编辑器，所以请提前到 Typora官网 安装或升级到最新版本，旧版本可能不支持 PicGo 上传图片功能。

方法 1

在 source 目录下创建一个名为 images 的文件夹专门用于存放图片，Hexo 生成文件时不会处理 _post 下的图片，但是会把 source/images 这个文件夹复制到 public/images ，即部署后的站点根目录下，到时候可以通过绝对路径很方便的获取到 images 里面的图片。

首先修改 Typora 里面的图像设置如下图。这样当我们在 _post 目录下使用 Typora 进行 Markdown 写作时，插入的图片时会自动拷贝复制一份到../images，也就是我们之前创建的目录下。

注意：一定要使用相对路径。此外建议网络和本地都勾上，这样即使引用的网络图片被删除或者原来的本地图片被被移动的情况下图片引用都不会失效。

但是还有另外一个问题需要解决。在 _post 目录下的 Markdown 文档解析后的生成的 HTML 页面并不在 public/post/ 这个目录下（事实上也不存这个目录），而是在以日期命名的路径下面。例如在 _post 目录下有一篇名为 title.md 的 Markdown 文档，其日期属性为 date: 2020-12-3 ，部署后需要通过 主机名/2020/12/03/title/index.html 这个路径才能访问对应的文章页面。

这时如果我们在这个文档中粘贴一张图片，Typora 自动生成的图片引用为 ![](../images/example.jpg)，图片经过解析后生成的 HTML 标签为 <img src="../images/example.jpg" >，转化为绝对地址就是 <img src="主机名/2020/12/images/example.jpg" >，然而图片在网络上的所在地址是 主机名/images/example.jpg，所以图片没法正确的加载显示出来。

我们可以选择更改 Hexo 生成文章时的默认路径，让文章直接在部署到站点根目录下面的某一个文件夹下，而不经过年月日的层叠。

但我们使用的是另外一种方法：Typora 专门提供了一项设置可以解决这个问题：在 Front-matter 给文档添加如下的 typora-root-url 属性。

再次提醒：英文冒号后面一定要有空格！

typora-root-url: ../

新版 Typora 已经支持直接在菜单中设置图片根目录了，将 _post 目录的上一层 source 目录设为根目录。 Typora 会自动添加一条和上面一样的 YAML Front Matter 属性。

指定了图片根目录后 Typora 解析图片的相对路径时就会自动添加设置的这段路径。这时粘贴图片到文章中时，图片还是会拷贝到 source/images 下面，但是所生成的 Markdown 引用为 ![](/images/example.jpg)，解析成 HTML 图片标签的 src 值为 /images/example.jpg ，正好可以匹配到站点根目录下的 images 路径下的图片。

优点：

• 不用单独搭建图床仓库，也不用手动上传图片，直接把图片和 Markdown 文档一同部署到仓库。
• 直接在 _post 目录下创作，修改后保存重新生成部署即可生效。

缺点：

• 每篇 Markdown 文档都需要指定根目录属性，虽然可以利用 Hexo 的模版功能来解决，但是这样每次都必须通过命令行来创建新的 Markdown 文章。
• 所有文章的图片都集中在一个文件夹，后期不好管理。
• 图片和文章都在一个仓库中存储，有可能造成后期空间紧张。
• GitHub 在国内访问不是很稳定，造成图片加载很慢甚至加载不出来。

方法 1 适合那些直接在 _post 目录下写博客的人群，而下面的方法 2 则适合那些以前就使用过 Typora，已经习惯在某个文件夹下创作的人群。

方法 2:

首先在 GitHub 创建一个新的空仓库用作图床，仓库名可以任意。

创建一个新的分支用来存储图片，而不是直接使用默认分支，这样做有两点好处。一是上传照片到非默认分支可以避免被 GitHub 统计成 contribution，不会点亮主页的小绿点。二是在前期测试图床的过程中如果上传了一些测试图片可以方便利用删除分支功能来删除这些图片，而不是删除整个仓库再重新建新仓库。

安装 PicGo，建议直接安装最新的 beta 版本，旧版本容易出现各种端口冲突。

然后配置 PicGo 的 GitHub 参数。

仓库名和分支名使用上面自己创建的仓库和分支。注意：仓库名前要加上自己的 GitHub 账户名称。

在 Github 的账号设置页右侧找到 Developer settings 进入，生成一个新的 token。

Note 相当于给这个 token 取个名字，用来以后提示自己当初创建这个 token 的用途。权限范围只用勾上 repo 即可，token 生成后务必立即复制粘贴到 PicGo 的设置中来，页面关闭后将不可见，没复制上就只能选择再新建一个 token。

指定存储路径可以随意，建议还是指定个一级目录例如 photos/ 或者 imgs/，避免图片直接暴露在仓库最外面。

存储路径务必按照以下路径来填写，这样可以使用 jsdelivr 免费的 CDN 加快图片加载速度。其中 user 换成自己的 GitHub 名称， repo 换成自己的图床仓库名，branch 换成自己设定的分支名。

https://cdn.jsdelivr.net/gh/user/repo@branch

PicGo 配置完毕后回到 Typora 中的图像设置中来，还是选择方法 1 中一样的复制到指定路径的选项，不同的是这次我们把路径指定为./${filename} images，即插入图片时在当前目录新建一个文件夹专门用来保存某一篇 Markdown 中的图片。上传服务选择 PicGo（app），并关联到自己的 PicGo 安装路径，然后点击验证图片上传选项看上传是否成功。

Typora 支持在插入图片时就通过 PicGo 自动上传图片。但是使用 PicGo 上传到 GitHub 不是很稳定，容易出现各种上传失败。所以建议还是先把图片老老实实保存到本地，最后再集中上传。这样即使上传出错，直接全部重传就好。上传失败时多利用 PicGo 的日志来查找失败原因。

注意：一定要在 PicGo 的设置中开启时间戳重命名，确保上传的图片名称不会和之前上传的图片产生冲突。

建议在本地创建一个文件夹专门用来 Markdown 写作，引用图片生成图片文件夹也在此文件夹中，等某篇 Markdown 完成无需修改再将 Markdown 文档和对应的图片文件夹复制一份到 Hexo 下的 source/_post/ 目录里面，然后按照下图的方式集中上传整篇文档的图片到图床。

注意：一定要把图片文件夹也一起复制过来，因为我们前面设置的是相对路径，上传成功后图片文件夹可以删掉 。

注意：一次上传完所有图片后 Typora 会自动把 Markdown 文档中原来的本地图片引用地址替换成我们在 PicGo 中配置的 HTTPS 地址，记得先 Ctrl + s 保存修改后的 Markdown 文档再使用 Hexo 命令生成和部署。

这样相当于存在两个版本，一个是引用本地图片的离线版本可以用作存档，一个是引用 GitHub 图床的在线版部用来解析生成博客，实现存档和部署的文件相互分离，以后如果要迁移起来也方便。

优点：

• 不用改变以前使用 Typora 的习惯，只需要将想上传的 Markdown 拷贝到 _post 文件夹然后在 Typora 中一次性上传所有本地图片。
• 图床仓库和博客仓库隔离，图片不会挤占博客仓库空间。
• 本地版中的图片按篇组织在一个个文件夹，易于检查和整理。
• 可以配合 jsDelivr 实现免费的 CDN 加速，加快图片的加载速度，图片也不容易被墙。

缺点：

• 需要单独搭建配置图床。
• 本地离线版和在线版两个版本管理起来容易混乱，特别是后期有修改需要同步时。
• PicGo 用起来不是很稳定，但是目前也没有找到更好的替代工具。
• 两个版本多了一份重复文件，多占一丢丢几乎可忽略的硬盘空间。

很多人担心 GitHub 的仓库容量用来图床会不会够用，GitHub 官方关单个仓库容量的说法是：理想情况下小于 1 GB，强烈建议小于 5 GB。只是用来存储文章插图是够用的。

如果是打算上传各种高清大图，或者要上传音频甚至视频的，可以考虑七牛云的对象存储服务，上传身份证照片实名认证后有 10 GB 的免费空间，每月 10 GB 的免费流量。

注意：一定要备过案的域名能使用免费的 CND 加速，没备案的不能使用自定义域名加速。CND 加速效果相比 jsDelivr 并没有感觉到什么差距，可能和自己的网络环境有关。

至此完成了博客最基础的文章和图片展示功能的搭建，Hexo 还有更多高阶玩法，例如添加文章评论系统，嵌入音乐播放器，自定义主题模板等。建议把博客搭起来后，先把文章写起来，内容才是核心，花里胡哨可以等日后有空可以再慢慢折腾。

参考：

1. 吴润：GitHub+Hexo 搭建个人网站详细教程
2. 米淇淋：使用GitHub+jsDelivr+PicGo搭建免费快速图床