解读

在国内一线/二线大厂的 Go 服务拆分实践中，代码往往被拆成几十甚至上百个私有仓库，每个仓库都是一个独立 Go Module。此时“internal 能不能被隔壁模块用”成为高频踩坑点：

1. 很多候选人把 internal 简单类比 Java 的 package-private，误以为“只要在同一公司、同一项目”就能穿透；
2. 也有人把 internal 与 vender 混为一谈，认为“replace 一下就能看见”；
3. 面试官真正想确认的是：你对 “Go 编译器在模块时代如何判定 import 路径是否合法” 这一底层规则是否了然于胸，以及你是否能在 跨模块、跨仓库、跨版本 的复杂场景下，依然保证封装性不被击穿。

知识点

1. 可见性判定单元：Go 把 “模块根目录” 作为可见性边界，而不是 Git 仓库、组织名或文件系统上级目录。
2. internal 语义：
   • 位于 <module>/internal/ 下的包，只允许被 <module> 前缀的路径 import；
   • 任何 模块 M 想 import 模块 N 的 internal，只要 M 的模块路径不是 N 的前缀，就会被编译器 硬拒绝，与 replace、vendor、go.work 无关。
3. 跨模块场景：
   • 若公司级共享库想隐藏实现，只能把 internal 放在 叶子模块 里，让业务模块通过 公开 API 模块 间接依赖；
   • 若强行通过 本地 replace 把两个模块拼到同一目录，虽然能编译过，但 go.mod 中模块路径仍不一致，CI 或别人拉代码时依旧失败——属于 掩耳盗铃。
4. 版本升级风险：
   • 一旦误把 internal 包写在 go.mod 的 require 里，后续版本即使作者把 internal 删掉，你的项目也会 编译直接失败（国内大厂曾因此阻塞全量发布）。
5. 工具链验证：
   • go list -m all 可以看到真实解析路径；
   • go mod why -m <target> 可回溯是谁间接引用了 internal；
   • go vet 在 Go 1.20+ 会对 “跨模块 import internal” 给出明确错误，不再只是提示。

答案

Go 的 internal 机制在跨模块场景下依旧以 “模块路径前缀” 为唯一判据：
只要 import 方的模块路径不是被 import 方模块路径的前缀，编译器就会 直接报错，replace、vendor、go.work 均无法绕过。
因此，若模块 A（github.com/company/foo）试图 import "github.com/company/bar/internal/util"，无论 A 的 go.mod 里如何 replace 到本地 ../bar，只要 A 的模块路径不是 github.com/company/bar 本身，构建就会失败。
正确做法是：把需要共享的符号提升到 bar 的 非 internal 公开包，或再拆一个 api 模块 供外部依赖，确保 封装边界与模块路径边界严格对齐。

拓展思考

1. 在 单仓库多模块（monorepo）模式下，如何既利用 internal 隐藏实现，又让不同业务模块共享公共逻辑？
   答：可在仓库根再建一个 “公共叶子模块”，如 company.com/repo/lib，把公共 internal 放在该模块下，其他业务模块通过 “路径前缀相同” 原则自然可见，而外部仓库仍无法触碰。
2. 国内很多团队把 “internal 误当版本管理工具”，在 v1.0.0 把类型暴露在 internal，v1.1.0 直接删除，导致下游业务编译即挂。
   建议：在 CI 中增加 “go list -json ./... | jq 选中含有 internal 的 import” 的强制卡点，一旦检测到跨模块引用 internal，直接拒绝 MR，从根本上杜绝 “今天能编，明天上线失败” 的 P0 故障。