关键是把业务代码和框架能力解耦：用CSS变量统一配置样式、封装适配层隔离框架实现、约定命名与作用域规则、渐进式替换升级。
直接改框架源码或强绑版本不是出路，关键是把业务代码和框架能力解耦。核心思路是：用配置代替硬编码，用抽象层隔离变化。
提取可配置的样式变量
把颜色、间距、圆角等基础值从组件内部抽到统一的 CSS 变量或主题配置文件里。比如不再写 padding: 16px，而是用 padding: var(--space-lg)。升级框架时，只需调整变量映射，不用逐个改组件。
- 用
:root定义全局变量，配合媒体查询做响应式变量切换 - 主题切换场景下，通过 class 切换（如
theme-dark）重载变量值 - 避免在 JS 里内联样式写死数值，所有尺寸/颜色走 CSS 变量桥接
封装轻量级适配层组件
不直接使用框架的 Button、Card 等原生组件，而是封装一层自己的 MyButton，只暴露业务需要的 props，并把框架内部实现当成“黑盒”。这样框架升级时，只要保证 MyButton 的接口不变，业务代码完全无感。
- 适配层只做属性透传 + 样式桥接，不加业务逻辑
- 用
React.forwardRef和...rest保持原生行为一致 - 为不同框架版本维护多个适配器（如
AntdV5Adapter），运行时按需加载
约定 CSS 命名与作用域规则
禁用框架自带的 utility class（如 Tailwind 的 mt-4、Ant Design 的 ant-btn-primary）直接写在 JSX 中。统一走 BEM 或 CSS Modules，让样式归属清晰、可追溯。
立即学习“前端免费学习笔记（深入）”；
- 组件样式文件命名与组件同名，用
module.css隔离作用域 - 业务定制样式写在独立的
overrides.css，不 patch 框架源码 - 用 PostCSS 插件自动检测并警告非法使用的框架 utility class
渐进式替换而非全量升级
把框架升级拆成小步：先锁定依赖版本，再逐步将老组件迁移到新适配层；新功能一律用新封装组件开发。过程中保留双框架共存能力（如用微前端或动态 import 加载不同版本 UI 库）。
- 用
package.json的resolutions锁定子依赖，防意外升级破坏 - 写脚本扫描项目中对框架私有 API 的调用（如
Modal.destroyAll()），提前识别风险点 - 为关键组件补 E2E 快照测试，升级后比对渲染结果是否一致
不复杂但容易忽略：升级成本高，往往不是框架本身难，而是业务代码和它缠得太紧。松一松耦合，配置好边界，升级就从“停业整顿”变成“后台静默更新”。
