关键是把业务代码和框架能力解耦：用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 快照测试，升级后比对渲染结果是否一致

不复杂但容易忽略：升级成本高，往往不是框架本身难，而是业务代码和它缠得太紧。松一松耦合，配置好边界，升级就从“停业整顿”变成“后台静默更新”。