Hexo 的好处是写作和发布之间隔得很近：文章是 Markdown，预览是本地网页，发布是一次静态生成。但“很近”不等于“没有步骤”。如果一开始就把文件、命令和预览方式固定下来，后面写十篇、几十篇文章都不会变得混乱。

从命令创建文章

在项目根目录打开终端，使用 Hexo CLI 创建新文章：

npx hexo new "my-first-post"

命令会把文件放到 source/_posts/，文件名通常会根据标题生成。实际维护时，我更喜欢直接使用稳定的英文 slug，例如：

npx hexo new "hexo-local-writing-preview"

创建之后先打开 Markdown 文件，补齐 title、date、tags、categories 和 description。文件名决定 URL 的一部分，越早把 slug 定下来，后面改链接的成本越低。

如果你已经确定文章标题，也可以先用 slug 建文件，再把中文标题写入 front matter。标题负责给读者看，文件名负责给 URL 和仓库维护者看，两者不必完全相同。

本地预览的标准入口

写作时使用仓库已有的 server 脚本：

npm run server

Hexo 会启动本地服务，终端会显示访问地址。编辑 Markdown 后，浏览器通常会自动刷新；如果页面没有变化，先保存文件，再回到终端确认服务进程还在。

只想预览已经发布的文章时，保持 draft: false。需要检查草稿样式时，可以显式让 Hexo 在本地显示草稿：

npx hexo server --draft

草稿预览只影响本地服务，不代表它会被正式生成。当前项目的 render_drafts 配置是 false，正式构建默认不会把 draft: true 的文章放进公开页面。写完并完成复核后，再把 draft 改为 false。

日期、未来文章和预览差异

当前项目打开了 future: true，因此带未来日期的文章也会进入生成结果。这适合提前排版或安排发布顺序，但也意味着日期要认真填写。若文章不该立即出现，使用 draft: true 比随意修改日期更直观。

我通常把“写作状态”和“发布时间”分开考虑：

  • 还在整理的内容用 draft: true；
  • 已经准备发布的内容用 draft: false；
  • date 表示文章在站点上的时间；
  • updated 表示最近一次重要修改。

这样做比在正文里写“暂时不要看”更可靠，因为状态由生成器处理。

端口冲突和临时预览

如果默认端口被其他程序占用，可以给 Hexo 指定一个临时端口：

npx hexo server --port 4001

端口改变只影响本地访问地址，不会改变文章 URL。停止服务时回到运行 Hexo 的终端按 Ctrl+C 即可；不要为了释放端口去结束一组不确定的系统进程。

如果页面看起来像旧版本，先执行一次清理和生成：

npx hexo clean
npx hexo generate

日常写作不必每次都 clean，但排查缓存、主题渲染或资源路径问题时，这一步能帮助区分“源文件没更新”和“生成物没刷新”。

写作时保持小步验证

我会按照“改一小段—刷新预览—确认结构”的节奏写，而不是写完几千字后才第一次打开页面。标题层级、列表、代码块和站内链接越早发现问题，修改越便宜。

准备提交前，再运行仓库统一检查：

pwsh ./ops/check.ps1

它会检查文章 front matter 的必填字段。检查脚本不能判断观点是否准确，却能避免文章因为少一个 description 而在发布阶段返工。

小结

Hexo 本地写作的核心不是记住很多命令，而是把常用入口固定下来：用 npx hexo new 创建文件，用 npm run server 预览，用 draft 控制未完成内容，用 clean 和 generate 排查旧产物，最后用 check 做发布前护栏。

如果你正在整理文章元数据，可以继续看Hexo Front Matter 详解；如果文章已经开始包含图片和互链，再看资源与站内链接的组织方法。