大家好，我是煎鱼。
之前在写 Go 代码时 IDE 经常会提示，团队内 CodeReview 也会遇到一些方法的返回值，处理不处理的问题。一开始大家还会讨论一下，久而久之基本也就麻木了。
假期时翻资料学习时，看到了 Go 社区这个相关的 issues#20803。之前已经有大佬提过类似的疑惑，Go 团队也进行了回复。
官方算是给了一个初步的定论，今天分享给大家。和煎鱼一起学习！
快速背景
现在我们写 Go 程序时，如果函数或方法同时返回了返回值和错误参数，用户（程序员）必须要做出一些处理。
最经常的返回 error 参数的场景。如下代码：
v, err := computeTheThing()或是明确的忽略他。如下代码：
v, _ := computeTheThing()相信大家都这么干过。（没错，经常翻代码看到...）
但是在很多有唯一返回值（例如：io.Closer.Close、proto.Unmarshal）的场景下，写习惯后，有的就顺手忽略了。
最常见的代码：
_ = json.Unmarshal(jsonBlob, &eddycjy)又或是：
defer fd.Close()看了直呼好家伙...业务代码写的久的同学应该知道不可信任原则。我是经常遇到有人这么写，结果没有记错误信息，查半天没查到哪里出问题的。
即使不是错误参数的处理。在其他 API 中也有类似的问题。
如下代码：
t := time.Now()
t.Add(10 * time.Second) // Should be t = t.Add(…)又或是：
strconv.AppendQuote(dst, "eddycjy") // Should be dst = strconv.AppendQuote(…)总而言之，提案作者 @Bryan C. Mills 认为 “忘记” 进行错误检查或丢弃赋值的后果可能相当严重。
可能会出现如下问题：存储到生产数据库中的数据被破坏、用户数据无法提交到存储中、因未验证用户输入而导致程序崩溃等问题。
期望的解决方案
提案作者 @Bryan C. Mills 给出思路：建议 Go 默认拒绝未使用的返回值。
配合的解决方式是增加 ignore 内置关键字或其他方式来忽略任意数量的返回值。
如下 ignore 代码：
go func() { ignore(fmt.Fprintln(os.Stderr, findTheBug())) }()或是以下变形：
go func() { ignore fmt.Fprintln(os.Stderr, findTheBug()) }()又或是使用别的方式：
go func() { _ fmt.Fprintln(os.Stderr, findTheBug()) }()简而言之，就是较为显式的指定来忽略。
其他语言是如何处理的
Swift 会对未使用的返回值发出警告，但如果设置了 @discardableResult 属性，则允许抑制该警告。
- 在 Swift 3 中进行修改之前，默认情况下可以忽略返回值（但可以使用 @warn_unused_result 添加警告）。
- Rust 有 [#[must_use]](https://doc.rust-lang.org/std/result/#results-must-be-used "#[must_use]") 属性。
- C++17 有 [[[nodiscard]]](https://en.cppreference.com/w/cpp/language/attributes "[[nodiscard]]") 属性，它将长期存在的
__attribute__((warn_unused_result))GNU 扩展标准化。 - ghc Haskell 编译器为未使用的结果提供了警告标志（-fwarn-unused-do-bind 和 -fwarn-wrong-do-bind）。
- OCaml 默认会对未使用的返回值发出警告。它在标准库中提供了一个 ignore 函数。
提案作者认为 OCaml（这是一个函数式、指令式、模块化、面向对象的通用的编程语言）提供 ignore 函数的方式与 Go 最为贴合。
因此他提出的提案和方向也与此语言保持基本一致。
核心团队回复
Go 核心团队成员之一的老大哥 @Ian Lance Taylor 和 Go 创始人 @
Rob Pike，直接发了张好人卡给提案作者。（尴尬了...）
翻译过来的关键意思是：“我很同情大家的担忧，但你这个解决方案不够好”。
反对的原因是：
- 降低代码可读性：我认为用 ignore 函数来包装表达式会掩盖代码的主要内容，从而增加代码的阅读难度。
- 这个例子不够好：在一门重视简洁性的语言中，用
_, _ =开头的典型例子 hello, world 在我看来是很不幸的。
结论是：“我同意这个问题，但不同意建议的解决方案”。（煎鱼注：高情商发言人？）
总结
通篇看下来，其实 Go 核心团队是较为认可这个问题的存在。但是既要也要还要的模式下，一时半会也找不到更好的解决思路。
同时许多社区内提出的解决思路都会一定程度的破坏 Go 现有的兼容性保障，让这件事变得前后都 “复杂” 了起来。
因此在后续中，Go 官方更推荐使用 vet 等 linter 工具检测来规避这个问题。
文章持续更新，可以微信搜【脑子进煎鱼了】阅读，本文 GitHub github.com/eddycjy/blog 已收录，学习 Go 语言可以看 Go 学习地图和路线，欢迎 Star 催更。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。