结构体传值还是传指针取决于真实字节大小（≤16字节倾向传值）、是否需修改原值、调用频次三个硬条件，而非字段个数；含slice/map/chan时即使小也建议传指针，因header拷贝易致语义混淆和意外共享。
int 和 int64 不是可互换的类型，选错会埋下跨平台隐患；string 和 []byte 的误用直接导致内存暴增；结构体传值还是传指针，不能只看字段个数——得看真实字节大小、是否修改、调用频次三个硬条件。
什么时候该用 int64 而不是 int？
别被本地开发环境骗了。int 在 64 位机器上是 8 字节，在 32 位 CI 环境（比如 ARM32 容器）里只有 4 字节，溢出可能只在上线后暴露。
- 时间戳、文件偏移量、大计数器 → 必须用
int64，不妥协 - 切片索引、循环变量、小范围计数（int 可用，但别把它赋给
int32变量，go vet会报截断警告 -
len()返回int，但若后续要存进数据库或序列化到 JSON，建议显式转成int64，避免平台差异
string 和 []byte 怎么选才不踩坑？
string 是只读 header（16 字节），[]byte 是可写 header（24 字节），但底层共用数组。误用会引发静默 bug 或额外拷贝。
- 需要修改内容（如协议解析、base64 decode、逐字节处理）→ 直接用
[]byte，配合预分配切片或bytes.Buffer - 只读场景（HTTP header、map key、日志输出）→ 用
string，零拷贝更高效 -
string(b)转换时，如果b后续还会被修改，必须先copy一份：string(append([]byte{}, b...))，否则 string 内容可能突变 - 反复拼接字符串 → 别用
+，改用strings.Builder或bytes.Buffer，string拼接一次就分配新底层数组
结构体传值 vs 传指针：三个判断条件缺一不可
不是“大就传指针”，而是看是否同时满足：需修改原值、真实体积超临界、调用频次高。用 unsafe.Sizeof 查真实大小，别数字段。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 必须传指针：
func (c *Config) Save()这类方法已绑定指针接收者，再传值会导致接口赋值失败 - 倾向传指针：结构体 >128 字节 + 高频调用（如 HTTP handler 中解析请求体）
- 倾向传值：≤16 字节（两个 machine word）+ 只读 + 生命周期短（如
type Point struct{X, Y int}） - 含
slice/map/chan的结构体，即使很小也建议传指针——值传只拷贝 header，但语义易混淆，且后续修改仍影响原数据
切片里存结构体值还是指针？性能差十几倍
实测一个 112 字节的结构体，append(s, MyStruct{}) 比 append(s, &MyStruct{}) 慢 14 倍。但性能不是唯一因素，语义更重要。
立即学习“go语言免费学习笔记（深入）”；
- 存值适合：
Point、RGBA这类 ≤16 字节、不共享、不跨 goroutine 的结构体 - 存指针适合：结构体 ≥64 字节、需长期存活、或多个函数间传递
- 副作用必须考虑：
s[0].Field = x在存指针时会改原始对象，存值则不会——这比纳秒级耗时更关键 - GC 压力：存大量指针会延长对象生命周期，尤其当切片长期持有时
struct{int8; [64]byte} 实际占 72 字节，而 struct{[64]byte; int8} 却是 128 字节——差出近一倍。别信字段加总，用 unsafe.Sizeof 或 go tool compile -S 看真相。 
