Jekyll数据文件最佳实践：存于/data目录还是文章前置元数据中？

云上老周

2026-7-17

将数据嵌入Front Matter的弊端

虽然这种方式在中小型数据集场景下很方便，但它存在不少明显的局限性：

复用性极低：如果多篇文章需要使用同一份数据，你得在每篇文章的front matter里重复粘贴，完全没法像/data目录的独立文件那样一次定义、多处调用。后期修改数据时，要逐个更新所有包含该数据的文章，维护成本会随着数据复用次数直线上升。
内容与数据过度耦合：数据直接塞进front matter会让文章的元数据部分变得臃肿不堪，尤其是当数据有多层嵌套（比如复杂的项目大纲）时，front matter会占据文章开头大量篇幅，严重干扰文章内容的编辑和阅读体验，也很难快速区分「元配置」和「业务数据」。
数据处理能力受限：多数静态站点生成器对front matter的支持偏基础，无法像处理独立数据文件那样，单独对数据做预校验、过滤、转换等操作。所有数据处理逻辑都得硬塞进文章模板里，会让模板代码变得冗余复杂，后期难以维护。
版本追踪混乱：数据和文章内容混在同一个文件里，版本控制系统（如Git）无法单独追踪数据的变更历史。修改数据的提交和修改文章内容的提交会混在一起，排查问题时很难快速定位是数据变更还是内容变更导致的问题。
扩展性极差：一旦你的数据集需要扩容，或者要和其他数据源关联，嵌入front matter的方式几乎没有调整空间。你没法像/data目录那样按模块拆分数据文件，只能硬着头皮在front matter里继续堆砌，最后整个文件会变得难以管理。
编辑器支持不足：很多Markdown编辑器对复杂结构的front matter支持有限，嵌套层级深的数据可能显示错乱，甚至出现语法高亮失效的情况。编辑时也容易误触修改数据，不像独立数据文件有专门的语法校验和编辑优化。