io.Discard 是 Go 中零开销的 io.Writer，Write 永远返回写入长度和 nil 错误，不保存、不系统调用；适用于需满足接口但忽略输出的场景，如测试、静默日志。
io.Discard 是什么，它真的“丢弃”数据吗？
io.Discard 是 Go 标准库中一个预定义的 io.Writer，它的 Write 方法永远返回 n = len(p) 和 nil 错误，不保存、不转发、不阻塞——只“假装写完”。它不是缓冲区，也不涉及系统调用，纯属零开销空操作。
常见误解是把它当成类似 /dev/null 的文件句柄，但其实它连 fd 都不打开。适合用在你明确不需要输出内容、又必须传入 io.Writer 接口的地方。
什么时候该用 io.Discard 而不是 os.DevNull？
两者都能“丢数据”，但行为和开销不同：
-
os.DevNull是一个真实文件路径（/dev/null或 Windows 上的NUL），每次Write都触发系统调用，有上下文切换成本 -
io.Discard完全在用户态，Write就是几条指令，适合高频写入场景（如测试中 mock 日志、压测时关闭 debug 输出） - 若代码逻辑里做了
os.Stat或依赖文件属性（比如判断是否可写），io.Discard会 panic（它不是*os.File），这时必须用os.DevNull
典型使用场景和写法示例
以下都是生产代码中真实出现过的模式：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 关闭 HTTP client 的日志输出：
http.DefaultTransport.(*http.Transport).Proxy = http.ProxyFromEnvironment不影响，但若你用了自定义RoundTripper并往log.SetOutput塞了东西，可设为log.SetOutput(io.Discard) - 测试中忽略命令输出：
cmd.Stdout, cmd.Stderr = io.Discard, io.Discard，比重定向到临时文件干净得多 - 解析 JSON 时跳过某个大字段：
json.NewDecoder(io.MultiReader(r, io.Discard))不对——这不行；正确做法是用json.RawMessage或自定义UnmarshalJSON，io.Discard在这里不适用 - 初始化 logger 时静默：
log.New(io.Discard, "", 0)，后续所有log.Print调用都不产生副作用
容易踩的坑：类型断言失败和 nil 检查误区
io.Discard 是一个变量，类型是 io.Writer，但它底层不是指针，不能做 *bytes.Buffer 那类断言：
var w io.Writer = io.Discard _, ok := w.(*bytes.Buffer) // false，panic if forced
也不要对它做 == nil 判断——它非 nil，且 io.Discard == io.Discard 是 true（因为它是包级变量）。更常见的错误是误以为它能“清空”已有 writer，比如：
-
io.Copy(io.Discard, r)✅ 正确：把r的内容读完丢掉 -
w = io.Discard; w.Write(buf)✅ 正确：写入被静默接受 -
fmt.Fprint(io.Discard, "hello")✅ 正确：格式化后丢弃 -
io.WriteString(io.Discard, "hello")✅ 同上 -
io.Copy(w, r)其中w是你自己的 struct 字段且未初始化 → 如果你忘了赋值，w是 nil，会 panic；别指望io.Discard能兜底
真正容易被忽略的是：它不提供任何同步保障，也不参与 io.MultiWriter 的错误聚合——只要有一个 writer 失败，MultiWriter 就返回错误，而 io.Discard 永远不失败，这点反而让它在组合场景中很可靠。
