go变量声明性能无影响，但方式选择关乎可读性与维护性：局部变量优先用:=（类型推断、强制初始化、作用域明确），包级变量用var并显式写类型，避免混用，关键位置宁可冗余也要写死类型，变量名比声明方式更重要。
Go变量声明本身不耗性能，但选错方式会让代码读起来像解谜——尤其在多人协作或后期维护时。
用 := 声明局部变量是默认选择
函数内部绝大多数变量都该用 :=，不是因为它“短”，而是它把类型、初始化、作用域三件事一次说清。
- 编译器自动推断类型，避免手动写
int或string却和右边值不一致（比如var x int = 3.14直接报错） - 强制初始化，杜绝“声明后忘赋值”导致的零值误用（比如
var enabled bool默认是false，但你本意可能是true） - 无法在包级别使用，天然防止把本该局部的状态泄露成全局变量
- 注意：
a, b := 1, "hello"合法；但a := 1; a := 2报错——:=要求左侧至少一个新变量
用 var 显式声明包级变量和需零值初始化的场景
包级变量必须用 var，且显式写出类型是强烈建议的做法——它让其他文件/包能一眼看出这个变量的契约。
- 不写类型容易埋坑：比如
var port = 8080推断为int，但实际 HTTP 端口应是uint16；后续传参给http.ListenAndServe就得加类型转换 - 需要零值语义时才依赖
var的默认初始化：比如var mu sync.RWMutex，sync.RWMutex{}和零值等价，但写出来更直白 - 批量声明用因式分解写法，比单行堆砌更易维护：
var (
defaultTimeout = 30 * time.Second
maxRetries = 3
userAgent = "my-app/1.0"
)
避免混用声明方式造成语义断裂
同一逻辑块里突然从 := 切到 var，会让人怀疑这个变量是不是有特殊意图——比如是否要导出、是否会被跨 goroutine 修改、是否故意留空待后续赋值。
- 常见反模式：
name := "alice"; var age int; age = 25——age用var却立刻赋值，不如统一用age := 25 - 另一个反模式：
var config Config; config = loadConfig()—— 如果loadConfig()可能返回零值，那显式初始化反而掩盖问题；不如直接config := loadConfig()，让调用方自己判断有效性 - 真正需要分两步的场景极少，比如带副作用的初始化：
var db *sql.DB; db, _ = sql.Open(...); db.Ping()，这时保留var是合理信号
类型推断不是万能，关键位置宁可啰嗦也要写死
编译器推出来的类型有时不是你想要的——尤其是数字字面量和接口组合时。
-
x := 42是int，但在 32 位系统上可能和int64API 不兼容；明确写var x int64 = 42更安全 -
err := errors.New("fail")类型是error，没问题；但v := struct{ X int }{1}推出的是匿名结构体，无法作为参数传给期待具名类型的函数 - 当变量用于 channel、map、slice 初始化时，类型缺失会导致歧义：
m := map[string]int{"a": 1}没问题，但var m map[string]int; m = make(map[string]int)更清晰表明这是有意为之的空映射
最常被忽略的点：变量名本身才是可读性的第一道防线。再规范的声明方式，配上 v、tmp、data 这类名字，照样让人看不懂。声明方式只是骨架，名字才是血肉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
