必须用var而非:=的场景包括：包级变量声明、需延迟赋值、需显式指定类型（如int64）、批量声明及逻辑分组；:=仅限函数内且要求至少一个新变量。
Go 语言中不能用 var 声明“未使用”的变量，且 var 声明的变量默认初始化为零值——这不是缺陷，而是强制你面对状态初始态的设计选择。
什么时候必须用 var 而不是 :=
短变量声明 := 只能在函数内部使用，且要求左侧变量名全部为新声明；而 var 是唯一能在包级（全局）作用域声明变量的方式。
- 包级变量（如配置、计数器、单例）必须用
var，例如：var DefaultTimeout = 30 * time.Second
- 声明但暂不赋值（比如后续在
if分支中初始化），var可明确占位：var conn net.Conn<br>if useTLS {<br> conn = tls.Dial("tcp", addr, cfg)<br>} else {<br> conn = net.Dial("tcp", addr)<br>} - 需要显式指定类型（绕过类型推导），比如避免
int和int64混用引发的接口赋值失败：
var statusCode int64 = 404
var 的三种写法及适用场景
Go 支持三种 var 声明形式，差异在于是否显式写类型、是否批量、是否带初始值。
-
单行显式类型 + 初始值：
var name string = "Alice"—— 类型清晰，适合跨包暴露或需强调语义时 -
单行省略类型（靠值推导）：
var age = 28—— 推导为int，简洁但类型隐含，注意和int64等不兼容 -
批量声明（推荐用于相关变量）：
var (<br> buf bytes.Buffer<br> debug bool = true<br> maxRetries int = 3<br>)
—— 块内变量共享作用域，且支持混合写法（有初值/无初值/显式类型）
常见错误：重复声明、未使用、类型不匹配
编译器对 var 声明比对 := 更严格，尤其在函数内混用时容易踩坑。
-
“no new variables on left side of :=”：试图用
:=重新声明已由var定义的变量，例如：var x int<br>x := 42 // 错误！x 已存在
正确做法是直接赋值：x = 42 -
“declared and not used”：包级
var若未被引用，会编译失败（函数内局部变量同理）；调试时临时加var _ = x可绕过，但别提交 -
类型推导陷阱：写
var port = 8080得到int，但http.ListenAndServe需要string（端口是字符串）；应写var port = ":8080"或显式var port string = ":8080"
为什么不能只用 :=？性能和可读性代价
:= 看似方便，但在大型函数中会导致变量生命周期模糊、类型不透明、重构困难。而 var 显式控制变量“出生地”和“出身”，尤其利于静态分析工具识别作用域与逃逸行为。
- 函数参数传入后立即用
var提取并重命名，比链式:=更易读：var username = req.URL.Query().Get("u")比username := req.URL.Query().Get("u")在长函数中更醒目 -
var声明的变量若未取地址，更可能被分配到栈上；而过度依赖:=可能因闭包捕获或返回引用导致意外堆分配 - 团队协作中，
var块天然形成逻辑分组（如“输入”“中间态”“输出”），比散落各处的:=更易维护
真正难的不是语法，是判断变量该在哪一层作用域出现、该不该立刻初始化、要不要暴露类型——var 把这些决策摆到你面前，躲不开。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
