核心思路是切断隐式命名空间污染，用显式模块边界替代类路径的“扁平查找”机制；变量冲突本质是运行时命名空间被意外覆盖，须通过import全路径调用、限制from导入、精确控制__all__导出及构建期强制检查来预防。
核心思路是切断隐式命名空间污染，用显式模块边界替代类路径的“扁平查找”机制。变量冲突本质不是语法错误，而是运行时命名空间被意外覆盖——这在类路径模式下几乎无法预防，必须转向模块化约束。
停止使用 from ... import 同名符号
这是最直接的冲突源头。Python中 from auth.models import User 和 from billing.models import User 连续执行，后一个会静默覆盖前一个。Java中虽无类似语法，但Maven默认拉取传递依赖时，若多个模块都引入 commons-lang3 不同版本，JVM加载器只会选一个，其他版本的类变量/静态字段实际不可见。
- Python改用
import auth.models+auth.models.User()调用，路径即上下文 - Java在
module-info.java中严格声明requires java.sql;，不声明的包即使在classpath里也访问不到 - 禁用
import static批量导入常量或工具方法，尤其避免import static org.junit.Assert.*这类泛导入
用模块路径（modulepath）替代类路径（classpath）
Java 9+ 的模块系统强制依赖可见性。把jar打成模块（含 module-info.class），JVM就不再按传统classpath顺序扫描所有类，而是只加载requires声明且exports暴露的包。
- 编译时加
--module-path指向模块目录，而非-cp - 运行时用
java --module-path mods --module com.example.app/com.example.Main - 非模块化jar可封装为自动模块（automatic module），文件名即模块名，但需手动
exports关键包
重构包结构与导出策略
模块化不是简单加个 module-info.java，而是重新设计包职责。原来放在 com.example.utils 下的通用工具类，若被多个业务模块依赖，应拆为独立模块并精确导出。
- 每个模块只
exports真正需要对外暴露的包，如exports com.example.auth.api; -
com.example.auth.internal这类包不导出，即使同名类存在，外部也无法引用 - Python对应做法：包内
__init__.py不再from .user import User，改为仅留__all__ = ["UserV1", "UserV2"]并显式重命名导入
建立构建期强制检查机制
靠人工约定易失效，需工具链卡点。
- Maven项目启用
maven-enforcer-plugin，配置dependencyConvergence规则，构建失败时直接报出版本冲突 - Python项目用
pipdeptree --warn fail检查重复安装的包，CI流程中加入此步骤 - IDE设置：IntelliJ中关闭 “Add library to classpath” 自动勾选；PyCharm禁用 “Show all files in external libraries” 遮蔽真实模块路径
