为何requires transitive仅局限于直接依赖其所在模块的模块？

这问题问到了Java模块系统（JPMS）设计的核心逻辑上——依赖的可控性与模块边界的清晰化，咱们结合你给出的场景一步步拆解：

先明确requires transitive的本质作用 #

当模块A声明requires transitive X时，它想传递的信息是：“我的对外API依赖了X的类型，所以任何直接依赖我的模块（比如你的B1-B100）必须能访问X才能正常使用我的功能”。所以JPMS只会把X的依赖权限传递给直接依赖A的模块，而不会继续向下传递给依赖B的C模块，这是刻意设计的行为。

为什么不能无限传递？核心原因有三个： #

1. 避免不必要的隐式依赖，防止依赖爆炸 #

你的场景里，C1-C100根本不需要了解A的包，更别提X了。如果requires transitive能无限传递，那这些C模块会莫名其妙地间接依赖X——但它们完全用不到X的功能。这种隐式依赖会带来两个大问题：

• 一旦X模块升级、变更甚至被移除，所有间接依赖它的C模块都可能出现编译或运行错误，哪怕它们和X毫无业务关联。
• 模块的依赖图谱会变得极其臃肿，你根本没法快速理清一个模块到底需要哪些依赖，维护成本直线上升。

2. 强制依赖显式化，守住模块边界 #

JPMS的核心目标之一就是让模块的依赖关系透明、可控。每个模块只应该依赖自己明确需要的资源：

• B模块依赖A，而A声明了requires transitive X，说明B确实可能需要用X的类型（比如A的方法返回X里的类），这时候自动传递X的依赖是合理的，也帮B省了手动声明的麻烦。
• 但C模块只依赖B，它的需求应该由B的API来满足。如果C真的需要X的功能，那它应该自己显式声明requires X，而不是靠多层传递来“偷偷”获取依赖——这能让C模块的依赖关系一目了然。

3. 降低模块间耦合，减少变更扩散 #

假设某天A模块不再需要X了，把requires transitive X改成了普通的requires X：

• 如果传递只到B模块，那只有A和直接用了X的B模块需要调整，C模块完全不受影响。
• 如果允许传递到C模块，那所有C模块都会因为突然找不到X的依赖而报错，把A的内部依赖变更扩散到了无关的上层模块，耦合度太高了。

结合你的场景再梳理一遍逻辑 #

• 模块A用requires transitive X：告诉所有直接依赖我的B模块“你要用我，就得能访问X”，这是因为A的API基于X构建。
• B模块依赖A：自动获得X的访问权限，不用手动声明，同时明确了“A的API依赖X”这个事实。
• C模块依赖B：只需要关注B的API即可，和A、X无关。如果C需要X，那它应该自己显式声明requires X，而不是靠传递——这是C模块维护者的主动选择，而非被动接受的隐式依赖。

这样设计下来，每个模块的依赖关系都是清晰可控的，不会出现“莫名其妙依赖了某个模块”的情况，这也是JPMS解决传统Java依赖混乱问题的关键手段之一。

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