_不能真正忽略错误，因为错误值仍被计算、分配并影响执行路径，仅避免编译警告；应显式处理或至少记录日志。
为什么 _ 不能真正“忽略”错误
Go 里用 _ 接收函数返回的错误，只是让编译器不报“变量未使用”，错误值本身依然被计算、分配、逃逸——它没消失，只是你假装看不见。很多线上 panic 或静默失败，就源于这里。
常见错误现象：json.Unmarshal 解析失败但用了 _，后续代码按“解析成功”逻辑走，字段为空或零值，下游数据错乱却无日志；os.Open 打开不存在的文件失败，程序继续读 nil *os.File，直接 panic。
- 错误值仍参与执行路径：比如
io.Copy失败后返回err，若丢给_，调用方无法判断复制是否完成 - 调试困难：没有日志、没有堆栈、没有监控指标，问题只能靠现象倒推
- 静态检查工具（如
errcheck）会报出这类遗漏，但很多人直接禁用它
defer os.Remove 配合 _ 是典型误用场景
写临时文件后想自动清理，常看到这种写法：defer os.Remove(tmpPath)，然后对 os.Remove 的返回值用 _ 忽略。问题在于：删除失败（比如权限不足、文件正被占用）时，你完全不知道。
使用场景：测试生成临时目录、CLI 工具导出中间文件、HTTP handler 中写缓存文件后清理。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法是显式检查：
if err := os.Remove(tmpPath); err != nil { log.Printf("failed to remove %s: %v", tmpPath, err) } - 更稳妥的是用
os.RemoveAll（支持目录），并确保defer前文件已关闭（避免 Windows 下删除失败） - 若真要“尽力删”，也该记录 warn 级日志，而不是沉默
哪些情况可以安全用 _ 接错误
只有当错误**不可能发生**，或**发生也不影响后续行为**，且**有其他机制兜底**时，才考虑 _。这不是偷懒的借口，而是明确的契约。
典型例子：bytes.Buffer.Write 在内存充足时永不返回错误；fmt.Sprintf 格式串合法时不会出错；strconv.Itoa 对非负整数转换必成功。
-
buf := &bytes.Buffer{}; buf.WriteString("hello"); _ = buf.WriteByte('!')——WriteByte只在内存 OOM 时失败，而 Go runtime 此时已不可控 -
str := strconv.Itoa(123); _ = json.Unmarshal([]byte(str), &n)—— 错误？那说明str被篡改过，属于数据污染，本就不该继续 - 注意：
fmt.Fprintf(os.Stderr, ...)的错误仍建议检查——stderr 可能被重定向到满磁盘的文件
替代 _ 的更务实做法
多数时候，“忽略错误”的真实意图是“我不关心这个错误，但得让它可见”。与其用 _ 自欺，不如用最小成本暴露它。
性能影响几乎为零，但可维护性提升明显：日志、metrics、trace 都能串起来。
- 用
log.Printf("ignore err: %v", err)—— 至少留下痕迹，grep 可查 - 封装成函数：
func ignoreErr(err error) { if err != nil { log.Printf("[IGNORED] %v", err) } }，再ignoreErr(os.Remove(path)) - 在测试中用
require.NoError(t, err)或assert.NoError(t, err)，避免 CI 过了但逻辑有缺陷
真正难的不是写 _，而是判断“这个错误值我到底有没有能力处理、要不要通知别人、会不会滚雪球”。一旦开始问这些问题，_ 就自然退场了。
