webpack 不会因 typescript 循环依赖直接报错，但运行时会暴露 undefined 导出等问题；需用 circular-dependency-plugin 检测并重构代码打破闭环，如抽离共享逻辑、动态导入或接口依赖注入，并配合 ts 配置验证解决效果。

Webpack 本身不会因 TypeScript 的循环依赖直接报错，但会在运行时暴露问题——比如模块导出为 undefined、函数调用失败、或构建后功能异常。真正需要解决的是代码结构层面的依赖闭环，而不是单纯靠 Webpack “绕过”它。

用插件主动发现循环依赖

安装并启用 circular-dependency-plugin 是第一步，它能在构建阶段提前暴露问题：

• 运行 npm install --save-dev circular-dependency-plugin
• 在 webpack.config.js 的 plugins 中加入：

  new CircularDependencyPlugin({
    exclude: /node_modules/,
    failOnError: true,
    allowAsyncCycles: false
  })

• 构建时一旦检测到 A → B → A 这类路径，就会中断并打印完整链路，例如：src/utils/a.ts -> src/services/b.ts -> src/utils/a.ts

重构代码打破依赖闭环

插件只报错，不修复。核心解法是让依赖变成单向或解耦：

Add Typescript Best Practices

在 CLAUDE.md 中配置 TypeScript 最佳实践和代码风格规则

下载

• 抽离共享逻辑到独立模块：把 A 和 B 都用到的类型、工具函数、常量移到 shared/ 或 types/ 目录下，双方只依赖它，不再互相引用
• 延迟导入（dynamic import）：把 B 中对 A 的依赖从顶部 import 移到具体函数内，例如：

  // moduleB.ts
  export function doSomething() {
    const { helper } = await import('./moduleA'); // 运行时才加载
    return helper();
  }

• 接口先行 + 依赖注入：定义 IApiService 接口在单独文件，A 和 B 都只依赖接口；实际实现由上层组装传入，避免编译期硬依赖

配合 TypeScript 编译配置规避干扰

确保 TS 不生成中间文件干扰 Webpack 流程：

• 在 tsconfig.json 中设 "noEmit": true，关闭 tsc 自动输出，交由 Webpack + ts-loader 统一处理
• 确认 webpack.config.js 的 resolve.extensions 包含 '.ts'，且顺序靠前，避免同名 .js 被误解析
• 检查 ts-loader 是否启用 transpileOnly: false（默认开启类型检查），否则循环依赖引发的类型错误可能被静默忽略

验证是否真正解决

改完代码后不要只跑一次构建：

• 重新执行 Webpack 构建，确认插件不再报错
• 启动开发服务器，手动测试涉及 A/B 模块的功能路径
• 必要时用 webpack-bundle-analyzer 查看打包产物，确认相关模块没被重复或空引入