React新JSX运行时反而导致打包体积增大？如何排查与优化？

输出形式差异的产生原因 #

你观察到的「模块对象.方法」形式的JSX调用，确实和Webpack的模块处理逻辑直接相关，本质是和官方示例的编译链路差异导致的：

• 开发环境看到的带Webpack模块标记的长名输出，是Webpack未做模块压缩、作用域提升时的原始导入逻辑：Webpack默认会把整个被导入的ES Module作为命名空间对象挂载在当前模块作用域下，因此调用模块导出的方法时，必须通过「命名空间对象.方法名」的形式访问，也就是你看到的react_jsx_dev_runtime__WEBPACK_IMPORTED_MODULE_4__.jsxDEV写法。
• 生产环境看到的(0,a.jsx)("div",{})，是代码压缩工具做了变量重命名、间接调用语法优化后的简写形式——前面的逗号表达式是为了避免成员函数调用时错误绑定this到模块对象a，属于压缩器的标准处理；本质上还是保留了「导入模块对象、取对象上的jsx方法」的逻辑，和官方示例中把_jsx作为独立顶层函数调用的形式存在差异。官方示例是Babel编译后的原始输出，默认会从JSX运行时模块直接命名导入单个jsx方法，编译后可以直接以独立函数引用的形式调用，不需要走对象属性访问的链路。

可通过配置优化输出形式的调整方向 #

这类输出形式带来的冗余，完全可以通过调整Webpack和Babel配置消除，进一步压缩体积：

• 开启Webpack的模块作用域提升（optimization.concatenateModules）：生产环境该配置默认开启，如果手动关闭会导致所有模块以独立作用域的形式打包，强制保留完整的模块对象引用。开启后Webpack会基于ES Module的静态导入做代码提升，把jsx、jsxs这类单个导出的方法直接提升到当前模块的顶层作用域，去掉不必要的对象嵌套访问逻辑。
• 避免对JSX运行时模块做CommonJS转译：如果Babel配置开启了@babel/plugin-transform-modules-commonjs，会把原生ES Module的导入转成CommonJS格式的对象属性访问写法，直接触发你看到的调用形式。需要确保生产构建时，Babel保留对react/jsx-runtime、react/jsx-dev-runtime的原生ES Module导入格式，让Webpack可以正确做静态分析和代码优化。
• 确保代码压缩工具开启基础变量优化：比如Terser压缩器需要开启reduce_vars、unused等优化选项，自动消除冗余的模块对象引用，把成员访问调用替换为直接的函数引用。

接入新JSX运行时后体积反增的常见诱因 #

除了上述的输出形式差异，还有几类高频踩坑点会直接导致打包体积上涨：

• 新旧JSX转换逻辑共存：如果Babel配置没有完全切换到自动运行时模式，同时保留了经典JSX转换（自动注入React.createElement的逻辑）和新运行时转换，会导致所有JSX编译产物同时附带两套兼容代码，凭空增加冗余体积。需要确认Babel的JSX配置切换到runtime: "automatic"模式，关闭所有旧版经典JSX转译插件。
• 生产环境错误引入开发版JSX运行时：新JSX运行时分dev和prod两个独立包，dev版本包含大量props校验、重复key检测、源码位置映射的开发逻辑，体积是生产版本的数倍。如果构建流程没有动态切换Babel的development参数，生产包会完整打入这些开发校验代码，很容易造成2%左右的体积涨幅。
• 静态分析失效导致摇树优化失败：如果项目中存在大量CommonJS格式的React导入（比如const React = require('react')），Webpack无法对JSX运行时的导出做静态跟踪，会把整个React包的相关依赖全量打入，而不是只引入需要的两个jsx方法，带来不必要的冗余。
• 第三方依赖适配滞后：部分老旧的组件库还没有适配新的JSX运行时，编译时会重复注入React导入逻辑，进一步放大打包冗余。

内容的提问来源于stack exchange，提问作者Leo Jiang