scratch-blocks 2.0：从 Blockly 分支到依赖库，Scratch 积木的架构转身
项目速览：Scratch Blocks 是一个用于构建创意计算界面的库。
秒懂
- 它是什么？
- 本文介绍 Scratch Foundation 的 scratch-blocks 库，重点分析 2.0 版本从 Blockly 分支改为依赖 Blockly 12 的架构变化，适合需要构建可视化编程界面的开发者评估是否采用。
- 适合谁用？
- scratch-blocks 适合那些需要与 Scratch VM 深度配合、构建类似 Scratch 的积木式编程界面的团队。它不适合只想在网页中嵌入一个通用积木编辑器的项目，因为其设计围绕 Scratch 的交互模式，且不提供代码生成器。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 4 天前。
- 用什么语言写的？
- 主要是 JavaScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，给谁用
scratch-blocks 解决的问题很具体：让开发者不用从零开始绘制积木块，就能搭建一个类似 Scratch 的可视化编程界面。它面向的是教育类应用、编程学习平台，以及任何想用拖拽积木来替代文本代码的团队。它不是给终端用户直接使用的产品，而是一个库，需要与 Scratch Virtual Machine（VM）配合才能运行。如果你只想在网页里嵌一个简单的积木编辑器，这个库可能过重；但如果你要的是 Scratch 那样的交互体验，它正是为此设计的。
2.0 的架构转向：从 fork 到依赖
2.0 版本最大的变化是架构关系。过去 scratch-blocks 是 Blockly 的一个分支，意味着它要自己维护一份 Blockly 的代码，升级困难。现在它改为依赖 Blockly 作为库，并将 Blockly 版本升级到 12。README 里明确说“no longer a fork of Blockly, but rather depends on Blockly as a library”。这个转变意味着，Blockly 的 bug 修复和改进可以直接通过依赖更新获得，而不是手动合并。但这也带来一个风险：scratch-blocks 的定制部分必须跟上 Blockly 的变化，如果上游 API 变动，它可能被迫调整。README 也承认“there will likely be a few bumps in the road”，说明他们自己也知道这个过渡期不会一帆风顺。
与 Scratch VM 的分工，为什么没有代码生成器
scratch-blocks 与 Blockly 的一个核心区别是它不使用代码生成器。Blockly 通常会把积木转换成 JavaScript、Python 等代码，但 scratch-blocks 不这样做。它依赖 Scratch VM 来执行积木的逻辑。这意味着积木块本身只是界面表示，真正的执行逻辑在 VM 里。这种设计适合 Scratch 这种即时反馈的环境，积木拖动后就能直接运行，而不需要先编译成代码。但代价是，如果你希望积木能生成文本代码，scratch-blocks 帮不上忙，你得自己实现。对于教育场景，这可能是优点，因为孩子不需要看到代码；但对于想同时输出代码的学习工具，这就是一个明显的局限。
开发与运行：真实的命令和配置
要开始使用 scratch-blocks，README 给出的步骤很直接。首先克隆仓库，然后运行 npm ci 安装依赖，再运行 npm run build 构建。测试方面，单元测试在 jsdom 中运行，不需要额外配置，直接 npm run test:unit 即可。浏览器测试需要 Chromium，通过 Playwright 驱动，先运行 npx playwright install chromium 安装浏览器，然后 npm run test:browser。如果你想调试失败的浏览器测试，可以用 npm run test:browser -- --browser.headless=false 打开可见窗口，或者用 PWDEBUG=1 npm run test:browser 在启动时暂停并打开开发者工具。这些命令都写在 README 里，没有隐藏的配置项。提交代码时，项目使用 semantic release 来自动管理版本号，要求提交信息遵循 conventional-changelog 规范，可以用 commitizen 来格式化提交。
维护与升级成本：semantic release 和 TypeScript
scratch-blocks 的维护成本主要体现在两个方面。一是依赖管理，它依赖 Blockly 12，这意味着每次 Blockly 更新，scratch-blocks 都需要验证兼容性。README 提到使用 semantic release 来确保版本号遵循 semver，这样依赖它的项目不会因为意外的大版本更新而崩溃。但这也要求提交信息必须规范，否则版本号可能错误。二是技术栈，项目用 TypeScript 和 webpack 构建，这比纯 JavaScript 有更高的学习门槛。如果你要修改 scratch-blocks 的源码，需要熟悉 TypeScript 的类型系统和 webpack 的配置。对于只想使用库的开发者，这些是间接成本，但如果你要贡献代码或深度定制，就得投入学习。
局限性与错误使用场景
scratch-blocks 的局限很明显。首先，它不提供代码生成器，所以如果你的应用需要把积木转换成文本代码，这个库不适合。其次，它依赖 Scratch VM，这意味着你必须同时引入两个库，并且要理解它们之间的接口。如果你只需要一个简单的积木编辑器，用 Blockly 本身可能更轻量。另外，2.0 版本刚发布，README 自己都说“会有一些颠簸”，所以生产环境使用需要谨慎。从仓库的活跃度看，最近几天连续发布 v2.1.17 到 v2.1.19，说明团队在快速修复问题，但这也暗示版本还不稳定。如果你对稳定性要求高，可能需要等一段时间。
替代方案：直接使用 Blockly 的区别
最直接的替代方案是使用 Blockly 本身，scratch-blocks 就是基于它的。区别在于，Blockly 是一个通用积木库，支持代码生成器，可以输出多种语言，而且不依赖任何特定的虚拟机。如果你不需要 Scratch 的视觉风格和交互方式，直接使用 Blockly 会更灵活。Blockly 有完善的文档和更大的社区，而 scratch-blocks 的文档主要在 wiki 上，相对分散。另一个区别是，Blockly 的更新由 Google 和 Raspberry Pi Foundation 维护，而 scratch-blocks 由 Scratch 团队维护，后者的更新节奏受 Scratch 项目需求驱动。所以，如果你的项目目标是通用编程教育，Blockly 可能是更稳妥的选择；但如果你要的是 Scratch 的体验，scratch-blocks 是唯一的选择，因为 Blockly 本身不提供 Scratch 的积木外观和交互。
编辑结论
scratch-blocks 适合那些需要与 Scratch VM 深度配合、构建类似 Scratch 的积木式编程界面的团队。它不适合只想在网页中嵌入一个通用积木编辑器的项目，因为其设计围绕 Scratch 的交互模式，且不提供代码生成器。如果你考虑采用，建议先验证 2.0 版本与 Blockly 12 的依赖是否稳定，检查你需要的自定义积木是否能在新架构下实现，并确认你的团队能接受 TypeScript 和 webpack 的构建流程。对于已有 Blockly 经验的团队，scratch-blocks 2.0 的架构变化可能降低迁移成本，但你需要评估其 API 与 Blockly 原生的差异。最终，scratch-blocks 的价值在于其与 Scratch VM 的紧密集成，而不是作为通用积木库。
社区笔记