next.js 在开发模式下对 dynamic() 导入的组件会独立打包其依赖（如 react-plotly.js），导致相同包被多次加载；但在生产构建后，webpack 会自动进行模块去重与代码分割优化，确保共享依赖仅加载一次。
next.js 在开发模式下对 dynamic() 导入的组件会独立打包其依赖（如 react-plotly.js），导致相同包被多次加载；但在生产构建后，webpack 会自动进行模块去重与代码分割优化，确保共享依赖仅加载一次。
在 Next.js 应用中，使用 dynamic({ ssr: false }) 实现客户端渲染组件时，开发者常误以为多个组件共用同一第三方库（如 react-plotly.js）会自然复用已加载的模块。然而，在 开发环境（next dev）中，每个 dynamic() 导入都会触发独立的 Webpack 按需 chunk 构建，且热更新机制会隔离模块实例，导致相同依赖被重复打包、重复下载——正如你观察到的 5.4MB 的 react-plotly.js 被加载 4 次。
但这一现象仅存在于开发阶段。当你执行 next build && next start 启动生产环境时，Next.js 底层基于 Webpack 5 的模块联邦与 SplitChunksPlugin 会自动识别并合并跨 chunk 的公共依赖。只要这些组件最终被打包进同一构建产物（即未被强制分割为互不关联的异步 chunk），react-plotly.js 将被提取至一个共享 chunk（如 common-xxx.js），由所有组件按需懒加载该唯一 chunk，实现真正的单次加载、全局复用。
✅ 验证方式：
构建后检查 .next/static/chunks/ 目录，你会看到类似 1234.abcd5678.js（Chart 组件逻辑）和 common.efgh9012.js（含 react-plotly.js 及其依赖）的分离文件；同时在浏览器 Network 面板中，该 common chunk 仅请求一次。
⚠️ 注意事项：
- 不要手动在 _app.js 中提前 import 'react-plotly.js' 并通过 Context 注入——这会强制将庞大依赖注入首屏 JS，增加 TTFB 和初始包体积，违背 code-splitting 原则；
- 确保各组件未使用 loadable 或自定义 webpack 配置干扰默认分包策略；
- 若仍存在重复加载，可检查 next.config.js 中是否禁用了 splitChunks，或组件路径存在命名冲突（如 Chart1/index.tsx 与 Chart1.tsx 并存导致 Webpack 视为不同模块）。
? 最佳实践建议：
// ✅ 推荐：保持 dynamic 导入，信任 Next.js 生产构建优化
const Chart1 = dynamic(() => import('@/components/scheduling/Chart1'), { ssr: false });
const Chart2 = dynamic(() => import('@/components/scheduling/Chart2'), { ssr: false });
// ... 其余同理总结：Next.js 默认具备跨动态组件的依赖去重能力，无需手动干预。关键在于区分开发与生产行为——开发时的重复加载是调试友好性设计，而非缺陷；真正影响性能的是生产构建结果。始终以 next build 后的 Lighthouse 报告和 Network 分析为准，而非 next dev 的临时表现。
