published 表示公开发布时间#

published 应该代表文章对外发布或整理完成的日期，而不是每次编辑的时间。后续修错别字、补一段代码，不需要频繁修改这个字段。

如果文章是迁移旧内容，原则上保留旧文章创建时间；如果是新补写的教程，可以选择今天之前合理分布的日期。

日期格式要稳定#

我建议统一使用 YYYY-MM-DD，不要混用 2026/05/02、中文日期或带时区的完整时间。静态站生成时，格式越统一，排序和解析越稳定。

1
published: 2026-05-02
2
draft: false
3
category: "博客相关分类"

批量新增时的检查#

• 日期是否都早于今天，避免未来文章意外提前展示。

• 同一批文章日期是否尽量不重复。

• 分类页排序是否符合预期。

• RSS 中是否出现大量同一天的机械更新。

修改日期前先想清楚#

日期不是任意美化字段。改旧文章日期会改变归档历史，也可能影响搜索引擎对内容新旧的判断。除非文章被完全重写，否则我一般不改旧日期。

实战复盘#

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

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

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

最小验收样例#

验收《Frontmatter 日期字段使用规则》时，我会选一篇真实文章或一个真实页面作为样例，而不是只看源码。先确认页面能打开，再确认列表、分类、归档、搜索这些入口都能找到它。

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

小结#

frontmatter 的日期字段要当成内容元数据来维护。它不只是排序依据，也是博客长期可信度的一部分。