Ember.js 官方于 2026 年 5 月 29 日正式发布 7.0 版本。作为 Ember 连续第 7 个大版本,7.0 并没有带来大量的新 API,而是遵循 Ember 一贯的升级哲学——只有在充分稳定之后才会引入重大变更。本质上,7.0 的全部工作就是移除在 6.x 周期中标记为废弃的那些功能。

升级路径:从 6.12 开始
对于正在使用 Ember 6.x 的开发者,官方推荐的升级路径是先升级到 6.12——该版本已被指定为新的长期支持(LTS)版本。然后解决所有来自废弃警告(deprecation warnings)的问题,最后运行 npx ember-cli-update --to 7.0 完成迁移。这个升级路径设计得很清晰:6.12 作为 LTS 提供了稳定的过渡地带,让项目可以在不受新版本发布压力的情况下从容完成升级。
整个 6.x 周期的核心改进
7.0 移除的是废弃功能,真正的能力增长实际上来自 6.x 周期积累的大量改进。
最值得关注的架构变化发生在 6.8 版本:Embroider 和基于 Vite 的构建系统成为了默认选项。这两者的结合为 Ember 带来了真正意义上的现代前端构建体验。Vite 的即时热更新和快速冷启动解决了长期以来 Ember 应用在开发体验上的痛点,而 Embroider 则提供了更高效的打包输出。
同期,默认启用的还有严格模式的模板标签组件编写方式,以及一系列新的 tracked 集合类型——trackedArray、trackedObject、trackedMap、trackedSet 等,为响应式数据管理提供了更现代化的 API。
此外,renderComponent API 的引入允许独立渲染单个组件,而 glimmer-vm 和 router.js 仓库合并到 ember.js 主仓库的决策,也进一步简化了维护和版本管理。
被移除的废弃功能
7.0 移除了三个主要废弃项:全局 import Ember from 'ember' 的导入方式不再支持;AMD bundle 的发布方式被移除;以及从 @ember/service 导入 inject 的写法被废弃。这些都是经过多个版本缓冲的变更,对于仍在使用的项目有明确的迁移指引。
Ember CLI 7.0 的定位
值得注意的是,Ember CLI 7.0 同样没有引入新的公开 API 或功能,其唯一职责就是清理废弃代码。这种「减法」哲学贯穿整个发布周期——功能的引入和验证放在次版本,等到稳定后才在大版本中清理废弃入口。
对于长期关注 Ember 的开发者而言,这种节奏并不陌生。Ember 团队向来倾向于过度谨慎而非过度激进,一个功能从提出到默认启用往往需要跨越多个版本。这使得 Ember 在前端框架快速迭代的竞争中显得有些「慢」,但也让它成为追求稳定性和长期可维护性的团队的首选。
参考来源:https://blog.emberjs.com/ember-released-7-0/