每一个 go 库都是精品，组合到一块儿就这么恶心

[fxjson]

最近在学习使用 go  stars 比较多的库，比如 gin,gorm,go redis 等，单独用一个写段代码，感觉很舒服，挺爽，于是想把他们整合到一块儿，感觉很郁闷，数据库，redis 库底层 error 和业务空都归类为 error,我整合成一个业务框架以后写业务就很啰嗦了，要区分是业务 error 还是底层 error ，总不能把底层 error 抛出来前端显示吧，go 又不提倡 panic ，大家有木有用 go 写业务的，用啥框架，还是自己封装？发现 go zero 是个好东西，大部分代码都可脚手架生成

[lscho]

同感，说到底还是异常处理太恶心

[wangritian]

goframe ，大而全方向的，用自带 code 的 gerror 解决

[dacapoday]

1. gorm 不是精品，至少是鸡肋。无论其 api 风格还是库的实现，都能看出作者 与 go 本身的设计思想 以及其标准库实现 的对抗，但又不得不迁就的无奈(比如配置连接池，raw sql ，自定义 colum 类型的接口设计)
2. 既然是集成第三方库，必然需要封装，无论是出于统一业务逻辑(比如报错方式)，还是可维护性(仅就 go-redis 库，难道直接在业务代码里写 redis cmd ？为啥不封装一个面向业务的方法，将 key, ttl 等细节屏蔽)。
3. 如果是纯写业务，对性能，自定义底层行为，以及 第三方依赖管理 没有需求。应该是选择主流的框架或项目模版，按其文档进行开发。而非仅靠 stars 挑选第三方库并集成

[lvsshuttao]

目前使用的是 goframe (2.0) + xorm ，然后自己写的错误处理：1. 非业务代码产生的错误全部写入日志； 2. 业务代码根据需要写入日志（简单的参数错误不写日志）

之前尝试用 go zero 写项目，感觉太麻烦了，可能我这种简单的 CURD 项目不太适合

[janxin]

错误要做额外包装方便统一处理

[lookStupiToForce]

虽然语言不同，但处理这些非算法的工程事务的方法可以相通
推荐阅读一下这个文章（因为带过多地址会导致多扣铜币，地址经过 base64 编码）

Python 工匠： 异常处理的三个好习惯
aHR0cHM6Ly9naXRodWIuY29tL3BpZ2xlaS9vbmUtcHl0aG9uLWNyYWZ0c21hbi9ibG9iL21hc3Rlci96aF9DTi82LXRocmVlLXJpdHVhbHMtb2YtZXhjZXB0aW9ucy1oYW5kbGluZy5tZA==

顺带一提，这个文章出自这位 v 友 piglei ，你可以关注一下他
aHR0cHM6Ly93d3cudjJleC5jb20vbWVtYmVyL3BpZ2xlaQ==