事情的起因是这样的。 一个方法要查询 N 次数据库，每一次查询都要 if err ， 我实在受不了啦，思索一番后觉得 似乎并不需要在运行时处理数据库操作的 error 。结论如下：
因为运行时的 error 大概率是连接，基建问题。 如果是 sql 语句问题，早就该在测试环节就发现。
既然是连接问题，那么一个查询报错，其它所有查询都会报错， 所以在每一个查询的地方都做 err check 是没有意义的。
可是不处理 err 怎么知道数据库有问题呢，怎么保证业务的完整呢？我大概理出了三板斧：

query 的操作不处理 err ，sql 问题留到测试期解决
update, insert 类操作要处理 err, 保证数据安全
对这些操作做一层包装和封装，每次调用记录 error ，监控该报警报警

当然，我不确定我这个想法是否考虑周到，可能以偏概全了。 欢迎大家一起讨论一下。

不要忽略任何错误.哪怕打个日志也好. 用上模板写个 if err 也就一秒. 万一出问题帮你节省的时间起码几小时.

之前写 gorm 的时候，无查询结果时也会有 err 不知道现在是什么样了

数据库查询错误，可能是数据库迁移没做好，这个测试环境可能无法复现（因为生产环境和测试环境很有可能用的不是同一个数据库，注意这里的错误不一定指的是某个表不存在，而是说可能出现一些异常数据导致查询错误）

必须要每个 error 都处理。我就说一个最简单的场景,一个请求进来，判断是不是合法用户(根据 token 查询数据库中是否存在)，如果不存在，则在爬虫表里记录该请求的信息。伪代码大概如下：var count int64err1 := dao.TestDb.Model(&dao.UserDao{}).Count(&count).Error//用户信息表里没有，则记录爬虫if count==0{err2:= dao.TestDb.Create(userDao)}如果一个合法用户的请求进来，因为网络抖动出错了，也会导致 count=0 并且 err1 不为空,你没有处理 err1,所以后面 insert 成功了(你无法猜测网络波动的时间，只能尽可能的去处理所有的 error)。

线上出现问题的时候，你就会后悔没有每个 err 都处理并打印日志了

写代码一时爽，查线上问题火葬场

goland 生产力搞起，输入err.rr按 tab见证奇迹

每个 err 都要处理，更何况设计到网络这种的

很多因素会导致数据库报错，cpu 、内存、磁盘、其它慢 sql 影响、db 的定时任务、机器老化等。甚至使用的 orm 库可能有 bug ，导致某些正常连接有问题。建议还是每个错误都捕获，写 err 麻烦的话，goland 敲 err 然后直接 tab 键就自动补全了。

在 copilot 的帮助下, 没有太大问题.考虑到费用问题, 也有很多免费的替代, 今天北大刚出了一款类似产品.

查线上问题的时候你把不得每行一条 log 。

能处理就处理，处理不了就抛出去，但是永远不要吞异常，

一楼说的没错，你起码要打个 log ，不然线上出问题，找到你这你说不清楚这锅就得你背

First Last 查询 API 为单条查询设计，查询不到时会 ErrRecordNotFound 错误，使用 Take API 查询单条时，查询不到不会报错。应该是使用 API 的问题

那可能是我对 Gorm 不熟悉的问题

没必要，err 该处理处理

还是打印日志为妙

有一些 fail fast 的文档，这会儿时间不多，可以 Google 「 program design check error rare panic OR fail 」

其实 postgres 已经把错误日志收集了

谢谢你对测试的信任

可以看下 Errors are values 这篇文章： go.dev/blog/errors-are-values

db 的 error 你都敢不处理，胆子好大啊，链式操作怎么办？前一步操作失败该回滚了你还继续么一个 crud 的接口，线上数据库字段变更没成功，查询操作失败了，抛个服务错误出来，你可以在网关加监控，捕捉到现在 error 不处理了，等着客户投诉你你才知道啊，这么任性的么

回滚？我目测 op 的数据库操作都没开启事物，回滚什么

对于数据库错误，我是直接 panic 出去了，事务内的会自动回滚，然后全局 recover 了特定于数据库的报错，提示给用户的就是数据库报错，日志里面记录了错误的详细信息

首先写结论：必须处理 if err 判断，其实就是一个熟悉的过程，搞熟悉了就不介意了。就像菇凉一样，开始丑点，看顺了就好。

是谁给了 op 这样的自信，哦，原来是因为懒和没经验，没被毒打过