internal包不是私有作用域，只是import路径守门员：它仅在编译期拦截非法import，不限制运行时访问、不控制符号可见性；只要标识符导出且路径合规，本模块内任意包均可直接使用。
internal包不是私有作用域，只是import路径守门员
Go 的 internal 目录不控制符号可见性、不隐藏类型、不限制运行时访问——它只在编译期拦截非法 import。只要标识符首字母大写（比如 type Config struct{} 或 func New() *Config），且调用方路径合规，就能被本模块任意包直接实例化、赋值、调用方法。
常见误判：把结构体塞进 internal/config 就以为“安全”，结果 cmd/server 里一行 c := &config.Config{Port: 8080} 就能跑通。这不是 bug，是机制设计如此。
-
internal检查发生在 import 解析阶段，早于类型检查，错误信息固定为：use of internal package not allowed - 反射、
unsafe、//go:linkname完全不受限——只要符号导出，就能被读取或绑定 - 测试文件（
*_test.go）若与被测包同属一个 module 且路径合规，可自由 importinternal，无需额外配置
跨模块 import 失败的根本原因是路径前缀不匹配
报错 import "github.com/user/myapp/internal/utils" is not allowed to import from outside the repository 不是因为权限不足，而是 Go 编译器硬编码校验：调用方的 import 路径必须以 internal 所在模块的 module 声明为前缀，且不能跨 module boundary。
例如模块声明为 module github.com/user/myapp，则只有 github.com/user/myapp/... 下的包能导入 github.com/user/myapp/internal/utils；哪怕 fork 到 github.com/other/fork，也会立刻失败。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- CI 构建失败但本地 OK？大概率是 CI 工作目录路径（如
/tmp/build）和go.mod中module声明不一致，导致模块根计算错误 - 多模块项目中，
go work下的每个go.mod独立定义internal边界：./module-a和./module-b互不可见，即使物理路径相邻 -
vendor/目录不影响internal规则——第三方依赖仍按原始模块路径判断，无法访问主模块的internal
真正想隐藏实现，得靠小写首字母 + 接口 + 工厂函数
仅靠 internal 无法防止内部误用或下游强依赖。要达成封装效果，必须配合语言级可见性控制：
- 把具体实现类型设为小写（如
type dbClient struct{}），不导出 - 定义导出接口（如
type DB interface{ Query(...)}），放在上层包（如pkg/db） - 提供导出工厂函数（如
func NewDB(...) DB），返回接口而非具体类型 - 避免在
internal里放大量导出类型——如果必须导出，说明它其实该提升到公共 API 层
否则，internal 只是给调用方加了一道“需要写对路径”的门槛，而不是真正的抽象边界。
别把 internal 当成临时藏代码的地方
internal 一旦发布，就是模块内稳定的 ABI：改名、删函数、调整参数，都可能破坏同模块其他包的构建。它适合封装高频变动的中间件、适配层、私有工具，不适合放核心领域模型或长期稳定的组件。
典型反例：把订单状态机逻辑全塞进 internal/order/state，又导出 type StateMachine struct{} 和 func (s *StateMachine) Transition(...) —— 这等于把实现细节钉死在模块契约里。
最常被忽略的一点：internal 不解决“谁该用什么”问题，只解决“谁允许 import”。复杂业务中，真正的封装难点从来不在路径限制，而在接口粒度设计和依赖方向控制。
