博客1.2版本（多线路访问）

这篇文章整理一下本站现在的写作和发布方式。它既是一篇面向读者的技术说明，也是一份公开的维护记录：内容如何从 Obsidian 进入博客，页面如何发布到 GitHub Pages，为什么还会准备独立服务器线路和 EdgeOne 加速入口。

为什么要做多线路访问

这个博客本质上是一套静态网站。静态博客的好处是简单、稳定、容易备份；问题是不同网络环境下，访问 GitHub Pages、境外服务器或国内加速线路的体验可能不一样。

所以本站现在提供一个访问选择页：

1

https://blog.orixx.xyz/

这个页面不是另一套内容，而是同一份博客的入口导航。读者可以按自己的网络环境选择更顺畅的线路：

• 稳定访问：由独立服务器提供，作为日常推荐入口。
• 大陆优化线路：通过腾讯云 EdgeOne 做访问加速。
• 备用镜像：GitHub Pages 上的公开镜像。

这样做的目标很朴素：文章只维护一份，但访问方式可以更灵活。

写作入口：Obsidian

文章最初写在 Obsidian 里。它适合做长期笔记，也适合写 Markdown，所以博客草稿和正式文章都放在同一个写作环境中维护。

当前约定是：

1
2
3

Blog/Posts   # 博客文章
Blog/Assets  # 博客素材
Blog/Trash   # 删除文章时的回收目录

每篇文章使用 Hexo 兼容的 front matter，例如：

1
2
3
4
5
6
7
8
9
10

---
title: 示例文章
date: 2026-06-19 12:00:00
tags:
  - 博客网站
categories:
  - docs
cover: /images/theme/default-cover.webp
draft: false
---

其中 draft: true 表示私有草稿，不会同步到博客源码目录；改成 draft: false 后才会进入发布流程。

本地图形化工具

为了减少重复命令，仓库里放了一个本地 GUI：

1

npm run blog

它用 Python + Qt 写成。启动脚本会自动寻找可用的 Qt 环境，例如 PySide6、PyQt6 或 PyQt5。当前机器使用的是 Anaconda 环境里的 PyQt。

GUI 主要做几件事：

• 新建草稿。
• 把 Obsidian 文章同步到 Hexo。
• 执行本地构建检查。
• 设置本地封面或图床封面。
• 删除文章并同步下线。
• 推送源码分支，让 GitHub Actions 自动部署。

如果不打开 GUI，也可以用命令行完成同样的流程：

1
2
3

npm run blog:sync
npm run blog:build
npm run blog:publish

其中 blog:publish 不直接上传所有站点，它只推送博客源码分支。真正的线上部署由 GitHub Actions 统一处理。

图片和封面

文章封面可以使用站内图片，也可以使用外部图床链接：

1
2

cover: /images/posts/example.webp
cover: https://example.com/example.webp

如果不想为每篇文章单独维护封面，可以保留默认值：

1

cover: /images/theme/default-cover.webp

GUI 里有两个辅助按钮：

• 选择封面：选择本地图片，自动复制到博客图片目录。
• 封面 URL：把图床链接写入最近修改的文章。

如果图片已经在 Obsidian 中直接写成 URL，也可以保持原样。同步脚本会保留这种写法。

从源码到线上页面

这个博客仓库使用 source 分支维护源码。文章、图片、脚本、主题配置都在这个分支里。推送后，GitHub Actions 会运行：

1

.github/workflows/deploy.yml

发布流程大致是：

1. 安装 Node.js 和 npm 依赖。
2. 执行 Hexo 构建。
3. 把 GitHub Pages 版本发布到 main 分支。
4. 使用独立配置再构建一份适合 /blog/ 路径的版本。
5. 通过 SSH 同步到独立服务器目录。

这样，本地电脑不需要分别登录每个发布平台；只要源码进入 GitHub，后续部署就由自动化流程接管。

GitHub Pages

GitHub Pages 是本站的公开镜像之一：

1

https://ori2333.github.io/

它的优点是稳定、透明、和源码仓库绑定紧密。GitHub Actions 会把 Hexo 生成的静态文件发布到 main 分支，因此 source 分支负责维护源码，main 分支负责承载静态页面。

独立服务器线路

除了 GitHub Pages，本站还部署了一份服务器托管版本：

1

https://blog.orixx.xyz/blog/

入口页则是：

1

https://blog.orixx.xyz/

服务器部署脚本在：

1

tools/hk_deploy/

几个关键文件分别负责：

• deploy_hk.py：构建服务器版本、生成访问选择页、打包并上传。
• _config.hk.yml：覆盖 Hexo 的 url、root 和 public_dir。
• hk_deploy.config.json：保存域名、远程目录和入口链接配置。
• nginx-ori2333-blog.conf：Nginx 配置模板。
• setup_hk_server.py：初始化服务器站点配置和 HTTPS。

服务器上的目录固定为：

1

/var/www/ori2333-blog

部署脚本只同步这个目录，不会接管服务器上的其他服务。旧的 /hk/ 路径会跳转到 /blog/，用于兼容早期测试阶段的地址。

HTTPS 使用 Let’s Encrypt。证书有效期为 90 天，需要服务器保持自动续签任务开启。

EdgeOne 加速线路

为了改善中国大陆网络访问体验，本站还准备了腾讯云 EdgeOne 入口。它不是另一套博客，也不是另一份文章源，而是一条访问加速线路。

日常写作不需要为 EdgeOne 单独做任何操作。文章发布后，GitHub Pages 和服务器版本先更新；EdgeOne 再按照它的源站和缓存策略提供加速访问。

如果某次访问发现 EdgeOne 内容延迟，通常优先检查：

• GitHub Actions 是否部署成功。
• 加速线路的源站是否可访问。
• 是否命中了旧缓存。
• 当前访问 URL 是否带着过期参数。

仓库结构

仓库里最常用的目录是这些：

1
2
3
4
5
6
7
8

source/_posts/                   # Hexo 文章源文件
source/images/posts/             # 文章配图
source/images/theme/             # 主题图片、头像、背景、默认封面
tools/blog/                      # 本地 GUI 和同步工具
tools/hk_deploy/                 # 独立服务器部署工具
templates/blog-post.md           # 新文章模板
docs/blog-workflow-migration.md  # 换电脑和环境迁移说明
.github/workflows/deploy.yml     # 自动部署流程

public/ 是 Hexo 构建产物，不需要手动维护，也不应该作为主要修改对象。真正值得维护的是文章、图片、配置和脚本。

删除和下线

删除文章时，最好不要只在一个目录里删文件。GUI 的 删除文章 会同时处理 Obsidian 和 Hexo 源文件：

• 原文移动到 Blog/Trash。
• source/_posts 中的同名文章被删除。
• 构建和发布流程会让线上页面同步下线。

这可以避免“本地删掉了，线上还看得到”的情况。

换电脑时需要恢复什么

如果以后换电脑，重点是恢复写作和发布环境：

1. 安装 Node.js，并在仓库里运行 npm ci。
2. 准备一个带 Qt 的 Python 环境。
3. 配置 Obsidian 库路径。
4. 确认可以推送 GitHub 的 source 分支。
5. 如果需要本地手动部署服务器版本，再恢复 SSH key。

可以先用这条命令检查 GUI 环境：

1

npm run blog:check

它会同时检查 Python/Qt、Git、Node.js、npm、Hexo 依赖、Obsidian 路径和 Git 状态。换电脑后如果缺少 Git 或 Node.js，报告里会给出对应的处理建议。

服务器自动部署所需的密钥放在 GitHub Actions Secrets 中，不写进仓库。相关名称包括：

1
2
3
4
5

HK_HOST
HK_PORT
HK_USER
HK_REMOTE_ROOT
HK_SSH_KEY

这套流程的取舍

这套系统的重点不是追求复杂，而是把容易出错的部分拆开：

• Obsidian 负责写作体验。
• GUI 负责减少重复操作。
• Hexo 负责生成静态页面。
• GitHub Actions 负责自动部署。
• 独立服务器和 EdgeOne 负责改善访问体验。

从读者视角看，只需要选择一条顺畅的访问线路；从维护视角看，只需要维护一份文章源。这个边界清楚以后，后续更换域名、迁移服务器或调整加速线路，都不会影响写作本身。