internal 不是访问控制机制，它仅在 import 阶段校验路径前缀，不限制运行时调用、反射或同模块内访问；真正封装需依赖小写字段、接口抽象和工厂函数。
不能靠 internal 实现“优雅”的访问隔离——它只拦 import，不拦调用、不拦反射、不拦同模块内任意访问。 真正想隔离，得放弃把它当“私有包”用，转而用小写字段 + 接口 + 工厂函数组合拳。
为什么 internal 不是访问控制机制
internal 目录只是 Go 编译器在 import 解析阶段做的路径守门员：只要 import 路径含 /internal/，就检查调用方的 module 路径前缀是否匹配。它不管运行时行为，也不管符号可见性。
- 错误信息固定为：
use of internal package not allowed，只出现在 import 行，不会在c := &config.Config{Port: 8080}这种赋值时报错 - 同一模块下，
cmd/server可以直接 newinternal/db.DB、修改其导出字段、调用其导出方法 - 测试文件（
*_test.go）只要和被测包同属一个 module，就能自由 importinternal/xxx -
reflect、unsafe、//go:linkname完全不受限——只要类型导出，就能读写
真正起作用的封装手段只有三个
Go 的访问控制唯一语言级机制是首字母大小写。想让别人“用不了”，就得让他们“看不见”。
- 把结构体字段全设为小写：
type DB struct { addr string; port int }，外部无法直接访问或赋值 - 只导出接口：
type DBer interface { Query(string) error }，隐藏具体实现 - 提供工厂函数返回接口：
func NewDB(...)返回DBer，而不是*DB - 避免在
internal包里暴露导出结构体或导出字段——否则等于白放
多模块项目里 internal 边界最容易误判
在 go work 下，./module-a 和 ./module-b 是两个独立 module，即使物理相邻，module-b 也不能 import module-a/internal/db。
- 报错仍是：
use of internal package not allowed，不是权限问题，是路径前缀不匹配 -
go list -f '{{.Module.Path}}' ./module-b可确认当前目录所属模块路径 -
go work use ./module-a只影响go run或go test的模块解析，不放宽internal限制 - vendor 目录下的
internal仍按原始模块路径判断，不是以 vendor 根为基准
CI 构建失败但本地 OK？先查工作目录路径
CI 环境（如 /tmp/build）和 go.mod 中声明的 module 路径不一致时，Go 会算错模块根，导致 internal 路径校验失败。
- 本地路径可能是
/home/user/myapp，而 CI 是/tmp/build/myapp - 如果
go.mod写的是module github.com/user/myapp，但实际工作目录不在该路径下，import 就会失败 - 验证方式：
go list -f '{{.Imports}}' ./cmd查看真实导入链，比直觉更可靠 - 解决方案：CI 脚本中确保
cd到正确路径，或用GO111MODULE=on GOPATH=... go build显式控制
最常被忽略的一点：internal 是路径守门员，不是封装工程。它解决的是“谁不该 import”，而不是“谁不该用”。想让别人用不了，得从语言设计本身下手——小写字段、接口抽象、工厂隔离，缺一不可。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
