内容层检查#

先通读标题、开头和小结，确认文章真的回答了标题提出的问题。正文不能只堆命令，也不能只写感受，至少要交代场景、步骤和验证结果。

技术文章尤其要检查代码块是否闭合、命令是否能复制运行、变量名是否前后一致。

元数据检查#

frontmatter 里的 title、published、description、tags、category 会直接影响列表页、分类页和搜索索引。批量处理时最容易出现日期重复、分类写错、摘要空泛的问题。

1
title: "Nginx 404 与 403 排查"
2
published: 2026-06-23
3
description: "从站点根目录、权限、location 匹配和错误日志四个方向区分 404 与 403。"
4
tags: ["问题解决", "Nginx"]
5
category: "问题解决"
6
draft: false

构建和线上检查#

本地或服务器构建通过只能说明没有语法错误，还要确认页面能访问、搜索索引更新、文章列表数量正确。

• 首页是否展示新文章。

• 分类页计数是否变化。

• 新文章 URL 是否返回 200。

• 搜索接口或 Pagefind 索引是否重新生成。

什么时候必须加严检查#

批量新增、迁移旧文章、修改路由结构、替换主题组件时，都要比日常写一篇文章更严格。因为这类改动影响的不是单个页面，而是整个站点结构。

实战复盘#

我会用《博客发布前复查流程》建立一个可复用的维护标准：先说明为什么要做，再写具体检查项，最后给出发布后的确认方式。读者照着做时，不需要再猜下一步。

博客类文章最容易变成泛泛而谈，所以每篇都应该留下明确对象，例如 frontmatter、Pagefind、Nginx、Sitemap、分类卡片。对象越明确，文章越容易被搜索和复用。

如果以后发现文章只有原则没有操作，就应该补一个最小命令或检查清单。维护博客本身也是工程工作，要能验证、能回滚、能复盘。

最小验收样例#

验收《博客发布前复查流程》时，我会选一篇真实文章或一个真实页面作为样例，而不是只看源码。先确认页面能打开，再确认列表、分类、归档、搜索这些入口都能找到它。

如果文章讲的是站点维护，还要记录修改前后差异：改了哪个文件、构建产物是否更新、线上 HTTP 状态码是多少。这样后面出问题时，可以直接回到这次验收记录。

小结#

复查流程的价值在于固定顺序。只要每次都按内容、元数据、构建、线上四层走，很多问题会在发布前暴露。