在Go里面，想要让程序并发运行是一件很简单的事情，只要在func执行的时候，加上go关键字便实现了。
但同时又引入了另外一个问题，go执行我们捕获不到错误信息。

对于普通错误信息，我们可能只需要将其打到 log 日志，然后到日志收集系统去查询。

最近线上的mongo出现了连接数报警，登上去查看后，发现连接数上去之后一直没有降下来，而很多会话都处于「不活跃」状态。

最开始是想是不是因为程序已经重启了，产生了新连接，而mongo服务端一直保持着旧连接没有释放。但通过对比连接数上涨的时间，已经过去蛮久了，作为TCP连接，假设一方连接已经中断，mongo服务端这时候理应也要释放了。

在mongodb中，当业务希望按时间排序获取数据时，我们可能会直接采用 _id 来 sort ，因为我们知道默认 _id 的类型是ObjectID，它包含了时间戳信息，而且是有索引的。

最近一个情况却让我发现这样使用可能会出现意料之外的行为。表现就是：
两条新插入数据库的数据，在sort使用了{_id: -1}之后，慢插入的那条按理应该排在前面，然而它却排在后面。

这一篇，主要是想讲一下在实践项目中处理错误的一些方式与思考。
接口类型error是 Go 的内置类型，实现了方法Error() string的类型，都可以被当成error。

现在，我们已经知道如何定义error，如何产生error，以及如何对error进行处理，参考 错误处理（一）。
但是在真正的项目使用中，我们要如何组织错误，是 Gopher 一直探讨的话题。这里我会介绍我们在项目中的一些处理方式，以及如何组合这些错误处理方式，更优雅地组织代码。

在团队开发中，我们会要求每次提交项目代码都需要写注释，也就是commit message。
落实到实际运用上，就会发现，提交的注释五花八门，简短如“commit”，“fix bug”。当看完了注释，发现还是不知道这次提交究竟做了什么，还是得仔细查看代码变动才能得知。
更糟糕的是，有时候真的是出现bug了，又不确定是在哪次改动中碰到，只能在茫茫的git log中苦苦寻找。

五月的尾声，这个月有些许忙碌。这周主要是在调Gitlab的CI/CD，考虑替代Jenkins的可行性。
中途并没有那么顺利，也不是复杂度的问题，就是调试脚本这事情，总觉得不像debug程序那么顺畅，就类似搭建 Harbor 和简单的 K8S 集群，想一次点亮还真不容易，但是一旦你通过了一次，你发现第二次便无比顺利。

我总习惯于每过一段时间便思考审思（其实是焦虑），在每一次的焦虑出现，我都很渴望去做一些改变自我的事情。这段时间，这种感受不由又出现了，它很奇怪，既让我对前行的道路感到迷惘，却也让我重新沉下心来，回顾当下。

前些天看到段话，人们总是会对过去过度美化，同时对未来过于期待。
其实，当下更重要。

在之前的文章里，我们了解过 struct 与 interface。

通过结构体，我们可以将松散的数据字段组合成有意义的类型，同时它可以拥有自己的方法，让我们可以像面向对象的「类」一样去使用。

Go 语言没有类与继承的概念，但它提供的「接口」功能，也能让我们优雅地实现面向对象的特性。

在许多面向对象语言中，接口定义完之后，要实现一个接口，需要显示写明，比如Java使用implements关键字来实现接口。
而 Go 语言中的接口是隐式的，非侵入性实现，方便又灵活。

距离去年中的心血来潮的早睡早起行动，不知不觉已快一年。

很荣幸，这次没有做积极废人，成功地养成了习惯，现在基本上早上6点几起身，洗漱吃个早餐，为自己和家人做一份中午餐，这个时候大概也才到了八点出。

因为公司离家近（不到半个钟时间），所以距离上班时间（九点半）还早的很，我经常也就直接出发，前往公司。前段时间没有做饭，我经常到公司还不到八点，着实把上早班的同事吓一跳。