依赖巡航架构守卫

问题：当依赖关系开始悄悄失控

在 JS/TS 项目演进过程中，最棘手的问题往往不是某一次编译失败，而是依赖图慢慢偏离最初的架构意图：某层本不该直接引用框架的内部包，却因为赶进度绕过了接口边界；模块之间形成了环状依赖，谁也不敢先动；某个目录里躺着一堆没人引用的孤立模块，靠构建产物里多出来的 chunk 才被发现。这类问题通常不会让 CI 立即变红，但它们会持续侵蚀分层边界——当团队成员习惯了 import 从任何地方拉取代码时，架构漂移就已经扩散了。

这个技能如何工作

这个技能把依赖规则变成可执行的检查项，核心思路是先定义边界，再持续校验：

• 依赖规则即配置：通过 dependency-cruiser 的规则配置声明哪些路径是合法依赖，哪些是禁止的导入，例如限制特定模块只能被上层引用、禁止跨层访问实现细节。
• 多维度扫描：覆盖四类典型违规——禁止导入（forbidden imports）、循环依赖（circular dependencies）、孤立模块（orphaned modules），以及更细分的规则违反。
• 静态分析：直接解析源码中的 import/require 语句构建依赖图，不依赖运行时，因此可以在提交前或 CI 中快速反馈。
• 生成配置：提供初始化入口，从已有项目中快速生成规则配置骨架，再按需收紧。

适用边界与注意点

• 规则配置需要团队共同维护，脱离实际分层约定的规则表很快就会变成噪音，团队需要定期 review 违规清单。
• 它解决的是依赖拓扑问题，不替代代码审查、不检测运行时行为，也处理不了设计层面的概念耦合。
• 对超大 monorepo，全量扫描的耗时需要纳入 CI 规划。
• 规则本身是代码资产：规则与项目结构脱节时，要么收紧要么删除，否则检查会逐渐失去约束力。