Build Awesome (Eleventy) v4：一个更简单的静态站点生成器，以及它为什么值得再看一眼

它要解决什么问题，以及为谁而做

Build Awesome 的定位很直接：一个更简单的静态站点生成器，是 Jekyll 的替代品。Jekyll 用 Ruby，模板语言以 Liquid 为主，而 Build Awesome 用 JavaScript，允许你在 HTML、Markdown、JavaScript、Liquid、Nunjucks 之间自由混用，还通过插件支持 WebC、Sass、Vue、Svelte、TypeScript、JSX。它的目标用户是那些不想被框架绑死、希望直接控制模板输出的人。与 Jekyll 相比，它把语言栈从 Ruby 换成 Node.js，这让前端工程师更容易定制构建流程。它不试图成为内容管理系统，它只是把目录里的模板变成 HTML，这个简单承诺是它的核心。

机制：目录到 HTML 的转换过程

根据 README 的描述，Build Awesome 的核心动作是“将目录中的模板（各种类型）转换为 HTML”。它没有像 Next.js 那样的服务器组件或客户端路由，它是纯静态输出。模板类型由文件扩展名决定，比如 .md 走 Markdown 解析，.liquid 走 Liquid 引擎，.njk 走 Nunjucks。JavaScript 模板文件可以导出数据或函数，这使得你可以在构建时生成页面列表或读取外部数据。插件系统是扩展的入口，官方文档专门有一页讲插件。这种设计意味着数据流是单向的：源文件经过模板引擎和插件处理，最终落成 HTML 文件。没有运行时，没有服务端逻辑，这既是它的简单之处，也是它的限制。

安装与上手：两条命令和文档入口

安装命令在 README 里写得很清楚：npm install @awesome.me/buildawesome --save-dev，或者为了向后兼容，用 npm install @11ty/eleventy --save-dev。后者意味着 v4 仍然保留旧的包名，这对已有 Eleventy 项目的迁移很重要。官方文档入口是 https://www.11ty.dev/docs/，其中 Getting Started 指南是推荐的起点。测试命令是 npm test，仓库里有多套测试套件，包括 ava、Node.js 自带测试运行器，以及基于 Vitest 的浏览器测试。这些测试分布在 test/、test_node/ 和 packages/browser/test/ 目录。对于普通用户，你不需要跑这些测试，但了解它们的结构有助于判断项目的维护严谨度。

版本状态：alpha 阶段的现实

仓库的最近发布是 v4.0.0-alpha.9 和 v4.0.0-alpha.10，时间都在 2026 年 7 月 1 日，相隔不到四小时。这意味着 v4 仍处于 alpha 阶段，API 可能变动。README 没有提到任何稳定的 v3 版本，但“向后兼容”的安装方式暗示 v3 用户可以通过 @11ty/eleventy 包名继续使用。alpha 版本不适合生产环境，除非你愿意承担破坏性变更的风险。另一个信号是仓库的默认分支是 main，但 README 里引用的覆盖率文档路径是 master/docs/coverage.md，这可能是文档与代码分支不同步，也可能是历史遗留。总之，如果你要用于正式项目，先锁定版本号，并留意 alpha 阶段的更新日志。

测试与质量保障：多套测试套件的意义

Build Awesome 的测试策略比一般静态站点生成器更复杂。它同时使用 ava 作为主测试框架，Node.js 自带 test runner 作为次要套件，还有 Vitest 的浏览器模式测试。这种多测试框架并存的做法并不常见，通常团队会选一个。这里可能是为了覆盖不同层面的行为：ava 处理核心逻辑，Node test runner 可能用于快速单元测试，浏览器测试则验证在真实浏览器环境中的表现。另外还有一个独立的 benchmark 仓库（11ty/buildbenchmark）用于性能回归检测。这说明项目对性能退化有意识，但 README 没有给出任何基准数字，所以实际性能表现无法从材料中确认。

限制与错误使用场景

Build Awesome 的简单性也带来限制。它没有内置的增量构建或热更新，至少 README 没有提到，这意味着大型站点的构建时间可能成为瓶颈。它也不提供主题系统，Jekyll 有丰富的主题市场，而这里你需要自己组合模板和插件。如果你只想快速搭一个博客，不想折腾模板引擎选择，Build Awesome 可能不是最省事的选择。另一个问题是插件生态的成熟度，README 列出了许多插件，但 v4 alpha 阶段这些插件是否全部兼容还不确定。如果你的项目需要动态路由、表单处理或服务端渲染，这个工具根本不适合，它只输出静态 HTML。

替代方案：Jekyll 与 Hugo 的对比

最直接的替代是 Jekyll，Build Awesome 本身就是它的替代品。Jekyll 用 Ruby，模板语言以 Liquid 为主，安装需要 Ruby 环境，而 Build Awesome 用 Node.js，这决定了生态差异。另一个常见选择是 Hugo，它用 Go 编写，以速度著称，但模板语言是 Go 模板，学习曲线不同。Hugo 内置了分类、短代码和主题系统，开箱即用程度高于 Build Awesome。如果你需要极快的构建速度，Hugo 可能更合适；如果你想要 JavaScript 生态的灵活性，Build Awesome 更贴近。材料中没有提到 Hugo，但这是静态站点生成器领域常见的对比对象，基于项目定位可以合理推断。

维护成本与许可证

许可证是 MIT，这意味着你可以自由使用、修改和分发，只要保留版权声明。维护成本方面，由于 v4 还在 alpha，你需要定期关注发布节奏，比如 2026 年 7 月一天内发布了两个 alpha 版本，说明迭代很快。升级时要注意向后兼容的承诺，README 特意提到 @11ty/eleventy 包名仍然可用，这降低了迁移成本。但插件兼容性需要自己验证，因为插件作者可能跟不上主版本更新。文档站是独立的，更新频率未知。总体而言，这个项目的维护活跃度看起来不错，但 alpha 阶段的稳定性需要你自行评估。

编辑结论

Build Awesome 适合已经熟悉 Eleventy 的开发者，尤其是那些喜欢用 JavaScript 控制构建流程、需要从 Markdown 到组件框架多种模板混用的人。它不适合追求零配置的纯内容站点，因为模板引擎的选择、插件配置和数据文件约定都需要你主动学习。初次使用前，先确认你的 Node.js 版本满足 v4 的要求，然后跑一遍官方 Getting Started 指南，用 npm install @11ty/eleventy 安装以保持向后兼容。最后，检查你要用的插件是否已经适配 v4，因为 alpha 阶段的插件生态可能滞后。如果你接受这些前提，它会是一个比 Jekyll 更贴近 JavaScript 生态的选择；如果你想要开箱即用的博客系统，Hugo 或 Jekyll 仍然更省心。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes