Go中标识符导出仅取决于首字母是否为Unicode大写，小写字段、函数、方法、接口及嵌套结构体内部未导出成员在包外均不可见，跨包调用报undefined错误常因未大写命名所致。
Go 里变量/函数首字母大写才可导出
Go 没有 public/private 关键字，导出与否只看标识符首字母是否为大写（Unicode 大写字母）。小写的 name、doSomething、errHandler 在包外完全不可见，哪怕加了注释或文档也没用。
- 导出的必须是首字母大写，比如
Name、DoWork、HTTPClient；XMLParser合法，xmlParser不合法 - 下划线开头（如
_helper）或全小写（如initDB）一律不导出，Go 编译器直接忽略其外部访问意图 - 结构体字段也遵循同一规则：
type User struct { Name string; age int }中，只有Name可被外部读写，age完全不可见 —— 即便反射也拿不到未导出字段的地址
跨包调用时“undefined”错误的真正原因
报错 undefined: xxx 很可能不是拼写错、没 import，而是标识符本身不可导出。Go 的 import 是静态链接式的，它只把导出符号拉进来，其余一概无视。
- 常见误操作：在
utils/包里写了func parseConfig() error，主包 import 后直接调utils.parseConfig()→ 报undefined: utils.parseConfig - 修复只需改名：
ParseConfig，然后go build就过 —— 不需要改 import 方式，也不需要加任何修饰符 - 注意大小写敏感还影响方法绑定：给
type Config struct{}实现func (c Config) save() error，这个save方法也无法被外部调用；得写成Save
嵌套结构体和接口的导出边界容易混淆
导出规则逐层生效，不是“包导出就全导出”。哪怕一个结构体是导出的，它内部嵌套的未导出字段、未导出方法接收者类型，依然对外不可见。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
type Response struct { Data map[string]interface{}; err error }——Data可访问，但err字段不存在于外部视角；更关键的是，interface{}里若含未导出类型（如utils.privateHelper），序列化或反射时会 panic - 接口定义必须导出，且所有方法名也要导出，否则实现该接口的类型无法被外部断言：
type Reader interface { Read() []byte }合法；但type reader interface { read() []byte }定义本身不可导出，外部根本看不到这个接口 - 别依赖 “导出结构体 + 匿名嵌入” 来间接暴露内部字段：嵌入
innerStruct（小写）不会让它的字段浮上来；只有嵌入InnerStruct（大写）且其字段本身也大写，才能穿透
测试文件里访问未导出成员的正确姿势
测试代码（xxx_test.go）和被测代码在同一个包内，所以能直接访问未导出标识符 —— 这是 Go 测试机制的设计前提，不是 bug。
立即学习“go语言免费学习笔记（深入）”；
- 同包测试可以直接调
parseConfig()、读defaultTimeout、甚至修改未导出字段（如u.age = 25），无需任何 hack - 但一旦写成
go test -run=TestXXX ./otherpkg跨包测试，就退回到常规可见性规则：只能碰大写符号 - 如果真需要在测试中验证未导出逻辑（比如内部状态机流转），优先考虑通过导出方法的副作用来观测，而不是强行导出内部字段 —— 否则等于把实现细节暴露出去，后续重构会受限
大小写规则看着简单，但嵌套结构、接口约束、测试边界这几个地方最容易掉坑里。尤其当多人协作时，有人习惯全小写加注释说明“这里可安全用”，结果别人 import 时卡半天，才发现是命名问题 —— 不是编译器不够智能，是 Go 明确把可见性决策权交给了命名本身。
