把一款依赖Ember.js多年、业务逻辑盘根错节的前端系统迁移到React，本质上是在不停止业务的前提下完成心脏置换。Ember.js早期凭借强约定、自带构建工具和完整的MVC结构，帮助企业快速搭建了内部管理系统与SaaS界面；但如今组件化、 hooks 与函数式状态管理成为主流，团队往往面临招人困难、生态停滞与构建缓慢等现实问题。本文从架构对照、增量迁移与数据层桥接三个角度，说明如何让老牌框架平稳过渡到React。
架构层面的核心差异与映射关系
Ember.js的应用组织围绕路由、控制器、组件与服务展开，框架在背后自动注入依赖，开发者很少手动组装模块。例如在一个典型的Ember应用中，Route负责数据预取，Controller管理派生状态，模板通过{{}}绑定自动更新。这种结构在React中并没有一一对应的内置概念，React本身只是一个视图库，路由、状态、数据获取都需要自行选择方案。因此在迁移前，必须先列出旧系统中每个Ember概念在React生态里的承接方式，否则很容易在重写时丢失业务约束。
最直观的映射是：Ember的Route对应React Router的loader或useEffect中的数据请求；Ember的Component对应函数组件；Ember的Service对应用Context或外部状态库（如Zustand）创建的共享实例。但要注意，Ember的模板语法允许在HTML中直接调用助手函数，而React要求所有逻辑写在JavaScript里。下面是一段Ember模板与React组件的逻辑对照示例：
// Ember模板片段（旧）
// <h2>{{this.user.name}}</h2>
// <button {{on "click" this.logout}}>退出</button>
// React等价实现（新）
function UserPanel({ user, onLogout }) {
return (
<div>
<h2>{user.name}</h2>
<button onClick={onLogout}>退出</button>
</div>
);
}
这种映射不是简单翻译，而是要重新审视原本隐藏在Ember约定里的副作用。例如Ember的computed属性在React中应使用useMemo显式声明依赖，否则会出现不必要的重渲染。理解差异后，团队才能制定不破坏业务的切分边界。
采用外壳包裹的增量迁移策略
一次性重写整个Ember应用风险极高，因为老系统往往有数百个路由与大量自定义助手。更可行的方案是在同一页面中让React作为外层容器，Ember继续渲染特定挂载点。具体做法是在Ember的application.hbs中保留一个空的div，React通过createRoot挂载到该节点，并利用全局事件总线同步路由变化。这样新功能用React写，旧模块暂时不动，用户毫无感知。
实现上可以引入一个轻量的桥接模块，把Ember的owner.lookup服务暴露到window对象，React侧通过封装函数读取。当某个Ember路由完成迁移后，再从路由表中移除对应Ember定义，改为React Router接管。下面的代码展示了桥接层如何把Ember服务传给React：
// bridge.js 桥接脚本
export function getEmberService(name) {
const app = window.__APP__;
return app && app.lookup && app.lookup(`service:${name}`);
}
// React组件内使用
import { getEmberService } from './bridge';
function Settings() {
const session = getEmberService('session');
const isAuthed = session && session.isAuthenticated;
return <p>登录状态：{String(isAuthed)}</p>;
}
这种增量方式最大的好处是业务不中断，并且可以按模块验证兼容性。团队能够把迁移节奏交给产品迭代排期，而不是被迫停下需求做长达数月的重构。同时，由于Ember与React共存，老代码的测试套件仍可运行，新代码逐步补充React Testing Library用例，整体质量反而更可控。
数据层与状态管理的平滑过渡
Ember Data作为内置的ORM层，深度耦合了模型的序列化与关系处理。直接丢弃会导致大量接口契约重写。推荐做法是保留Ember Data的适配器与序列化器，在React侧用一层异步包装把它转成标准Promise，再交给React Query管理缓存。这样接口的字段映射逻辑不动，React组件只关心数据视图，不必理解Ember的存储机制。
当超过一半界面迁移到React后，可以开始用fetch或axios配合代码生成器，把Ember Data的模型定义转成TypeScript接口，并逐步替换包装层。以下示例展示适配层如何暴露Ember Data给React Query：
import { useQuery } from 'react-query';
import { getEmberService } from './bridge';
async function loadPosts() {
const store = getEmberService('store');
const result = await store.findAll('post');
return result.map((item: any) => item.serialize());
}
export function usePosts() {
return useQuery('posts', loadPosts);
}
状态管理方面，Ember的Service单例可以先用Zustand或Redux Toolkit重建，初期通过桥接读取Ember值，后期切断依赖。需要特别留意的是，Ember的脏检查机制与React的不可变更新不同，迁移时务必把原有可变数组操作改为返回新引用，否则界面不会刷新。经过数据层桥接与状态重建，老牌Ember.js应用便能在数个月内完成React现代化，且全程无需停机。