YW9hbmdAeDJveC5jb20

```go

func handleSignal() {
c := make(chan os.Signal)
signal.Notify(c, syscall.SIGINT, syscall.SIGQUIT, syscall.SIGTERM)

go func() {
sig := <-c
log.Info("server exit signal", zap.Any("signal notify", sig))

cron.Stop()
server.Close()

log.Info("server exit", zap.Time("time", time.Now()))
os.Exit(0)
}()
}

```

加引用说明，且你项目也用 GPL

既然都觉得你菜了，先入为主，你何不顺着他的心意来。

当你写的代码他看不懂的时候，他就不会觉得你菜了

你这个不够零成本，告诉你一个思路。

Telegram Bot 的 API 接入可以用 Vercel 。
数据库用 Google Firebase 的数据库。
GitHub Action 做定时任务。

提一下 Golang 的依赖管理。

在过去，Golang 没有官方的 go mod，那时候依赖管理都是一塌糊涂，然后渐渐的出现了很多第三方包管理器，但是没有一个好用的。
除开包管理器，也有人做了版本管理来控制版本，以此来凑活，gopkg.in 因此诞生，用这个做版本管理的库还不少，比如 go yaml 等等。

go mod 出来之后，一切都变好了吗？然而并没有，只是大部分情况下变好了。
它对库的规范很严格，很多库因为之前没有版本管理，都使用的一些骚操作来实现版本管理。比如，用 v1 v2 这种目录的形式来管理版本。

一些库开启了 go mod 之后，各种历史遗留原因加上循环依赖，灾难就降临了

最典型的例子就是 etcd 了，etcd, grpc, viper 循环依赖…，碰到过的人，肯定都觉得坑爹

想解决这个问题，只能一个个 replace，但是后续升级依赖，可能就又会碰到这个问题了。

只要项目复杂，包管理器再好用…也会变得复杂，只能从源头上处理这个问题，不要随意使用第三方库，非要用的情况下，要进行多方面考虑。
比如，库的活跃程度，库是否引用了第三方库，库引用的第三方库是否引用了第三方库……

你应该看看 https

人的一生就是在不断的将未知变成已知

设计问题，真想知道最初的原因…可能只能问那群人了，不过还是可以猜一猜的。

PostgreSQL 诞生于实验室中，目的是为了研究数据库内核原理。使用 buffer io 能够减少 IO 栈的开发量，从而更加专注于数据库内核原理，所以 PostgreSQL 才会有相当丰富的 SQL 语法、执行算法和优秀的执行优化器等功能，当然还可以提一下优秀的扩展性。

另外，PostgreSQL 采用多进程的并发机制，多进程和多线程对内存的使用方式上存在区别也是一个原因，page cache 可以看做多进程之间的一种数据共享方式，在流复制中，通过 buffer io 从 page cache 读取 wal 可以减少物理读的频率

这不是 bot api，是 telegram api 。

https://core.telegram.org/api

@teawithlife #52

因为他代码中 errCh 和 done 作用是一样的，一个 chan 就可以了，检查 chan 中的内容是出错退出的还是最终完成退出就行了。

并发限制用协程池，退出机制需要自己实现。

如果懒得实现，就直接摘出来，用系统的实现。main 启动之后开一个协程监听退出信号，收到退出信号之后直接 os.Exit()

其实还是应该自己在代码中实现出来，那个操作只能玩玩。看看源码，用 runtime.Goexit() 来终止协程。

errgroup context 都是用来传递消息的，并不是来做终止的。你用这两个来做的话，只能每进行一步就检查一下是否有退出信号，不然就做不到及时退出。

ws 或者 http2，一般都是用 ws 保持兼容性。

看你服务端怎么写的吧。比如操作系统的启动时间，如果算上开机自检，那速度可以体会一下。

一般情况下，程序启动最主要的时间是花费在检查和初始化上面。比如检查数据库连接是否正常、初始化对象池等等。
但启动超过一分钟的，不说自己写出来的，用都没用过这种…

软件大就代表需要拆了，启动都那么慢了，debug 的时候一个 bug 改一天？
没有合理与不合理，只有能不能忍

试试 Bitwarden，可以导入

关于 map 中的 key 被删除之后 gc 的问题，不是特别好回答。印象中这个问题很早就有人在 github 提出 issues 过，刚刚找出来了。

https://github.com/golang/go/issues/20135

可以去看看进展

第二个问题，对于 channel 两个协程进行收发，你的短暂的阻塞的说法是错误的。

一个协程给 channel 发消息，一个协程从 channel 接收，要求是这两个协程都准备好，才能完成收发操作。

形象一点的例子就是，快递员给你送快递，你要去拿快递，通过沟通约定了时间地点，快递员得带着快递过去，你得过去拿，这样才能完成这个流程。

而对于有缓冲的 channel，是不需要收发同步的，但是队列满了之后就和无缓冲的一样了。

所以，同时收发会直接完成这一次消息传递。非同时收发，那么发送端会被阻塞，接收端也会被阻塞。

给我邮箱发一份