查看一个模块的依赖图，发现连线绕了一圈又回到原处，接下来该改哪个文件？这时需要沿着连线找到具体引用。模块之间的依赖可能来自函数调用、类型使用、全局数据访问，也可能只是头文件包含。Understand可以把这些关系汇总到架构层，再展开到文件和代码行。分析时先确定模块划分与箭头方向，循环引用才不容易看错。

　　一、Understand如何分析模块间依赖关系

　　Understand显示的是分析数据库中的关系。源码更新后需要重新分析；目录结构与业务模块不一致时，也要先确认采用哪套架构分组。

　　1、更新分析并选定模块范围

　　①打开项目，点击【Project】→【Analyze Changed Files】，更新修改过的源码。

　　②改过宏、包含路径或语言设置时，选择【Project】→【Analyze All Files】重新分析全部文件。

　　③在【Architecture Browser】中展开目录架构或已有自定义架构，选择需要检查的模块节点。

　　目录通常适合做初步浏览。若一个业务模块分散在多个目录，应按实际职责建立分组后再判断，否则目录之间的往返引用可能被误当成业务模块之间的环。

　　2、从依赖列表打开图形

　　①右键目标目录或架构节点，点击【View Dependencies】，打开依赖浏览器。

　　②选择【Depends On】查看它依赖谁，切换【Depended On By】查看谁依赖它。

　　③右键架构节点，选择【Graphical Views】→【Dependencies】。

　　④在图形工具栏的【Variant】中选择【Internal】查看组内关系，或选择【Butterfly】查看节点两侧的依赖。

　　A调用B中的函数，会形成A依赖B的关系。依赖浏览器还保留了形成这条边的引用，可以继续展开到文件和行号。不要把双向浏览中的同一条关系，误认为已经存在两个方向的依赖。

　　二、Understand依赖图中循环引用如何定位

　　两节点相互依赖只是较简单的情况。A依赖B、B依赖C、C又依赖A，同样会形成循环，适合用依赖检查缩小范围。

　　1、对共同父节点配置循环检查

　　①点击【Checks】→【Configure Dependency Checks】，选择包含待查模块的共同父节点。

　　②勾选【No circular dependencies allowed among immediate children】。

　　③核对【Configured Checks】中的检查范围，点击【Save&Run】。

　　这项规则检查所选节点的直接子节点。如果几个目标模块不在这一层，应调整选择的父节点或架构分组。选中单个叶节点，不能据此检查任意几个模块之间的循环。

　　2、从违规结果展开循环成员

　　①在【Dependency Violations】中选择循环依赖对应的违规项。

　　②打开关联的【Dependency Violation Graph】，逐层展开涉及的架构节点和文件。

　　③在【Dependency Browser】中选择相关依赖，查看【References From】或【References To】列出的引用位置。

　　④逐条打开引用，记录循环中的方向，例如A到B、B到C以及C到A。

　　图中高亮关系可以帮助寻找断环位置，但工具给出的建议仍需结合模块职责审查。引用少的一条边，未必就是最适合移除的一条。

　　3、辨认每条边由什么引用形成

　　①在【Dependency Browser】展开目标依赖，查看引用种类、源文件及行号。

　　②分别检查调用、类型使用、数据访问和包含关系，不要只看边上的引用数量。

　　③右键相关文件，点击【View Dependencies】，核对文件层面的往返关系。

　　例如，上层模块调用底层服务，而底层服务又使用上层定义的配置类型，就可能形成模块循环，却没有函数互相递归。此时只删除一处调用，可能仍然留下类型依赖。

　　4、核对筛选范围与模块归属

　　图上看不到某条边，不代表它已从代码中消失。引用类型筛选、标准库排除，以及文件归属都会影响显示结果。

　　①打开【Dependency Browser】的选项菜单，检查【Group By】和【Architecture Tree】，确认当前分组。

　　②在【Dependency Violations】检查【Filter】，核对是否只显示某个架构或未提交修改。

　　③重新通过【Project】→【Analyze All Files】分析，再运行【Checks】→【Run Dependency Checks】。

　　C/C++的条件编译也要对照当前配置检查。某个构建变体没有启用的代码，不能用当前依赖图替其他变体作结论。

　　三、Understand循环依赖定位后如何复核调整效果

　　找到引用位置后，应先确定为什么需要这条依赖，再决定调整方式。把节点移出检查范围，只会改变检查结果，不会消除代码中的耦合。

　　1、选定需要调整的接口边界

　　①在【Dependency Browser】选择准备处理的反向依赖，展开它的全部引用。

　　②逐条打开代码，区分公共类型、业务实现与共享数据，确认影响范围。

　　③查看相关模块的【Depended On By】，核对还有哪些调用方使用该接口。

　　公共类型放错层、底层回调上层实现，以及双方共用状态，处理方式并不相同。可以评估提取公共契约、通过接口传入行为或重新划分职责，但应以代码语义和测试结果决定。

　　2、用原检查范围重新验证

　　①修改代码后，点击【Project】→【Analyze Changed Files】；涉及分析配置变化时，改用【Analyze All Files】。

　　②执行【Checks】→【Run Dependency Checks】，查看原循环是否仍被报告。

　　③重新打开【Graphical Views】→【Dependencies】，保持原有架构层级和显示口径进行比较。

　　移除一条边可能打断一个环，也可能仍有另一条路径连接回来。因此需要复查整个相关区域，不能只确认某根连线消失。

　　3、保留可追溯的检查结果

　　①在【Dependency Violations】中选择本次检查结果，使用【Export csv】导出记录。

　　②进入【Checks】→【Configure Dependency Checks】，核对保存的规则仍覆盖目标模块。

　　检查记录应与代码版本、分析配置一起留存。后续出现新的循环时，才方便区分新增问题与尚未处理的历史关系。

　　总结

　　依赖图的用途，是让模块边界在代码中有据可查。一个循环背后，可能是公共类型放置不合适，也可能是职责长期交叉累积的结果。Understand能够把图上的关系追到具体引用，帮助团队讨论调整范围，但修改方案仍需要结合接口约定和回归测试判断。日常保留一套稳定的模块划分与依赖规则，比临时查看一张全项目大图更便于持续维护。希望这些操作能帮助大家查清循环引用的位置，减少盲目改动。如有代码分析相关需求，欢迎进一步沟通咨询。