internal 包到底能被谁导入？
只有和 internal 包在同一个模块（module）下、且路径满足「父目录包含 internal」规则的包，才能导入它。不是“同项目”就行，而是必须满足 Go 的路径约束：比如 /a/b/internal/c 只能被 /a/b/... 下的包导入，/a/x 就不行，哪怕它们都在同一个 git 仓库里。
常见错误现象：import "/a/b/internal/c": use of internal package not allowed —— 这说明调用方路径不满足父子关系，或者跨了 module 边界（比如调用方是另一个 go.mod 管理的模块）。
- 模块根目录下放
internal/，是最稳妥的做法；放在子目录如pkg/internal/会缩窄可访问范围 -
go list -f '{{.Imports}}' ./path/to/pkg可验证实际导入链，比直觉更可靠 - 测试文件（
*_test.go）如果和被测包在同一目录，可以访问其internal子包；但如果是外部测试包（如example_test.go在其他目录），就不行
internal 不是私有作用域，只是 import 限制
internal 包里的标识符（函数、变量、结构体）只要导出（首字母大写），在包内就是公开可访问的——它不提供语言级封装，只拦 import。也就是说，internal 包自己完全可以暴露 func Do() {}，而调用方只要符合路径规则，就能用。
真正想隐藏实现细节，得配合导出控制：do() 小写函数 + Do() 大写接口/包装函数，才是常规做法。
立即学习“go语言免费学习笔记（深入）”；
- 别指望
internal防止别人读源码或反射调用；它只防编译期 import - 如果把核心算法全塞进
internal，又没做任何导出限制，等于“锁了门却把钥匙留在门垫下” - 第三方依赖无法绕过
internal限制，但你自己写的命令行工具（cmd/xxx）如果和internal同模块，是可以直接用的
vendor 和 replace 会影响 internal 的行为吗？
不影响。Go 的 internal 检查发生在 go build 的导入解析阶段，只看源码路径和模块声明，和是否启用了 vendor、有没有 replace 无关。
但容易踩的坑是：本地用 replace 把某个模块指向本地路径后，如果该本地路径结构不符合 internal 规则（比如你把 github.com/a/b replace 到 /tmp/local，而 /tmp/local/internal/c 被 /tmp/other 导入），照样报错。
-
vendor/目录下的internal包，仍然遵循原始模块的路径规则，不是 vendor 根目录 - CI 环境中如果用了多模块构建（如
go work），每个 workspace module 的internal是独立判断的 - 用
go mod graph | grep internal能快速确认是否有非法跨 internal 引用被意外引入
替代 internal 的更细粒度封装方式有哪些？
真要保护逻辑不被误用，internal 往往不够。Go 原生没 private 关键字，所以得靠组合手段：
- 把敏感逻辑抽成 unexported 类型 + exported interface，只暴露方法签名（如
type processor interface { Run() }） - 用函数选项模式（functional options）代替暴露结构体字段：
NewClient(WithTimeout(30))而非c.Timeout = 30 - 在文档里明确标注
// DO NOT USE: for internal use only，虽然不强制，但对协作团队有效 - 静态检查工具如
revive或自定义go vet规则，可以拦截对特定internal包的非法引用（需配置）
最常被忽略的一点：internal 目录名本身不是魔法字符串，internal 是硬编码在 Go 源码里的；但如果你把它改成 priv 或 impl，就完全失去限制效果——名字不能换，路径规则也不能松动。
