悠悠楠杉
网站页面
跨越框架边界：Preact与React在同一项目中的协同实践
07/13
框架混编的现实需求
去年接手某电商平台中台系统重构时，我们面临一个棘手的局面：历史代码库中存在大量React组件（v16.8），而新功能开发希望采用Preact（v10.5）来提升性能。经过三个月的技术验证，我们成功实现了两种框架的和平共处，这套方案至今稳定运行。
技术选型的悖论往往在于：React庞大的生态系统与Preact的极致性能就像鱼与熊掌。但在实际项目中，通过构建工具的巧妙配置，完全可以做到兼得。我们的解决方案核心是Webpack的alias配置：
javascript
resolve: {
alias: {
"react": "preact/compat",
"react-dom": "preact/compat",
// 保留特定模块继续使用原始React
"@legacy/react-components": "react"
}
}
渐进式迁移策略
混合架构最怕出现"薛定谔的依赖"——你永远不知道某个组件会调用哪个框架。我们制定的版本控制铁律包括：
- 新组件强制使用Preact编写
- 旧组件逐步迁移时保持React原样
- 共享状态管理必须通过跨框架方案（如Custom Events）
特别是在处理Hooks时，我们发现Preact的useState与React存在微妙的差异。例如在事件批处理方面，Preact默认不批量更新，这导致我们的表单验证逻辑出现了不一致。解决方案是引入Preact的options模块进行统一配置：
javascript
import { options } from 'preact';
options.debounceRendering = requestAnimationFrame;
样式方案的兼容之道
CSS-in-JS库的选择成为另一个挑战。 Emotion虽然同时支持两个框架，但在SSR场景下会出现className不一致的问题。我们最终采用双编译策略：
bash
对Preact组件
preact build --css-modules
对React组件
react-scripts build --css-in-js
通过PostCSS的命名空间转换，确保各自生成的类名不会冲突。这个方案增加了约15%的构建时间，但彻底解决了样式污染问题。
性能对比实测数据
在混合架构下，我们进行了3轮性能基准测试（使用Lighthouse 9.6）：
| 指标 | 纯React | 混合架构 | 提升幅度 |
|---------------|--------|----------|---------|
| TTI | 4.2s | 3.1s | 26%↑ |
| Bundle Size | 187KB | 142KB | 24%↓ |
| Memory Usage | 86MB | 72MB | 16%↓ |
有趣的是，当Preact组件超过60%时，再优化收益会急剧下降。我们的最佳实践是保持Preact在40-70%的比例区间。
调试技巧与血泪教训
跨框架调试就像在两种方言间做同声传译。我们总结出几个关键点：
- DevTools扩展必须同时安装React和Preact版本
- 错误边界组件必须使用对应框架的版本
- 性能分析时要区分框架调用栈
曾经因为一个Modal组件同时混用两种框架的Portal实现，导致内存泄漏。最终通过高阶组件封装解决了这个问题：
jsx
const FrameworkPortal = ({ children }) => {
return IS_PREACT ? (
<PreactPortal>{children}</PreactPortal>
) : (
ReactDOM.createPortal(children, document.body)
);
}
未来架构的演化方向
随着项目的演进，我们发现这种混合模式反而带来了意想不到的灵活性。现在我们可以：
- 在性能关键路径使用Preact
- 在复杂状态场景使用React+Recoil
- 通过Web Components封装框架无关组件
这种架构的终极优势在于：当某个框架出现重大更新时（比如React 19发布），我们可以分模块渐进升级，而不必全盘推翻重来。
结语
框架的边界不应成为技术决策的枷锁。通过合理的架构设计，Preact与React的联姻不仅能带来性能提升，更创造了技术演进的缓冲空间。在追求极致效率的时代，这种务实主义的方案或许更值得考虑。
