Babel 降级 Class 继承导致体积膨胀、冗余逻辑和 polyfill 注入，引发加载延迟与内存上升；应精准配置 targets、启用 transform-runtime、禁用 legacy 装饰器及废弃 polyfill，并通过 REPL 和 Coverage 验证优化效果。
Class 继承被 Babel 降级后性能劣化，通常不是执行时的“慢”，而是体积膨胀 + 冗余逻辑 + 非必要 polyfill 注入引发的加载延迟、解析开销与内存占用上升。极端情况下（如数百个类、深度继承链、老旧构建配置），可能造成首屏 JS 增大 20–40 KB、TBT（总阻塞时间）显著升高。核心矛盾在于：Babel 默认把每个 class A extends B 都展开为一整套寄生组合式继承代码，并重复注入辅助函数——这不是语义错误，而是工程冗余。
关闭无意义的继承转译
现代浏览器早已原生支持 class 和 extends。只要目标环境明确（如 Chrome ≥ 80、Safari ≥ 14、Edge ≥ 88），Babel 就不该降级继承语法本身。
- 在
babel.config.js中精准配置targets，不写模糊的"last 2 versions"或"ie >= 11" - 确认
@babel/preset-env的loose: false（默认值），避免因宽松模式引入额外兼容逻辑 - 若项目已弃用 IE，直接移除
core-js全局垫片注入，防止其触发 Babel 对语法结构的“过度保护”
用 transform-runtime 替代内联辅助函数
Babel 默认把 _inherits、_classCallCheck、_createSuper 等函数复制进每个模块，导致相同逻辑反复打包。启用 @babel/plugin-transform-runtime 可让它们统一从 @babel/runtime 导入，实现真正复用。
- 安装依赖：
npm install --save-dev @babel/plugin-transform-runtime和npm install --save @babel/runtime - 配置插件时设
{"corejs": false}（继承逻辑不依赖 core-js；仅需垫片时再开corejs: 3） - 确保未同时启用
@babel/preset-env的useBuiltIns，二者会冲突并导致辅助函数重复注入
剥离装饰器与提案语法的副作用
某些 Babel 插件（如 @babel/plugin-proposal-decorators 或旧版 @babel/plugin-proposal-class-properties）在开启 legacy: true 模式时，会强制将 class 重写为函数表达式，并绕过标准继承转译路径，反而激活更重的运行时逻辑。
- 检查
.babelrc或配置中是否误启了legacy decorators；如非必需，改用阶段 3 标准模式（{"version": "2023-03"}） - 禁用
@babel/plugin-proposal-class-properties的loose: true，它会导致this.x = y被转成构造函数内赋值，破坏 super() 时机控制，间接迫使 Babel 插入更多校验逻辑 - 移除已废弃的
babel-polyfill或全局import '@babel/polyfill'，它们会污染全局并干扰 Babel 的环境判断
验证与定位真实瓶颈
不要凭直觉优化。先确认问题是否真出在继承降级上：
- 用 Babel 官网 REPL 或本地
babel --out-file out.js src/MyClass.js查看单文件输出，搜索_inherits出现次数及位置 - 对比开启/关闭
transform-runtime后的产物体积（推荐size-limit或source-map-explorer） - 在 Chrome DevTools 的 Coverage 面板中加载页面，观察继承相关辅助函数是否被实际执行（很多只是打包进去但从未调用）
- 若使用 Webpack，开启
stats: { builtAt: true, reasons: true }查看哪些模块拉入了重复的 runtime 辅助代码
