go模块依赖管理在混合语言项目中不与python/java路径冲突，只认go.mod和导入路径；go111module=auto易因工作目录不同导致行为不一致；应禁用vendor/、隔离语言依赖，并确保模块路径与import语句严格匹配。
Go 模块依赖管理在混合语言项目中根本不会和 Python/Java 的路径系统“冲突”——它只认自己的 go.mod 和导入路径，所谓“路径冲突”其实是误把 GOPATH 时代习惯套用到 Modules 模式下，或混淆了构建产物输出路径与依赖解析路径。
为什么 go build 找不到包，却和 Python 脚本放同一目录？
Go 不扫描当前目录外的任意路径（包括 $PYTHONPATH 或 src/main/java），它只按以下顺序解析 import：
- 当前模块的
go.mod中replace声明的路径 - 本地相对路径（如
./utils） - 远程模块路径（如
github.com/org/pkg），由go.sum校验后从$GOMODCACHE加载
如果你在混合项目里把 Go 代码放在 backend/、Python 放在 frontend/，只要 Go 代码根目录有 go.mod，且 import 语句写的是模块内相对路径或已声明的远程路径，就完全不受其他语言目录结构影响。
GO111MODULE=auto 在混合项目里容易出什么问题？
当项目根目录没有 go.mod，但子目录（如 backend/）有，GO111MODULE=auto 会因当前工作目录不同而行为不一致：
- 你在
backend/下执行go build→ 成功（识别到go.mod） - 你在项目根目录执行
go build backend/...→ 报错no required module provides package（因为没进模块目录，auto回退到 GOPATH 模式）
解决方法只有一条：所有 Go 相关命令必须在 go.mod 所在目录或其子目录下执行；CI 脚本里显式加 cd backend && go build，别依赖路径自动推导。
混合项目共用 vendor/ 目录会怎样？
Go Modules 默认忽略 vendor/，除非你显式启用 go build -mod=vendor。但一旦启用：
- Go 只读
vendor/modules.txt，完全不看go.sum或远程 registry - 如果 Python 的
requirements.txt也往vendor/里塞了pip install --target vendor的内容，Go 构建时可能因文件权限、路径嵌套或缓存污染失败 -
go mod tidy会警告vendor directory is out of date，且无法自动同步 vendor 内容
建议：混合项目中彻底禁用 vendor/，用 go mod download + go.sum 锁定，把 Python 的依赖隔离到 venv/ 或 .venv/，两者物理隔离。
真正容易被忽略的点是：Go 的模块路径（module github.com/yourname/project/backend）必须和实际 import 语句完全匹配——哪怕只是大小写差异或多了个 v2 后缀，都会导致 “duplicate import” 或 “not in a module” 错误，而这类问题在混合项目里常被误判为“和其他语言路径打架”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
