Go 的 internal 包不能被 vendor 代码引用，因为 internal 访问控制基于模块边界而非文件路径，vendor 目录不改变依赖包所属模块，故其代码仍受原始模块限制，无法访问主模块的 internal/ 子目录。
Go 的 internal 包为什么不能被 vendor 里的代码引用
因为 Go 的 internal 检查发生在模块解析之后、导入路径合法性校验阶段，而 vendor 目录只是把依赖“复制进来”，不改变其原始模块路径——vendor/github.com/some/lib 仍然是 github.com/some/lib 模块，它无法穿透主模块的 internal/ 边界。
常见错误现象：import "myproject/internal/util" 在 vendor/ 下某个包里出现，编译直接报错：use of internal package myproject/internal/util not allowed。
-
internal限制是 Go 编译器硬编码的规则，和是否启用go mod vendor无关 - 即使你把
internal/整个目录手动拷进vendor/，也不会生效——Go 不会从vendor/里加载internal包 - 第三方库如果硬编码引用了你的
internal路径（比如通过 build tag 或条件编译绕过），属于违反 Go 工具链约定，不可靠且会在go list -deps等场景暴露问题
路径寻址时 vendor 和 internal 的优先级怎么算
Go 的 import 路径解析顺序是：先确定模块根（go.mod 所在目录），再按以下顺序尝试匹配：
- 当前模块下的
internal/子目录（仅限本模块内代码可访问） -
vendor/目录下对应路径（前提是GO111MODULE=on且启用了-mod=vendor） - 模块缓存（
$GOPATH/pkg/mod）或$GOROOT/src
关键点：不存在“vendor 优先于 internal”或反过来的说法——internal 是访问控制机制，不是路径搜索层级；vendor 是依赖供给方式。两者作用域正交。
立即学习“go语言免费学习笔记（深入）”；
例如，你的项目结构是：
myproj/
├── go.mod
├── main.go // import "myproj/internal/log"
├── internal/
│ └── log/log.go
└── vendor/
└── github.com/some/lib/...
此时 main.go 能 import "myproj/internal/log"，但 vendor/github.com/some/lib/foo.go 即使写同样的 import，也会被拒绝。
想让 vendor 里的代码用到内部逻辑，有哪些实际可行的办法
没有“绕过 internal 限制”的合法方式，只能重构接口暴露边界。真正能落地的做法只有两个方向：
- 把需要共享的逻辑抽成独立的、非
internal的模块（比如myproj/core或myproj/api），发布为私有 module，并在go.mod中 require 它——这是最干净的解法 - 用 interface + 注册模式：在公共包里定义接口（如
log.Logger），主模块初始化时传入具体实现，vendor 包只依赖接口，不碰internal实现细节 - 避免把 vendor 当“黑盒”去 hack——很多团队试图在
vendor/里 patch 第三方代码来调用internal，结果每次go mod vendor就丢补丁，维护成本极高
启用 -mod=vendor 后，internal 行为会不会变
不会。无论 GOFLAGS="-mod=vendor" 还是默认行为，internal 的可见性规则完全不变——它只取决于导入语句所在源码文件属于哪个模块、该模块的根路径在哪。
容易踩的坑：
- 误以为
go mod vendor会“扁平化”所有路径，从而让vendor/下的代码获得和主模块同等的internal访问权 - 在 CI 中用
-mod=vendor编译通过，就认为本地开发也能随意跨internal引用——其实只是没触发那个 import，或者用了旧缓存 - 把
internal当作“私有目录命名习惯”而非语言机制，结果在重构时才发现已有外部依赖悄悄依赖了它（比如某些生成代码工具硬写了路径）
最麻烦的情况是：某个 vendor 包通过 //go:build ignore 或构建约束，在特定条件下才引入 internal 路径——这种问题往往只在某个平台或 tag 下暴露，排查起来特别慢。
