@xabcstack 感觉好像不是？ m 的意思应该是千分之一，就像毫米毫秒里的 m 那样？

@Rwing 嗨，不存在，每个语言都有优秀的地方。

@Mitt 囧，我第二行写错了，:=应为=，我今天改下，谢谢提醒。
作用域应该是没变，上面这句我这么写编译不过去，因为:=左值没有新变量，伪代码大意了。

@ZSeptember 你说得对，我这篇文章对错误的识别处理说得太少了，标题有问题。感谢提醒。
pkg/errors 里有个 Cause()方法，在 Go 1.13 前用来做错误识别还是很趁手的。

裸返回和一般的返回是等效的，优势是可以少写一点东西。

劣势是有时确实容易写出 bug, 这时一般推荐用上包含 ineffetient assign 的静态分析 linter，可以避免翻车。

@zoharSoul 谢谢夸奖。Hugo 和 Zzo 主题，稍微自己改了一点点。

感谢各位的分享，综合意见，最后我使用了 Maven Shade Plugin，目前状态不错。

https://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html

也许可以考虑这样的实现方式，每一层调用者在发现调用的函数返回非空 nil 后，都使用 fmt.Errorf()提供上下文后再向 return 到上一层。

例如：

```
err := client.Ping(ctx).Err()
if err != nil {
err = fmt.Errorf("redis PING: %w", err)
return nil, err
}
```

这样到了最外层（一般是打日志的时候），文本化的 err 会形如：running up: program init: redis PING: network IO timeout

在大部分情况下，我自己感觉这个都比堆栈来得实用。

@index90 兄台说得对，这个方案不适合一个程序要启动多个 http 服务，只覆盖了部分用例。
感谢你的分享。

@FrankAdler 是呢，这样可以让 main()执行完，我们的思路挺类似呢。

@whitedroa 在另一个 goroutine 里做 ListenAndServe()，它的返回值一般是用 log.Fatal()来接的，要不然就不晓得 HTTP 服务启停状态了。
log.Fatal()调用的是 os.Exit()，这个方法会造成 go 程序直接退出，main()里的 defer 函数不运行（博文里链了 godoc 链接）。
当然也可以不用 log.Fatal()，自己搞定同步，但是那样复杂度上来了。

@v2Geeker 我是错了将近两年，涉及好几个服务，直到线上日志观察到了问题才醒悟的。

@SorcererXW 这里就见仁见智了，ListenAndServe()在 goroutine 中的话，错误处理大概率是 log.Fatal(err)这样的操作，如果服务并不是主动退出的（比如启动时立马遇到端口占用的错误），主函数 main()中的 defer 是不会执行的。我这里用了一些额外的复杂度让安全退出的逻辑更圆满了一些。

试试这个？
https://github.com/dsnet/termijack

@shadeofgod 方便分享品牌型号和典型价格吗？

感谢各位，综合各位意见，我使用了 POJO 里嵌入 fastjson 的 JSONObject，目前体验尚佳。

我一般写 Go，最近有些 Flink 需求学着写一些 Java，感觉是不是因为 Java 里不习惯把 struct(class)当成纯粹的数据载体？以及 Java 里定义 class 比较麻烦？

Go 里如果数据结构是确定好的话，一般是从 JSON 直接解析到 struct （对应 Java 的 POJO ），字段和类型都是固定的，而且 struct 定义比较方便，一般没有这个烦恼。

@aheadlead 感谢意见。那样就有点重了 XD

@chenset 见仁见智吧，我自己喜欢即用即走。