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，而非重复内联。
验证方法：
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
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 设计哲学的方式是：
- 保持各组件独立动态导入（维持可维护性）；
- 信任生产构建的自动优化；
- 如需进一步控制，可显式配置 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 框架的设计本意。
