Webpack在TypeScript多入口项目中提取公共代码的核心是optimization.splitChunks配置，需显式定义entry对象、合理分组vendors与common模块，并适配TS的module设置、loader及路径别名。
Webpack 在 TypeScript 项目中做多入口公共代码提取，核心是靠 optimization.splitChunks 配置，配合合理的入口定义和模块引用结构。它不是“自动识别业务逻辑”，而是基于模块被多少个 chunk 引用、大小阈值、来源路径等规则来智能拆分。TypeScript 本身不改变这一机制，但会影响模块解析粒度和类型检查开销——所以配置要兼顾构建速度与产物质量。
明确多入口定义方式
入口必须显式声明为对象形式，每个 key 是 chunk name，value 是对应 TS 入口文件路径：
- 错误写法：
entry: './src/main.ts'（单入口，无法触发跨入口复用） - 正确写法：
entry: { home: './src/pages/home.ts', dashboard: './src/pages/dashboard.ts' } -
output.filename必须含[name]占位符，如js/[name].js，否则多个入口会冲突或覆盖
配置 splitChunks 提取两类公共代码
推荐按来源和复用频率分组，避免所有代码挤进一个 common.js：
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
-
第三方依赖单独抽离：匹配
node_modules，命名为vendors，优先级设高（如priority: 10），确保 lodash/react 等只打一次包 -
业务公共模块按引用次数提取：设置
minChunks: 2，匹配 src 下的通用工具、组件、工具函数等，命名为common；可加reuseExistingChunk: true避免重复创建相同内容的 chunk -
控制体积下限：
minSize: 10240（10KB），太小的模块不值得单独请求，避免 HTTP 请求数暴增
适配 TypeScript 的关键细节
TypeScript 模块在 Webpack 中仍是标准 ES Module，但要注意三点：
- 确保
tsconfig.json中module设为"ESNext"或"CommonJS"（与 Webpack 兼容），避免module: "NodeNext"导致解析异常 - loader 配置建议启用
transpileOnly: true（跳过类型检查），再用fork-ts-checker-webpack-plugin后台校验，防止splitChunks过程因类型错误中断 - 若使用路径别名（如
@/utils），需在resolve.alias和tsconfig.json的compilerOptions.paths中同步配置，否则 Webpack 找不到模块，splitChunks无法识别复用关系
验证是否生效的简单方法
打包后查看 dist/js/ 目录：
- 应存在
vendors.js、common.js、home.js、dashboard.js等独立文件 - 打开任意一个入口 JS，搜索你写的公共函数名（如
formatDate），它不应出现在入口文件里，而应在common.js中 - 用
webpack-bundle-analyzer可视化依赖图，确认公共模块未被重复引入
