Go中struct字段首字母大写才可导出，影响跨包访问、JSON序列化、ORM映射等；初始化推荐字段名显式赋值；匿名字段需防名称冲突；传参依字段类型与语义选值或指针。
struct 字段首字母大小写决定是否可导出
Go 里结构体字段能不能被其他包访问，只看首字母：大写（如 Name）是导出字段，小写（如 age）是私有字段，连同包内都只能通过方法访问。这不是命名习惯问题，是编译器强制规则——字段小写后，JSON 解析、数据库映射、甚至 fmt.Printf 打印时都可能“看不见”它。
常见错误现象：json.Unmarshal 返回 nil 但结构体字段全是零值；gorm.Model 插入数据时字段没进数据库；用 reflect.ValueOf(s).NumField() 数出来字段数对，但 .Field(i).Interface() panic。
- 对外暴露的字段必须大写，哪怕只是想让 JSON 能序列化
- 想隐藏实现细节（比如缓存字段、内部状态），就用小写，并配套提供 getter 方法
- 别为了“看起来统一”把所有字段都大写——这等于主动放弃封装能力
初始化 struct 的三种写法及其语义差异
Go 不允许部分字段初始化（除非用字段名显式指定），但不同写法影响可读性、维护性和兼容性。
常见错误现象：新增字段后，原来用字面量初始化的代码直接编译失败；重构时把 type User struct{ Name string; Age int } 改成 type User struct{ Name string; Age int; Active bool }，结果一堆 User{"Alice", 25} 报错。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
User{Name: "Alice", Age: 25}—— 推荐。字段名明确，加字段不破环，适合多数场景 -
User{"Alice", 25}—— 仅限字段少、顺序稳定、且确定不会加字段的内部 DTO（比如测试用的 mock 数据） -
&User{Name: "Alice", Age: 25}—— 当你需要传指针（比如方法接收者是*User，或想原地修改）时才用，别为了“省一个 &”盲目取地址
嵌套 struct 和匿名字段的坑：别让字段名冲突静默覆盖
匿名字段（如 type Person struct{ User }）会把嵌入类型的导出字段“提升”到外层，但一旦多个匿名字段含同名字段，编译器报错；如果和外层字段重名，则外层字段优先，嵌入字段被遮蔽——而且不报错。
常见错误现象：结构体打印出来某个字段值不对；调用 user.Name 本意是想取嵌入的 User.Name，结果取到了自己定义的 Name 字段（值为空）；JSON 序列化时字段重复出现或丢失。
- 用匿名字段前，先检查嵌入类型所有导出字段名，确保不会和当前 struct 其他字段冲突
- 需要组合行为（比如
Logger、Validator）时，优先用命名字段 + 方法转发，而不是匿名字段 - 调试时用
fmt.Printf("%+v", s)看字段实际值，比靠名字猜更可靠
struct 作为函数参数：值传递 vs 指针传递的真实开销
struct 是值类型，传参默认复制整个结构体。但“多大才算大”没有固定阈值，得看字段数量、是否含 slice/map/chan/pointer——这些本身只占几个字节，真正数据在堆上。
常见错误现象：传一个含 10 个 string 字段的 struct，以为要避免指针，结果发现性能没差别；反过来，传一个只有两个 int 的 struct 却用了 *T，增加 nil 检查负担，还让调用方困惑。
- 字段 ≤ 4 个基础类型（
int/string/bool），直接传值更清晰、无 nil 风险 - 含 slice、map、interface{}、指针或 channel，无论字段多少，优先传指针——因为复制成本低，但语义上你本就想共享底层数据
- 不确定时，用
go tool compile -S yourfile.go看汇编，确认是否真在复制大量内存
字段名大小写、初始化方式、嵌套逻辑、传参选择——这四点串起来，才是 struct 在 Go 里真正落地的样子。改字段、加功能、调接口时，最容易漏掉的是字段可见性对序列化和 ORM 的隐性影响，不是语法错，是运行时才露馅。
