Go 的 internal 包限制是编译期硬性规则：仅允许同一模块根路径下的包导入 /internal/ 路径；首字母小写标识符仅在同包内可见，跨包不可用；JSON 序列化、方法调用、接口实现及变量使用均严格依赖导出规则。
为什么 import "myapp/internal/utils" 在外部模块会报错
因为 Go 编译器在构建阶段硬编码了 internal 路径检查规则：只要导入路径里含 /internal/，就只允许**同一模块根路径下**的包导入它。不是约定，是编译期直接拒绝。
- 你执行
go build时，如果某个第三方包（比如github.com/other/project）写了import "myapp/internal/utils"，会立刻报错：use of internal package not allowed - 这个限制和
go.mod中定义的模块路径强绑定——假设go mod init example.com/myapp，那只有路径以example.com/myapp开头的包才被允许导入example.com/myapp/internal/utils -
internal不加密、不隐藏源码，别人照样能 clone 看；它只管“能不能 import”，不管“能不能读”
首字母小写函数为什么在其他文件里能调用，但在别的包里就不行
Go 的可见性只看标识符首字母，和文件位置完全无关。同一包内所有 .go 文件共享一个命名空间，小写函数天然可跨文件调用；但跨包时，没导出就是不可见。
- 你在
pkg/db/connect.go定义了func openDB() *sql.DB，又在pkg/db/init.go里直接调用openDB()—— ✅ 没问题，同包 - 但如果你在
cmd/server/main.go（属于main包）里 import"myapp/pkg/db"后试图调用db.openDB()—— ❌ 报错：cannot refer to unexported name db.openDB - 别指望靠“我都在一个目录下”蒙混过关：Go 不认目录层级，只认
package声明和首字母大小写
结构体字段导出失败导致 JSON 序列化为空的典型场景
字段名首字母小写 → 包外不可见 → encoding/json 库根本读不到它，序列化结果里直接消失，不是 bug，是设计如此。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 定义
type User struct { ID int; name string }，然后json.Marshal(User{ID: 1, name: "alice"})→ 输出{"ID":1}，name字段没了 - 修复方式只有改名：
Name string，或加 tag：name string `json:"name"`不起作用——tag 不绕过可见性检查 - 嵌套结构体也一样：
Config *config（小写类型）即使有json:"config"，外部也无法解包其内部字段
方法能被外部调用的前提：接收者类型 + 方法名都必须导出
光把方法名写成 GetID() 没用，如果接收者类型是小写的 user，那这方法对外就是黑盒，连签名都看不到。
-
func (u *user) GetID() int→ ❌ 外部无法调用，因为user类型未导出，*user实例根本构造不出来 -
func (u *User) GetID() int→ ✅ 只要User是大写类型，且方法名也是大写，就能跨包用 - 接口实现也受此约束：如果接口定义在包 A，你用包 B 的结构体去实现它，但实现的方法接收者是未导出类型，那 Go 就认为“这个结构体没实现该接口”
最常被忽略的一点：包级变量导出后，如果它指向未导出类型（比如 var DefaultClient = &httpClient{}），外部包拿到这个变量也没法用——不是值的问题，是类型本身不可见。得从类型定义开始导出，链条上不能断。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
