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/