Hexo+Qexo，让你的静态博客”动“起来
开始之前
在开始这篇教程之前，你需要：
- 一个GitHub账户（注册传送门）
- 一个Vercel账户（可用GitHub账户注册）
- Git
- Node.js 12.0+
- 合适的网络环境或者一个域名（能托管到Cloudflare的免费的二级域名也行），两者皆有最佳
新建站点
安装Hexo
打开终端，使用以下命令：
npm install -g hexo-cli在任意位置新建一个文件夹，命名为 blog-source-temp
进入 blog-source-temp文件夹，右击空白位置，选择在“终端中打开”（win10及以下点击上方地址栏输入 cmd）。这里已经创建了站点所以文件夹不是空的
输入命令
hexo init
npm install一个Hexo站点创建完毕，在终端输入 hexo s即可预览
建议在此时将站点配置全部完成（注意域名配置选项）
配置自定义域名（如无可忽略）
进入 blog-source-temp/source文件夹，新建一个名为 CNAME的文件（文件不要带后缀名）
用文本编辑器打开，写入你想配置的自定义域名
打开域名托管平台（此处以Cloudflare为例），新建以下A记录，名称应与CNAME一致：
185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153如图
创建博客仓库
打开GitHub，点击右上角加号 Create New -> New repository，创建一个名为 {你的Github用户名}.github.io的公开仓库
推送站点到仓库
在 blog-source-temp文件夹打开终端，输入命令安装一键部署插件
npm install hexo-deployer-git --save打开 _config.yml文件，在 Deployment块中写入以下内容：
deploy:
type: git
repo: git@github.com:{你的GitHub用户名}/{你的GitHub用户名}.github.io.git #如未配置ssh请使用https链接
branch: main在终端中输入命令 hexo d，提示部署成功后稍等片刻，访问 {你的GitHub用户名}.github.io或自定义域名即可看到站点
配置自动化构建
此处通过配置自动化构建来让GitHub从Hexo源文件构建出博客站点，是Qexo配置中重要的一环
在GitHub新建一个名为 blog-source的私密仓库
克隆远程仓库：
git clone git@github.com:{你的用户名}/blog-source.git将 blog-source-temp中的文件全部复制到 blog-source中
配置GitHub Actions
新建文件 blog-source/.github/workflows/autodeploy.yml,写入以下内容：
name: Blog CI/CD # 脚本 workflow 名称
on:
push:
branches: [main, master] # 当监测 main,master 的 push
paths: # 监测所有 source 目录下的文件变动，所有 yml,json 后缀文件的变动。
- '*.json'
- '**.yml'
- '**/source/**'
jobs:
blog: # 任务名称
timeout-minutes: 30 # 设置 30 分钟超时
runs-on: ubuntu-latest # 指定最新 ubuntu 系统
steps:
- uses: actions/checkout@v4 # 拉取仓库代码
- uses: actions/setup-node@v4 # 设置 node.js 环境
- name: Cache node_modules # 缓存 node_modules，提高编译速度，毕竟每月只有 2000 分钟。
uses: actions/cache@v4 # 亲测 Github 服务器编译速度比我自己电脑都快，如果每次构建按5分钟计算，我们每个月可以免费部署 400 次，Github yyds！！！
env:
cache-name: cache-node-modules
with:
path: ~/.npm
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-build-${{ env.cache-name }}-
${{ runner.os }}-build-
${{ runner.os }}-
- name: Init Node.js # 安装源代码所需插件
run: |
npm install
echo "init node successful"
- name: Install Hexo-cli And component # 安装 Hexo
run: |
npm install -g hexo-cli --save
# 在此处安装所需插件
echo "install hexo successful"
- name: Build Blog # 编译创建静态博客文件
run: |
hexo clean && hexo g
echo "build blog successful"
- name: Deploy Blog # 设置 git 信息并推送静态博客文件
run: |
cd ./public
git init
git config user.name "${{secrets.GIT_NAME}}"
git config user.email "${{secrets.GIT_EMAIL}}"
git add .
git commit -m "Update"
git push --force --quiet "https://${{secrets.GH_TOKEN}}@${{secrets.GH_REF}}" master:main
- run: echo "Deploy Successful!"
配置存储库Secrets
申请GitHub Tokens
打开https://github.com/settings/tokens，点击 Tokens(classic)，右上角 Generate new token(classic)，设置token名称、有效期，勾选 repo与 workflow权限
确定之后，记下token，后面要用
配置存储库Secrets
在 Github -> blog-source -> Settings -> Secrets and variables -> Actions -> Secrets中添加用于Github Action的Secrets
| 键 | 值 |
|---|---|
| GIT_NAME | GitHub用户名 |
| GIT_EMAIL | GitHub邮箱 |
| GH_TOKEN | 上一步申请的密钥 |
| GH_REF | github.com/{用户名}/{用户名}.github.io.git |
推送博客源码
git add .
git branch -M main
git commit -m "Initial commit"
git push -u origin main部署Qexo
注册Vercel
前往Vercel注册页面，选择Continue With GitHub
在Github授权页面完成授权
部署
点击下方按钮一键部署Qexo
首次部署会报错, 请无视并进行接下来的步骤
进入 Storage -> Create Database -> Neon (PostgreSQL)
请注意在地区选择的位置选择与你上一步项目对应的地区，一般是Washington, D.C., USA (East)
进入创建的数据库，点击 Connect to project，选择刚刚创建的Qexo项目
在边栏点击Deployments，再点击第一次失败的部署，点击 Redeploy
稍等片刻，点击Vercel分配的域名，即可进入Qexo初始化程序（需要特殊网络环境）
无论是分配的域名还是自定义域名都要保管好，防止被有心之人盗刷流量
配置自定义域名（如无忽略）
由于Vercel默认分配的域名在国内网络环境下无法访问，所以需要配置一个自定义域名
在边栏点击 Domains 添加自定义域名
Qexo新版本优化了安全措施, 需要在环境变量中正确配置 DOMAINS 变量，否则会报400 Bad Request错误
在边栏点击 Environment Variables ，再点击右上角 Add Environment Variables
键填入 DOMAINS ，值填入 ["{你配置的域名}"]
保存后右下角会提示重新部署项目，选择重新部署
等待任务完成后即可通过自定义域名访问Qexo
Qexo初始化配置
设置好用户名和密码，下一步
| GitHub密钥 | GitHub仓库 | 项目分支 |
|---|---|---|
| 之前申请的token | 用户名/blog-source | main |
下一步，跟随引导完成设置
至此，系统搭建完毕
完结撒花！！！
后记
每次在 Qexo 中编辑文件之后文章发表时间都会被刷新，因为 git 推送更新之后不会保留时间等元数据。
来自 Git SCM Wiki 的解释
Why isn’t Git preserving modification time on files?
Modification time on files is a feature that affects build tools. Most build tools compare the timestamp of the source(s) with the timestamp of the derived file(s). If the source is newer, then a rebuild takes place, otherwise nothing happens. This speeds up the build process a lot.
Now consider what would happen if you check out another branch, and modification times were preserved. We assume you already have a fully-built project. If a source file on that other branch has a timestamp that is older than that of the corresponding derived file, the derived file will not be built even if it is different, because the build system only compares modification times. At best, you’ll get some kind of weird secondary error; but most likely everything will look fine at first, but you will not get the same result as you would have with a clean build. That situation is unhealthy since you really do not know what code you are executing and the source of the problem is hard to find. You will end up always having to make a clean build when switching branches to make sure you are using the correct source. (Git bisect is another Git procedure that checks out old and new revisions where you need a reliable rebuild.)
Git sets the current time as the timestamp on every file it modifies, but only those. The other files are left untouched, which means build tools will be able to depend on modification time and rebuild properly. If build rules change, that can cause a failure anyway, but that is a far less common problem than accidentally not rebuilding.
参考这篇文章修复：修复 Vercel/Github Actions 部署 hexo 导致文章的更新时间错误 | Hello! I’m 0o酱
如果改为 Vercel 自动化部署则本文中博客源码仓库中配置的4个 Secrets 和 GitHub Actions 配置文件可以删除
参考文献：