## 循环依赖（Medium）

### 触发信号

- `import A` → A 模块又 `import` 当前文件（直接循环）
- 模块间存在 A→B→C→A 的依赖链（间接循环）
- 延迟导入（`import()` 动态导入）打破循环但暗示架构问题

### 判定流程

1. **构建依赖图**：`Read` 提取变更文件的 `import`/`require` 语句，标记依赖关系
2. **检测直接循环**：`find_references` 检查被导入的模块是否导入了当前文件
3. **检测间接循环**：对被导入的模块递归检查其导入（最多 3 层），构建依赖链，检测是否存在环
4. **评估影响**：`Read` 确认循环依赖的实际影响：
   - 运行时是否导致 undefined（模块未完成初始化就被引用）
   - 是否存在延迟导入已作为临时解决方案
5. **识别耦合问题**：即使无循环，`Read` 识别过度耦合：
   - 工具模块被业务模块导入（应单向依赖）
   - 底层模块引用了高层模块（依赖倒置违反）

### 证据构造

确认缺陷后，输出需包含：
- 循环依赖链（A → B → ... → A 的完整路径）
- 影响评估（运行时错误/undefined 风险/架构问题）
- 建议解法（提取公共模块、依赖注入、事件解耦、延迟导入）

### 排除

- 已通过延迟导入（`import()`）打破了运行时循环
- 类型声明文件的相互引用（`*.d.ts` 互相 import type 不影响运行时）
- 同一目录下的紧密耦合模块（如 `index.ts` 重导出）
- 框架约定（如 Next.js 的 page/layout 互引）
- 涉及第三方包的依赖链（三方依赖不可见，无法确认包内部引用关系）
