这篇文章记录本博客当前的使用方式,包含:如何写文章、改文章、删文章、改主题配置、替换各位置图片、预览与部署。
1. 项目结构速览
当前核心目录:
source/_posts/:文章 Markdown 文件source/about/index.md:关于页面_config.yml:站点级配置(标题、URL、root、主题名等)_config.kratos-rebirth.yml:Kratos-Rebirth 主题配置public/:Hexo 生成后的静态文件(不要手改)
2. 脚本与命令
在仓库根目录运行:
1 | npm run clean |
说明:
clean:清空旧构建产物build:生成静态站点到public/server:本地预览,默认访问http://localhost:4000/deploy:按_config.yml的 deploy 配置发布(仅执行 Hexo deploy)push:static:一键执行clean + build + deploy(推静态站到部署仓库)push:执行source:push(推源码到主仓库,触发 GitHub Actions 部署)source:status:查看源码仓库改动状态source:push:将源码仓库改动执行add + commit + push
如果 4000 端口被占用:
1 | npm run server -- -p 4001 |
如果要查看当前项目脚本定义,可直接看 package.json 的 scripts 字段。
注意区分两类“推送”:
npm run push:推送的是源码仓库改动(用于触发 GitHub Actions 自动部署)。npm run push:static:推送的是静态站内容(public-> 部署仓库)。
结论(当前项目推荐):
- 你现在主要用
npm run push就可以。 npm run push:static不是日常必需,只有在你临时改走 Hexo 部署仓库时才用。
3. 如何写一篇新文章
3.1 创建文章
1 | npx hexo new post "你的文章标题" |
会在 source/_posts/ 里生成同名 .md 文件。
3.2 推荐 Front Matter 模板
1 |
|
标签与分类建议这样使用:
tags:可多个,用于主题聚合、跨分类检索。categories:建议单个主分类,保持结构稳定。
示例(技术文章):
1 | tags: |
生成后可在以下页面查看效果:
/tags//categories//tags/标签名//categories/分类名/
封面建议统一放在 source/images/posts/,并在文章里写成:
1 | cover: /images/posts/your-post-cover.webp |
注意:这里不要写站点根路径之外的前缀,当前站点已经部署在根域名下,资源路径应直接写成 /images/...。
3.3 控制首页摘要预览
在正文中加入:
1 | <!-- more --> |
这行之前是首页摘要,这行之后只在文章详情页显示。
4. 如何修改与删除文章
4.1 修改文章
直接编辑对应的 source/_posts/*.md 文件,然后执行:
1 | npm run build |
4.2 删除文章
删除 source/_posts/对应文章.md,再执行:
1 | npm run build |
5. 如何替换各种位置的图片
建议把你自己的图片放到 source/images/(或 source/assets/)下。
示例:
source/images/avatar.webpsource/images/banner-light.webpsource/images/banner-dark.webpsource/images/bg-light.webpsource/images/bg-dark.webpsource/images/post-cover.webp
这样 Hexo 生成后会变成:
/images/avatar.webp/images/banner-light.webp- …
5.1 侧栏头像
在 _config.kratos-rebirth.yml:
1 | image: |
5.2 顶部横幅 Banner
在 _config.kratos-rebirth.yml:
1 | image: |
5.3 全局背景图
在 _config.kratos-rebirth.yml:
1 | image: |
5.4 文章封面
在文章 front matter:
1 | cover: /images/posts/post-cover.webp |
建议每篇文章用独立封面文件名,例如:
source/images/posts/2026-03-29-hexo-cover.webpsource/images/posts/isp-bilinear-cover.webp
5.5 站点图标 Favicon
在 _config.kratos-rebirth.yml:
1 | image: |
当前图标文件位置:source/images/theme/favicon.svg。
如果你要换图标,直接替换该文件,或改成你自己的路径(例如 source/images/theme/my-favicon.png 并同步修改上面的配置)。
6. 常见问题
6.1 首页显示全文,不是摘要
原因:没有 <!-- more -->。
处理:在正文合适位置加入 <!-- more -->。
6.2 首页卡片图片裂开
原因:cover 路径不存在或不可访问。
处理:确认文件放在 source/images/,并检查路径拼写。
6.3 头像裂开
原因:路径与站点 root 不一致(本项目现在是 /)。
处理:头像路径使用可访问地址,并在本地预览验证。
6.4 审查时临时关闭评论
本项目支持通过一个开关临时关闭评论(用于审查/内测)。
在 _config.kratos-rebirth.yml 里找到:
1 | additional_injections: |
将 window.__COMMENTS_ENABLED 改为:
true:开启评论false:关闭评论(页面显示“评论已关闭(审查中)”提示)
关闭时会同时隐藏评论计数,避免出现“0 条评论”的占位文案。
6.5 文章页有阅读量,但首页列表不显示
原因:
- 当前项目采用纯静态阅读量方案(不依赖 Waline 服务),统计脚本只针对当前页面生效。
- 首页列表是一页里多篇文章卡片,纯静态方案无法稳定返回每篇文章各自的独立阅读量。
处理:
- 在
_config.kratos-rebirth.yml中保持visit_count.enable_at只启用post。 visit_count.template使用不蒜子脚本与busuanzi_container_page_pv模板。
说明:
- 阅读量统计可以独立于评论开关运行;即使评论关闭(
__COMMENTS_ENABLED=false),文章页阅读量仍可显示。 - 如果你以后想在首页列表也显示“每篇文章阅读量”,需要接入带后端存储的计数服务(如 Waline pageview)。
7. 发布流程
7.1 日常推荐流程(最简单,适合 90% 场景)
编辑完文章或配置后,直接在命令行执行:
1 | git add -A |
或用仓库脚本一键推送:
1 | npm run push |
就这样! GitHub Actions 会自动 build + deploy 到 GitHub Pages。
补充:
npm run push本身不做构建,构建发生在 CI(GitHub Actions)里- 推送时会自动排除
public/、db.json、.deploy_git/ - 等待 2-5 分钟,网站会自动更新
7.2 本地完整预览(发布前验证)
如果想在本地看到最终效果再推送:
1 | npm run clean # 清理旧构建 |
检查无误后再执行 npm run push 推送。
7.3 备用流程:本地直接部署(不常用)
如果你临时不想用 GitHub Actions,可以在本地直接构建并推送到 main 分支:
1 | npm run push:static # 等价于:clean + build + deploy |
这个流程需要:
- 本地配置好 SSH
_config.yml的 deploy 配置指向正确的仓库
日常不推荐用这个。
7.4 双托管(GitHub Pages + 腾讯云)说明
如果同时保留腾讯云静态托管:
- GitHub Pages 由
source -> (CI build) -> main自动发布 - 腾讯云由独立的 CloudBase workflow 或控制台配置负责
- 两边都会自动同步更新
腾讯云控制台配置要点:
- 分支:选
source(需要源码) - 目标目录:
.(仓库根) - 安装命令:
npm install - 构建命令:
npm run build - 构建产物目录:
public - 部署路径:
blog或根据实际需求(不要填/)
注意:当前 Hexo 配置是 root: /(根域名),如果腾讯云部署到 /blog/ 子路径,会出现样式加载失败。两边要保持一致:
- 都用根路径
/,或 - 都用子路径
/blog/(需要改 Hexo 配置)
9. Obsidian + 菜单式日常流程
现在仓库里加了一套更省心的日常入口:
tools/blog/blog.config.json:配置 Obsidian vault、文章目录和图片目录templates/blog-post.md:新文章模板tools/blog/blog_gui.py:图形化日常面板tools/blog/blog_cli.py:命令行入口,方便自动化和 Codex 调用npm run blog:启动图形界面
推荐流程:
- 在 Obsidian 的
Blog/Posts里写文章 - 图片放到
Blog/Assets - 准备发布时,把文章 front matter 里的
draft: true改成draft: false或删除这一行 - 运行
npm run blog - 在图形界面里点
Sync或All - 需要预览就选
Preview - 需要发布就选
Publish
首次使用时,可以先选 Import,把仓库现有文章和图片导入到 Obsidian。
如果你要调整同步位置,只需要改 tools/blog/blog.config.json。
迁移到新电脑或切换 Python 环境时,查看仓库里的 docs/blog-workflow-migration.md。
8. 🎉 新部署架构说明(2026 年 4 月更新)
本仓库已进行重大架构升级,采用业界标准的”源码与产物分离“策略。这彻底解决了之前混合托管带来的问题。
这部分就是原来独立的部署说明内容,现已并入本文,方便你只维护一篇文档。
主要改进
问题回顾
- ❌ 源码、配置、依赖混杂在同一分支
- ❌
node_modules被上传,仓库臃肿 - ❌ 安全隐患:配置文件和密钥暴露
- ❌ GitHub Pages 可能解析混淆
新方案
- ✅
source分支:存放源代码、文章、配置 - ✅
main分支:仅存放编译后的静态 HTML - ✅ CI 自动化:GitHub Actions 自动构建和部署
- ✅ 安全隔离:敏感信息不再进入 GitHub Pages
安全边界:会不会有密钥泄漏风险
如果你基本没有后端交互,风险通常很低,但不是绝对为零。关键看你有没有把真正的 Secret 放进仓库。
- 通常没问题的内容:文章正文、图片、CSS、JS、主题配置里只用于前端展示的公开站点 ID 或地址。
- 仍然要避免的内容:真正的 API Secret、Token、数据库密码、云存储私钥、可写权限密钥。
对于你现在这种纯静态博客,如果只是做展示、评论和统计,而且没有自建后端,那么大多数情况下不会产生“服务器密钥泄漏”问题。真正需要警惕的是以后如果接入了第三方后端能力,别把私钥直接写进 _config.yml、_config.kratos-rebirth.yml 或文章内容里。
新工作流(强烈推荐)
你只需关心一件事:编辑 source 分支并推送。
1 | # 1. 在 source 分支编辑(默认分支) |
分支说明
| 分支 | 用途 | 由谁维护 |
|---|---|---|
source |
日常编辑分支 | 你(编辑所有源文件) |
main |
GitHub Pages 分支 | 自动(CI 生成) |
常见场景
场景 1:发布新文章
1 | # source 分支上 |
场景 2:修改配置或主题
1 | # 修改配置 |
关键脚本命令
1 | npm run build # 生成 public/(本地用) |
跟进行动
如果这是你第一次看到这个新架构:
切到 source 分支(应该已经是默认)
1
2git checkout source
git branch -v # 验证 * source阅读详细文档
直接看本文第 7、8 节即可,相关部署说明已经合并到这里。验证 CI 工作流
进入 GitHub 仓库 > Actions 标签页,查看最新的工作流执行结果有任何疑问
- 查看 Hexo 官方文档:https://hexo.io/docs/
- 查看 GitHub Actions 文档:https://docs.github.com/en/actions
总结:现在你的博客采用了专业的 CI/CD 部署流程。编辑 → 推送 source → 自动部署。简单、安全、规范。