引言
大家好啊，我是前端拿破轮。
你是否也曾想过拥有一个自己的专属网站？但是却苦于服务器，域名，部署等等繁琐的流程和配置？
今天就教大家怎么不用服务器，不用域名也能搭建自己专属的个人网站！
说明：本教程面向对象为有一定基础的开发者，所以对于环境配置，github登录等基础流程不再过多介绍。
话不多说，我们直接开始，在流程中再解释相关的内容。
环境版本如下
node: 24.13.0
pnpm: 10.28.1
安装 Hexo
我这里使用的是 pnpm 作为包管理器。
bash
# 全局安装 hexo-cli
pnpm add hexo-cli -g初始化项目
初始化项目使用hexo init <你的github用户名>.github.io命令
比如我的 github 用户名是 majialu-love-zouyutong 那么，在初始化的时候文件夹必须 命名为majialu-love-zouyutong.github.io。
bash
# 初始化项目文件夹
hexo init majialu-love-zouyutong.github.io
# 进入目录并用 vscode 打开
cd majialu-love-zouyutong.github.io/
code .目录结构如下图所示： 
接着初始化 git 仓库并将代码推到 github 上。
bash
# 初始化 git 仓库
git init
# 添加到暂存区
git add .
# 提交
git commit -m 'feat: 初始化'推送仓库到 github
如果使用 github 登录了 vscode，在源代码这一栏可以很方便的一键推送到 github，不用手动创建仓库和设置远程分支。
注意，这里一定要发布为public仓库，否则无法访问个人网站
安装依赖并本地运行网站
bash
# 安装依赖
pnpm i
# 本地运行网站
pnpm run server
我们可以看到这里报了一个错误，意思是说在我们安装的依赖strip-ansi@7.1.2中，在ES Module中使用了require()。require是CJS的语法，所以报错了。
关于
ESM和CJS的区别，可以看往期文章的详细介绍：CJS和ESM两种模块化标准的异同分析
这里我们使用在package.json中配置pnpm的overrides的方法来将strip-ansi的主版本号降至6。
json
// package.json
{
其他配置项目,
"pnpm": {
"overrides": {
"strip-ansi": "^6"
}
}
}修改后的package.json如下：
json
{
"name": "hexo-site",
"version": "0.0.0",
"private": true,
"scripts": {
"build": "hexo generate",
"clean": "hexo clean",
"deploy": "hexo deploy",
"server": "hexo server"
},
"hexo": {
"version": "8.1.1"
},
"dependencies": {
"hexo": "^8.0.0",
"hexo-generator-archive": "^2.0.0",
"hexo-generator-category": "^2.0.0",
"hexo-generator-index": "^4.0.0",
"hexo-generator-tag": "^2.0.0",
"hexo-renderer-ejs": "^2.0.0",
"hexo-renderer-marked": "^7.0.0",
"hexo-renderer-stylus": "^3.0.1",
"hexo-server": "^3.0.0",
"hexo-theme-landscape": "^1.0.0"
},
"packageManager": "pnpm@10.28.1",
"engines": {
"node": "24.13.0",
"pnpm": "10.28.1"
},
"pnpm": {
"overrides": {
"strip-ansi": "^6"
}
}
}然后重新安装依赖再重新运行
bash
# 重新安装依赖
pnpm i
# 重新启动服务
pnpm run server
然后我们打开http://localhost:4000/即可访问页面。
看起来有点丑，但是不重要，我们后续可以使用主题进行美化。
配置 CI/CD
在.github/workflows文件夹下创建page.yml文件，写入以下内容
yaml
# GitHub Pages 自动化部署工作流
# 该工作流在 master 分支有新的 push 时自动触发，构建项目并部署到 GitHub Pages
# 工作流名称，会在 GitHub Actions 界面显示
name: Pages
# 工作流触发条件
on:
push:
branches:
- master # 仅在 master 分支有 push 时触发此工作流
# 定义工作流中的所有任务
jobs:
# 构建任务：编译项目并生成静态文件
build:
# 指定运行环境为最新的 Ubuntu 系统
runs-on: ubuntu-latest
# 定义此任务中的所有步骤
steps:
# 步骤 1: 检出代码仓库
- uses: actions/checkout@v4
with:
# 使用 GitHub 提供的默认 token 进行身份验证
token: ${{ secrets.GITHUB_TOKEN }}
# 递归检出所有子模块（如果项目包含 git submodule）
# 参考: https://github.com/actions/checkout
submodules: recursive
# 步骤 2: 设置 Node.js 运行环境
- name: Use Node.js 24.13.0
uses: actions/setup-node@v4
with:
# 指定 Node.js 版本为 24.13.0
# 支持的版本格式: 20, 18.19, >=16.20.2, lts/Iron, lts/Hydrogen, *, latest, current, node
# 详细说明: https://github.com/actions/setup-node#supported-version-syntax
node-version: '24.13.0'
# 步骤 3: 设置 pnpm 包管理器
- name: Setup pnpm
uses: pnpm/action-setup@v4
with:
# 指定 pnpm 版本为 10.28.1
version: 10.28.1
# 步骤 4: 获取 pnpm 存储目录路径
- name: Get pnpm store directory
# 执行命令获取 pnpm 的本地存储路径，并将其保存到环境变量 STORE_PATH 中
run: echo "STORE_PATH=$(pnpm store path)" >> $GITHUB_ENV
# 步骤 5: 缓存 pnpm 依赖包
- name: Cache pnpm store
uses: actions/cache@v4
with:
# 缓存的目录路径（pnpm 的包存储位置）
path: ${{ env.STORE_PATH }}
# 缓存的唯一标识符，基于操作系统和 pnpm-lock.yaml 文件的哈希值
# 这样可以在依赖未变化时复用缓存，加快构建速度
key: ${{ runner.os }}-pnpm-${{ hashFiles('pnpm-lock.yaml') }}
# 步骤 6: 安装项目依赖
- name: Install Dependencies
# 使用 pnpm 安装 package.json 中定义的所有依赖包
run: pnpm install
# 步骤 7: 构建项目
- name: Build
# 执行 package.json 中定义的 build 脚本，生成静态文件到 public 目录
run: pnpm run build
# 步骤 8: 上传构建产物到 GitHub Pages
- name: Upload Pages artifact
uses: actions/upload-pages-artifact@v3
with:
# 指定要上传的目录路径（构建后的静态文件所在目录）
path: ./public
# 部署任务：将构建好的文件部署到 GitHub Pages
deploy:
# 此任务依赖于 build 任务，只有 build 任务成功完成后才会执行
needs: build
# 定义此任务所需的权限
permissions:
# 允许写入 GitHub Pages 配置
pages: write
# 允许生成和使用 OIDC token（用于身份验证）
id-token: write
# 定义部署环境信息
environment:
# 环境名称为 github-pages（GitHub 会自动识别并配置）
name: github-pages
# 部署完成后的访问 URL，从部署步骤的输出中获取
url: ${{ steps.deployment.outputs.page_url }}
# 指定运行环境为最新的 Ubuntu 系统
runs-on: ubuntu-latest
# 定义此任务中的所有步骤
steps:
# 步骤 1: 部署到 GitHub Pages
- name: Deploy to GitHub Pages
# 为此步骤设置 ID，以便后续步骤可以引用其输出
id: deployment
# 使用 GitHub 官方的部署 action，将之前上传的产物部署到 GitHub Pages
uses: actions/deploy-pages@v4这样当我们在master分支push代码时，就可以触发Github的流水线，自动将更新后的网站部署到Github Pages。
尝试进行一次推送，进入仓库的Actions，发现workflow已经正在运行了。 
workflow运行成功后，我们就可以直接访问已经部署的页面了。
https://你的github账户名.github.io
这里以笔者的页面为例
使用主题
通过上面的操作，我们已经可以在每次推送更新的master时实现自动构建和部署，但是目前的样式太丑了，有没有什么方式可以进行美化呢？
答案是肯定的，我们可以在hexo主题市场中任意选择自己喜欢的主题。
每一个主题都有相应的预览网站可以查看。
我们这里以安之鱼主题为例进行说明，其他主题方法类似。
sh
# 博客项目根目录中执行
# 安装主题
pnpm add hexo-theme-anzhiyu
# 安装pug和stylus的渲染器
pnpm add hexo-renderer-pug hexo-renderer-stylus
# 本地启动项目
pnpm run server修改根目录中的_config.yml文件，将其中的theme字段改成znzhiyu。
项目在本地启动后就可以访问啦
将变更推送到Github仓库执行流水线，即可自动部署。
总结
本文详细记录了如何用hexo + Github Pages搭建一个自己的个人网站，并利用anzhiyu主题进行了美化，同时通过Github Actions设置了CI/CD流程，实现代码推送后自动部署。
好了，这篇文章就到这里啦，如果对您有所帮助，欢迎点赞,收藏,分享👍👍👍。您的认可是我更新的最大动力。由于笔者水平有限，难免有疏漏不足之处，欢迎各位大佬评论区指正。
往期推荐✨✨✨
我是前端拿破轮，我们下期见！