go变量声明需按场景选择：包级变量、未赋值或需显式类型时用var；函数内简洁赋值用:=。字符串拼接小规模用+，动态多参数用fmt.sprintf，高频用strings.builder。切片cap影响append扩容，len决定下标访问边界。
Go 里变量声明不是“写法越多越好”，而是“用对场景才不踩坑”。
var 声明 vs := 短变量声明，什么时候必须用哪个
显式用 var 是为了类型明确、包级作用域或零值初始化；:= 只能在函数内用，且会自动推导类型——但推导结果可能不是你想要的。
- 包级变量（如配置、全局计数器）必须用
var，:=在函数外直接报错：syntax error: non-declaration statement outside function body - 想声明但暂不赋值（比如后面才从 channel 接收），只能用
var x int；:=要求右侧有值 -
var x = 42和x := 42看似一样，但前者类型是int（由字面量决定），后者在 32 位系统上可能是int32（取决于上下文），混用易引发接口实现或反射问题
字符串拼接用 + 还是 fmt.Sprintf？性能差多少
小规模、确定数量的拼接用 + 最快；动态、多参数、含格式化需求时才上 fmt.Sprintf——但它会分配新字符串并触发 GC。
- 两个字符串拼接：
s := a + b是零分配，编译器能优化成一次内存拷贝 - 三个及以上，尤其带变量：
fmt.Sprintf("%s-%d-%t", name, age, active)更可读，但比手写strings.Builder慢 3–5 倍 - 高频循环中拼接（如日志组装），务必用
strings.Builder：先var b strings.Builder，再b.WriteString()，最后b.String()
切片声明时 len 和 cap 不一致，实际影响在哪
len 是当前可用长度，cap 是底层数组剩余容量；二者不等时，append 是否扩容，取决于 cap 是否够用，而不是 len。
-
s := make([]int, 0, 10)：初始空，但预留了 10 个元素空间；连续append10 次都不会 realloc -
s := make([]int, 5, 10)：已有 5 个元素，还能追加 5 个不扩容；但s[5]会 panic：index out of range，因为len才是合法下标上限 - 误以为
cap越大越好？其实浪费内存；过小则频繁 realloc，每次复制旧数据，append平摊时间仍是 O(1)，但瞬时延迟明显
变量类型和生命周期绑定极紧，没“运行时改类型”这回事；一个 interface{} 装了 int，取出来还是 int，别指望它自动变成 float64——这是最容易在调试时愣住三秒的地方。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
