JavaScript及其他技术栈中创建循环依赖的真实合理场景示例探讨

背景：重构项目里的循环依赖爆发 #

我们团队正在推进一个老代码库的完全重构项目——原代码已经臃肿到难以维护，新代码库至今有1年历史。我不是这个项目的架构师，而且项目初期的6个月我被借调到了其他团队，近期才深度参与进来。

最近我用静态分析工具扫描新代码库，发现了两个循环依赖集群：涉及的文件数从一个月前的109个，一路涨到115个、130个，现在已经到146个了。更糟的是，这些不是简单的a→b→c→a单环，而是一堆复杂交织的依赖关系，那依赖图乱得像被龙卷风袭击过的服务器机房。

我在团队频道里提了这件事，和架构师的对话如下：

我：“大家好，我刚发现代码里存在循环依赖问题，涉及约109个文件（一个月前的数据）。想了解大家对此的看法，以及我们是否是出于某些原因才这样设计的……”
架构师：“我认为代码库中不存在不良的循环依赖，我使用async来消除循环依赖。”
我（心里吐槽后）：“呃……循环依赖指的是a -> b -> c -> a的依赖关系。async确实能让编译器合理处理初始化逻辑，但这仍然属于循环依赖，而这类依赖通常并不理想。”
架构师：“我觉得这件事可以放到待办事项里，最多算是优先级很低的技术债务。”

核心疑问：循环依赖真的有“合理存在”的场景吗？ #

这段经历让我一直琢磨：有没有某些场景下，创建循环依赖是解决问题的最佳方案甚至唯一方案？

目前我能想到的只有对接设计糟糕的第三方库的情况，但我相信还有更多可能性。我过去10年主要从事JavaScript开发，对C#和Java的相关实践记忆已经模糊了，想听听社区里的经验分享。

后续行动：全组织代码健康审计系统 #

这件事也倒逼我开发了一套功能强大的代码审计系统，支持在多团队、多代码仓库、多语言环境下，实现全组织范围内的代码健康度透明化。我计划把这个仓库转为开源，感兴趣的朋友可以联系我。

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