Go函数最常踩的坑是值传递、作用域、defer执行时机和多返回值处理理解偏差：参数均为值传递（slice/map等含指针字段才显引用），短变量声明易遮蔽外层变量，defer参数在注册时即快照求值，多返回值须显式接收且error应居末位并妥善处理。
Go 函数最常踩的坑不是语法写错，而是对「值传递」「作用域」「defer 执行时机」和「多返回值处理」这四点理解偏差导致的隐性错误——它们不报编译错误，但运行结果总不对。
函数参数是值拷贝，修改 slice/map/channel 以外的类型不影响原值
Go 所有参数都是值传递。但 slice、map、channel、func、interface、指针这六类底层是引用语义（内部含指针字段），所以能“看起来”被修改；int、string、struct（不含上述字段）、array 等则是彻底拷贝。
-
string是只读字节序列，传入函数后哪怕转成[]byte修改，原string也不变 - 数组（如
[3]int）传参等于复制整个内存块，函数内改下标毫无意义 - 想让函数修改原始 struct，必须传指针：
func update(u *User)，而非func update(u User) - 切片虽是引用类型，但底层数组可能被扩容重分配，原切片长度/容量不变，这点常被忽略
短变量声明 := 在 if/for/block 内部会意外创建新变量
在代码块中用 := 声明同名变量，不会赋值给外层变量，而是遮蔽（shadow）它——这是编译器允许但逻辑致命的陷阱。
- 常见错误：在
if err != nil分支里写data, err := parse()，结果err变成新局部变量，外层err仍为nil，后续判断失效 - 修复方式统一用
=赋值，或确保所有分支都用:=并显式声明全部变量 - 可用
go vet -shadow检测这类问题，但不能依赖它覆盖所有嵌套场景
defer 的参数在 defer 语句执行时就求值，不是在函数返回时
defer 不是“延迟调用”，而是“延迟注册”，其参数在 defer 那行就固定了，后续变量变化不影响已注册的 defer 行为。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
i := 0; defer fmt.Println(i); i = 42→ 输出0，不是42 - 想捕获最终值，得用闭包：
defer func(v int) { fmt.Println(v) }(i) - 对文件/锁操作尤其危险：若先
defer f.Close()，再f, _ = os.Open(...)，实际 defer 的是nil指针，运行时 panic
忽略多返回值中的 error 导致程序静默失败
Go 强制你面对错误，但新手常靠 _ 忽略 error，或只检查 err != nil 却没处理具体错误类型。
-
t, _ := time.Parse(...)是典型反模式：解析失败时t是零值，后续逻辑可能基于错误时间继续执行 - 更隐蔽的是：
json.Unmarshal返回error，但若结构体字段未导出（小写开头），反序列化会静默跳过且不报错 - 正确做法：至少记录
err，关键路径上用errors.Is或errors.As区分临时错误与永久错误
这些坑大多发生在函数边界——参数怎么进、状态怎么出、错误怎么流、资源怎么收。越早意识到 Go 的“显式即安全”哲学，越少掉进看似合理实则错位的逻辑里。
