Next.js 在开发模式下可能对动态导入的组件重复打包相同依赖（如 react-plotly.js），但在生产构建后会自动进行代码分割与共享模块 deduplication，确保同一依赖仅加载一次。本文详解其原理、验证方式及最佳实践。

next.js 在开发模式下可能对动态导入的组件重复打包相同依赖（如 `react-plotly.js`），但在生产构建后会自动进行代码分割与共享模块 deduplication，确保同一依赖仅加载一次。本文详解其原理、验证方式及最佳实践。

在 Next.js 应用中，当多个客户端渲染（CSR）组件（如 Chart1–Chart4）各自动态导入并使用同一重型依赖（例如 react-plotly.js）时，开发者常观察到开发环境网络面板显示该包被重复加载多次（如 5.4MB × 4）。这容易引发误解——以为 Next.js 缺乏模块去重机制。但事实是：此现象仅存在于 next dev 开发服务器中，而非真实生产环境。

✅ 生产构建自动实现模块共享

Next.js 的 Webpack（v13+ 默认为 Turbopack 兼容架构）在 next build 阶段会对所有动态导入的 chunk 进行全局分析，并将公共依赖提取至独立的共享 chunk（如 commons-xxx.js）。只要多个动态模块引用同一 npm 包（且版本一致），该包就会被合并打包一次，后续组件按需加载该共享 chunk，而非重复内联。

验证方法：

抖音下载器(Node.js)

抖音无水印视频下载和文案提取工具

下载

next build && next start

然后访问页面并打开浏览器 Network 面板（禁用缓存），观察 /_next/static/chunks/ 下的 JS 文件——react-plotly.js 相关代码仅出现在一个 chunk 中，其余组件 chunk 体积显著减小，且无重复加载。

⚠️ 开发模式为何“看起来重复”？

• next dev 为提升热更新速度，默认启用 模块联邦式隔离加载：每个 dynamic() 导入生成独立的临时 chunk，不强制跨组件共享依赖，便于局部刷新；
• 此行为是开发体验优化，不反映真实部署行为，切勿以此评估生产性能。

✅ 推荐实践（无需 Context 曲线救国）

虽然您已通过 _app.js 提前加载 react-plotly.js 并用 Context 注入（有效规避了开发期问题），但这增加了架构复杂度，且非必需。更简洁、符合 Next.js 设计哲学的方式是：

1. 保持各组件独立动态导入（维持可维护性）；
2. 信任生产构建的自动优化；
3. 如需进一步控制，可显式配置 Webpack splitChunks（Next.js 13.4+ 支持 next.config.js 中 webpack: (config) => {...}）：

   // next.config.js
   module.exports = {
     webpack: (config) => {
       config.optimization.splitChunks = {
         ...config.optimization.splitChunks,
         cacheGroups: {
           plotly: {
             name: 'plotly',
             test: /[\/]node_modules[\/](react-plotly.js|plotly.js)[\/]/,
             priority: 20,
             chunks: 'all',
           },
         },
       };
       return config;
     },
   };

? 补充建议

• 使用 next build --debug 查看详细 chunk 分析；
• 通过 @next/bundle-analyzer 可视化依赖分布；
• 若仍遇生产环境重复加载，请检查：
  • 各组件是否引用不同版本的 react-plotly.js（版本不一致将无法共享）；
  • 是否存在 require() 或 eval() 等阻止静态分析的动态引用。

总之，Next.js 的模块加载优化已在生产构建中默认生效。专注写清晰的组件逻辑，让构建工具处理底层优化——这才是现代 React SSR 框架的设计本意。