直接写 _ = somefunc() 是危险的，因它主动放弃检查契约性 error，易致文件删除失败却继续执行、json 解析出错仍用脏数据、http 404 被当成功等严重问题。
为什么直接写 _ = someFunc() 是危险的
Go 里函数返回 error，不是可选提醒，是契约的一部分。忽略它不等于“没错误”，而是主动放弃检查——常见于 os.Remove()、json.Unmarshal() 或 http.Get() 后随手加个 _。结果往往是：文件删失败但程序继续跑，JSON 解析出错却用着脏数据，HTTP 请求 404 了还当成功处理。
真正的问题不在语法，而在语义：你得明确告诉自己和协作者——这个错误我**有意跳过**，且已评估过后果。
- 别用
_ = os.Remove("tmp.txt")，除非你知道文件不存在是预期状态，且后续逻辑完全不受影响 - 如果只是“懒得处理”，请至少写成
if err := os.Remove("tmp.txt"); err != nil { log.Printf("remove failed: %v", err) } - 某些标准库函数（如
fmt.Printf()）返回error主要用于底层 I/O 失败，实际中极少发生；这时可接受显式忽略，但必须加注释说明理由
哪些场景真能安全忽略 error
只有三类情况算合理忽略：I/O 写入到已知可靠的内存/缓冲区、日志记录本身失败、以及明确设计为“尽力而为”的清理操作（比如 defer 中的 Close()）。其他都该被质疑。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
log.Printf()返回error，但日志系统内部已做重试或降级，此时忽略可接受：_ = log.Printf("user %s logged in", userID) - 在
defer里关闭资源时，若父函数逻辑不依赖关闭是否成功，可用if cerr := f.Close(); cerr != nil { log.Printf("close failed: %v", cerr) }—— 不忽略，但不 panic -
bytes.Buffer.Write()几乎不会出错（除非Write实现被替换成异常版本），可忽略；但bufio.Writer.Write()可能因底层Write失败而返回 error，不能一概而论
用 _ 还是用 err 变量？关键看上下文
写 err := someFunc() 再扔掉，比直接 _ = someFunc() 更糟——它制造了变量污染，还让静态检查工具（如 errcheck）失效。但反过来，如果后续有多个可能出错的操作，统一用 err 变量反而更清晰。
- 单次调用且确认可忽略 → 用
_ = someFunc()，并紧跟一行注释：// ignore: file may not exist, cleanup is best-effort - 多个连续调用，其中部分可忽略 → 分开声明，避免复用
err：if err := f1(); err != nil { /* handle */ }; _ = f2() // best-effort - 用
errcheck工具扫描项目时，会把所有未检查的error标出来；别禁用它，而是逐个判断是否真该忽略
defer + Close() 的经典陷阱
很多人在 defer f.Close() 后就以为万事大吉，其实 Close() 自己就可能返回 error（比如写入缓冲区失败、网络连接提前断开）。而 defer 不捕获它的返回值，等于静默丢弃。
- 别写
defer f.Close()然后不管 —— 特别是写文件后需要确保落盘成功时 - 正确做法是显式调用并检查：
if err := f.Close(); err != nil { return fmt.Errorf("failed to close file: %w", err) } - 如果是在函数末尾的
defer，又想检查Close()错误，可以用命名返回值 + 延迟赋值技巧，但更推荐把Close()放到显式位置，而非依赖defer
很多开发者卡在“到底该不该管这个 error”上，其实就一条：只要错误发生会影响后续逻辑、数据一致性或可观测性，就不能忽略。 而判断依据不是函数名，是你的业务上下文。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
