Go函数多返回值必须全部接收或显式忽略，error须为最后返回值并立即检查，panic仅用于不可恢复异常，命名返回值需谨慎使用裸return。
Go函数多返回值必须全部接收或显式忽略
调用一个声明了多个返回值的函数时，Go编译器会强制你处理所有返回值——不能只取其中一个。比如 f2() 返回两个 string，写成 k := f2() 会直接报错：multiple-value f2() in single-value context。
正确做法只有三种：
- 全部接收：
k, v := f2() - 部分忽略：
greeting, _ := f2()（下划线占位符仅用于明确放弃某个值） - 全忽略：
_ = f2()或直接f2()（仅当函数无副作用且你真不需要任何返回值时才合理）
容易踩的坑是滥用 _：比如在 result, _ := divide(10, 0) 中忽略错误，会导致程序继续用无效的 result 做后续计算，而本该终止或重试。
error 必须作为最后一个返回值并立即检查
Go 的错误处理不是靠 try/catch，而是靠约定：error 类型必须放在返回列表末尾，且调用后几乎总要立刻判断是否为 nil。标准库所有 I/O、网络、文件操作函数都遵循这一规则，比如 os.ReadFile()、http.Get()。
立即学习“go语言免费学习笔记（深入）”；
典型写法是：
data, err := os.ReadFile("config.json")
if err != nil {
log.Fatal(err)
}
// 只有 err == nil 时，data 才可信
关键点：
- 不能跳过检查直接用前面的返回值，否则
err != nil时data是零值（如[]byte{}），极易引发静默逻辑错误 - 传播错误时用
return nil, err，不要吞掉或转成 panic（除非是真正不可恢复的编程错误） - 从 Go 1.13 起，优先用
fmt.Errorf("xxx: %w", err)包装错误，保留原始错误链，方便用errors.Is()或errors.As()判断
panic 不是错误处理机制，只用于真正异常的场景
panic 和 recover 不是替代 error 的方案，它们的定位完全不同：前者表示程序已无法继续正常运行（如空指针解引用、栈溢出、非法类型断言失败），后者只是提供一种“紧急逃生通道”，通常只在顶层 goroutine 或中间件中做兜底。
常见误用：
- 把可预期的业务错误（如用户输入格式不对、HTTP 404）用
panic抛出——这会让调用方失去控制权，且无法用errors.Is()判断 - 在普通函数里写
defer recover()拦截自己抛出的 panic——这掩盖了本该由上层决策的错误流，破坏了 error 的显式传递链 - 忘记
recover只对当前 goroutine 有效，无法跨 goroutine 捕获 panic
真正适合 panic 的例子极少：比如配置解析阶段发现必填字段缺失且无法默认，或类型断言失败后确认数据结构已损坏。
命名返回值和裸 return 容易让错误检查逻辑变模糊
当函数声明中给返回值起了名字（如 func divide(x, y float64) (result float64, err error)），就可以用裸 return 省略参数列表。这看似简洁，但会让错误检查路径变得不直观。
比如下面这段代码：
func parseConfig(s string) (cfg Config, err error) {
if s == "" {
err = errors.New("empty config")
return // 这里 cfg 是零值，但没显式写出，容易被忽略
}
cfg = Config{...}
return
}
问题在于：第一处 return 后，cfg 是未初始化的零值，但调用方看到的是 cfg, err := parseConfig("")，可能误以为 cfg 有内容。更安全的做法是显式写出返回值，或确保所有分支都明确赋值。
命名返回值真正的价值在于文档性和减少重复赋值，不是为了省略逻辑判断。一旦引入裸 return，就要格外注意每个分支是否都设置了全部命名变量——尤其是 err。
