如果是 Go 项目，没有 cgo 的情况下甚至可以二段 build ，第二段用 from scratch ，不用底包。
例子：

https://gist.github.com/nanmu42/90bf2d3870b64aec20b68ec3c104a610

@xabcstack 对于 CPU limit 是有个换算关系的，但是并不是 1mCPU = 1msCPU 时间，是 1000mCPU = 100ms CPU 时间 /100ms

@xabcstack 恐怕不对，文档里是这么说的：

> For CPU resource units, the expression 0.1 is equivalent to the expression 100m, which can be read as "one hundred millicpu". Some people say "one hundred millicores", and this is understood to mean the same thing.

https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu

另外 1000m = 1 CPU ，对应的是默认配置下 100ms 的 CPU 时间：

> The spec.containers[].resources.limits.cpu is converted to its millicore value and multiplied by 100.

https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#how-pods-with-resource-limits-are-run

@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，目前体验尚佳。