搭静态博客时，我先拿三篇笔记试做。一篇有照片，一篇带长代码，还有一篇需要被旧链接找到。它们能帮我判断文章怎么归类、图片应该放在哪里，以及换主题之后哪些地址还必须有效。这篇文章记录了从整理原稿到检查生成结果的过程。
先决定网站要留下什么
桌上的原稿有三类。一份是整理过的技术笔记，另一份是只记到一半的读书摘录，还有几张散步时拍的照片。它们都能放进同一个文件夹，却没有必要全都发布。读书摘录只有在补上出处和自己的疑问之后，别人才能读懂。技术笔记则需要说明问题在哪种条件下出现，否则读者很容易把一条临时处理办法当成通用规则。
我选择静态站，是因为这个博客的主要动作是阅读。几个人同时打开同一篇文章，服务器可以把已经生成的页面直接交给他们。编辑、排版和生成发生在发布之前，正文也能保留在本地。代价是修改后要重新生成和上传。如果网站主要用来协作编辑或处理表单，仍要另外考虑负责这些工作的服务。
让归档和分类回答不同的问题
我会先给文章挑一个能说明它写什么的分类，再决定有没有值得跨文章追踪的线索。以一篇记录图片丢失的笔记为例，它归在技术笔记，标签可以是静态网站。另一篇散步随笔即便也有照片，除非它真的谈拍摄或选图，否则没必要把技术文和散步文都打成摄影。
分类决定从哪里开始逛
打开分类页的人通常还不知道要读哪一篇。分类名称应当让他能猜到里面有什么。我曾考虑把技术笔记细分成路径、依赖、发布和排版，但四个名字下各只有一篇。先放在一个分类里，等同类问题累积到读者需要细找时，再看拆分是否值得。
标签用来跨分类串读
标签适合留下那些会反复出现的题目。「阅读」可以同时出现在排版手记与读书随笔里。归档则给读者一个按时间翻看的入口，旧文即使迁到另一个分类，仍能从原来的年份找到。发布前我会从这三个入口各找一次文章，确认它们提供了不同的线索。
| 从哪里找 | 读者可能在找什么 | 用本文做一次检查 |
|---|---|---|
| 分类 | 想读同类文章 | 能从技术笔记进入 |
| 标签 | 想沿一个话题往下读 | 能接着看静态站的路径排查 |
| 归档 | 记得大致发布时间 | 能在对应的年份里找到 |
跟着一篇文章走到输出目录
在已有的 Hexo 项目中，我从 source/_posts/field-notes.md 开始。文件头里的标题面向读者，文件名便于我自己查找。这里采用 posts/:title/ 的永久链接规则，生成后仍要核对实际路由。老站的规则如果把年份、月份写进地址，改发布日期之前也应先看旧链接是否会受影响。
1 |
|
这段 Front Matter 提供文章的元数据。正文经过 Markdown 渲染器成为 HTML 片段，生成器为文章、列表和归档安排路由，主题把片段与导航、日期、目录放进页面。遇到问题时，先判断哪一层出了错。文章只在归档找不到，检查生成结果和日期。标题能打开但正文格式异常，再看 Markdown 源稿和渲染结果。
图里另画了一条资源路径。图片本身不需要经过 Markdown 渲染器。文章输出的只是图片引用，浏览器在打开页面后才去请求文件。这两条路只有在最终地址匹配时才会接上。
为图片选一种清楚的组织方式
在这个小站里，我把可公开的图片放在 source/images/，有文章专属的一组照片时再考虑按文章分文件夹。源文件名只用小写英文字母和连字符。尺寸和用途不同的图可以分开命名，例如封面与正文细节图。改版时可以迅速找到哪些图是首页在用，哪些图只在文章中出现。
先在生成的 HTML 中找实际地址
如果页面位于 /posts/field-notes/，普通的相对地址 images/river.jpg 会从文章所在目录解析。以斜杠开头的 /images/river.jpg 则从域名根目录解析。站点如果发布到 /journal/，同样的根相对地址可能直接跳出子目录。此时要检查 Hexo 的 url、root，并确认使用的资源写法经过当前渲染器处理后确实带上站点前缀。Hexo 资源目录说明
我会在生成的文件里找 src，再到本地预览里看浏览器请求。如果地址正确仍找不到文件，就对照输出目录检查拼写和大小写。带空格或全角标点的旧文件尤其值得核对，改文件名时也应搜索是否还有第二篇文章在引用它。
给照片保留必要的上下文
原始照片留在备份里，站点只放适合屏幕阅读的版本。裁切前先确认画面里的关键信息在哪里。要是照片用来解释一处入口的方向，裁掉门边的路牌就会让它失去用途。替代文字可以写出正文没有交代的观察，比如台阶与护栏的位置。授权和摄影署名放在图注或素材记录中，日后移动图片时一并带过去。
用实际读法检查排版
我会把文章放到窄屏上，从头读到第一张图。读到一半离开，过一会儿再回来，看看能否从标题和邻近段落找回位置。目录里只出现「一些细节」或「其他」，通常说明这一节还可以再说清楚。子标题最好能直接回答读者下一步要找什么。
我的回读问题是：如果只看目录，我知道该去哪里找图片路径吗？
让代码和解释挨在一起
示例命令上方要说清它在哪个目录执行、会写出什么。正文可以先用一句话说明检查目标，代码块里只放能运行的命令。终端返回的结果另起一段解释，以免读者把提示符或输出也一起复制。较长的命令尽量按可理解的步骤拆开。路径本身必须很长时，保留完整值，让读者能够对照自己看到的请求地址。
一张图与一个例子放在同一节内，最好先说明读者要找哪一部分。比如上面的流程图里，上行是内容的处理顺序，下行是资源复制。读者看不到图时，也可以靠这两句说明理解为什么文章打开了，图片却还可能报错。
发布前，先做一次能重来的生成
在已安装依赖的站点根目录，我会用下面的命令生成并预览。生成与发布是两次独立操作，输出留在 public/，本地服务器可以用来确认实际访问路径。Hexo 命令参考
1 | npx hexo generate |
- 从首页打开刚写完的文章，再从分类和归档各走一遍。
- 打开以前分享过的一条链接，确认文章地址仍然有效。
- 请求正文中的图片，检查它的实际地址与替代文字。
- 在打包前查看生成目录，只把准备公开的文件交给托管服务。
用另一份配置模拟部署路径
本地首页用的是域名根目录，正式站却可能托管在一个项目子目录。我会为这种情况另存一份预览配置，把站点前缀设成真实路径，并指定一个独立的输出目录。这样可以对照两次生成结果，也能避免后一次测试覆盖平时看的文件。配置里的域名可以是示例地址，但路径层级应与最终部署一致。
检查时，我先从首页点到文章，再从文章里的链接走到第二篇。接着从浏览器地址栏直接打开同一个深层链接。如果只有从首页点进去才正常，先检查托管端是否能把目录地址映射到其中的 index.html。如果页面能打开，但样式或图片丢了，找出一条失败请求，比较它的路径与生成目录的相对位置。
对已经公开的站点，我还会保留几条实际有人用过的旧链接。比如一篇被订阅器收录的文章、一张曾在讨论里引用的图片，以及归档中较早的一页。只打开最新文章，很容易漏过改版后才出现的旧路径问题。若要设置重定向，在本地能确认的是新旧路径的对应关系，真正的跳转仍要到所用的托管环境里验证。
这几项检查可以写成一张短清单，留在项目旁边。下次如果只改了一处文字，通常看文章和生成结果就够了。改到站点前缀、目录结构或主题的链接处理时，再把整条路径走一遍。
把下次能用到的东西一起留下
备份先保留 Markdown、素材、站点配置和锁文件，以及记录主题来源和版本的说明。生成目录可以重建，但已经公开过的 URL 值得留一份清单。站点换过域名或目录结构时，它能帮助决定哪些页面需要配置重定向。
升级之前可以先用备份副本生成一次，记录几个常用入口和图片地址。然后升级，再生成并逐项比较。若同时换主题、改链接规则和整理分类，出问题很难判断从哪里开始查。拆成几次独立修改，每次只留下必要的记录，几个月后重新打开项目也能接着做。
我会在完成一次更新后记下最容易忘的一件事。有时只是「服务器区分图片文件名大小写」，有时是「旧文章的地址含日期」。这些说明放在站点自己的维护笔记里。等下一篇稿子写好，生成、检查和发布仍然是同一条能走回来的路。