先找退出结果#

真正失败通常会出现 error、failed、非零退出码，或者构建流程没有走到生成页面的阶段。只看到 warning 不一定需要回滚，但要知道它影响什么。

如果构建命令结束后没有生成新的 dist，就不能上线。

看页面数量#

Astro 构建会输出生成了多少页面。大规模新增文章后，页面数量应该明显增加。如果文章源文件增加了，但页面数量没变，要检查 draft、frontmatter 或内容集合配置。

Pagefind 日志里的 indexed pages 也很重要，它说明有多少页面进入搜索索引。

常用排查命令#

1
tail -n 80 /tmp/blog-build.log
2
grep -i "error\|failed\|warning" /tmp/blog-build.log
3
du -sh dist
4
find dist -name '*.html' | wc -l

警告怎么判断#

有些警告是可接受的，例如某些非文章页面没有正文可被 Pagefind 索引；有些警告则需要处理，例如 Markdown frontmatter 解析失败、图片路径不存在、组件属性错误。

判断标准很简单：它是否影响页面生成、内容展示、搜索索引或线上访问。

实战复盘#

复盘《博客构建日志怎么看》时，我会把它当成一个站点维护动作，而不是单篇文章。凡是影响首页、分类、RSS、Sitemap、搜索索引或旧链接的改动，都要在发布后做一次线上验证。

如果只在源码里看起来正确，但线上接口或页面没有变化，就说明构建或发布链路还有问题。博客维护类内容必须把“怎么确认已经生效”写清楚。

以后继续扩展这类文章时，可以补充真实命令输出、截图前后的差异，以及回滚路径。这样文章会更接近操作手册，而不是零散备忘。

最小验收样例#

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

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

小结#

构建日志要按顺序读：退出状态、页面数量、搜索索引、关键警告。只看最后一行，很容易漏掉内容层面的异常。