嘿，这个问题确实挺闹心的——12分钟的构建时长加上同一个文件被反复处理几十次，肯定得把根源揪出来。我来分享几个实用的调试思路，帮你一步步定位问题：

1. 生成并分析Webpack的详细构建统计 #

首先用Webpack自带的工具生成完整的构建统计数据，这能帮你看清每个模块的处理上下文：

webpack --profile --json > build-stats.json

打开生成的build-stats.json，搜索attachment.field.ts，你会看到这个文件的所有处理实例。重点看这几个字段：

• issuer: 是谁引入了这个模块？如果有几十个不同的issuer，说明它被很多地方重复引用了
• chunks: 这个模块属于哪些chunk？如果分散在多个chunk里，可能是splitChunks配置导致的重复打包
• loaders: 处理这个文件的loader链是什么？有没有重复的loader或者未缓存的环节

你也可以用Webpack官方的分析工具（本地运行即可）加载这个json文件，可视化查看模块的依赖关系和chunk分布。

2. 检查Loader的缓存配置 #

TypeScript文件重复处理且耗时久，大概率和loader未开启缓存有关。比如ts-loader或者@ngtools/webpack（Angular官方loader），如果没配置缓存，每次构建都会重新编译同一个文件：

• 对于ts-loader，确保开启cacheDirectory选项：

  module.exports = {
    module: {
      rules: [
        {
          test: /\.ts$/,
          loader: 'ts-loader',
          options: {
            cacheDirectory: true, // 开启缓存
            transpileOnly: true // 配合缓存提升速度，可选
          }
        }
      ]
    }
  }
  

• 如果你用Angular的@ngtools/webpack，它默认会缓存，但可以检查angular.json里的build配置，确保cache选项是开启的。

3. 排查模块重复引入与循环依赖 #

有时候代码里的循环依赖或者错误的路径引用，会导致Webpack多次解析同一个文件：

• 检查attachment.field.ts的import语句，有没有相对路径错误（比如用../和./混用，导致Webpack认为是不同的模块）
• 用webpack-bundle-analyzer本地分析bundle，看看这个文件是不是出现在多个chunk中。安装后运行：

  npx webpack-bundle-analyzer build-stats.json
  

  可视化界面里能直观看到模块在各个chunk中的分布，判断是否有不必要的重复打包。

4. 验证日志重复是不是插件本身的问题 #

simple-progress-webpack-plugin可能会因为Webpack的钩子触发逻辑，重复打印日志。暂时禁用这个插件，改用Webpack自带的--progress参数构建：

webpack --progress

如果自带的进度日志里没有重复处理的记录，那问题可能出在插件的钩子监听逻辑上；如果还是有重复，那就是Webpack编译流程本身的问题。

5. 检查Angular构建的多阶段配置 #

JavascriptServices模板生成的配置可能包含多阶段编译（比如AOT编译+打包），或者多环境、多语言的构建任务，导致同一个文件被多次处理：

• 查看angular.json里的architect.build配置，有没有开启aot和buildOptimizer的组合，或者有没有outputPath被多次覆盖的情况
• 检查是否有多个构建入口，或者lazy loading的路由配置导致模块被多次打包

6. 开启Webpack调试模式看详细流程 #

如果以上方法还没找到问题，开启Webpack的调试模式，获取更细粒度的编译日志：

webpack --debug --verbose

或者在webpack配置里添加：

module.exports = {
  // ...其他配置
  stats: 'verbose'
}

这些日志会显示每个模块从解析、编译到打包的完整时间线，你能看到attachment.field.ts每次被处理的触发原因，比如是哪个chunk的构建触发了它的编译。

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