33｜固若金汤：限速器与错误处理

老师，为什么我按照代码写完后，请求数据还是有1s20条左右。可以帮忙判断我大概是什么地方写错了吗？

在程序中应该避免使用野生的goroutine带来的panic，可以放在一个有个异常捕获的Go函数中来执行goroutine。姿势如下： ``` func Go(f func()) { go func() { // defer recover 捕获panic defer func() { if err := recover(); err != nil { log.Printf("panic: %+v", err) } }() f() }() } func main() { f := func() { panic("xxx") } Go(f) time.Sleep(1 * time.Second) } ```

1 - 官方的 golang.org/x/time/rate 实现限流是通过记录最后操作的时间+计算完成的，感觉这种处理方式让人耳目一新。以前我一直觉得这种令牌限流的算法就是使用 ticker 定时向一个 chan 中放入令牌，然后让获取令牌的人阻塞然后自行争抢，计算的方式毫无疑问比 ticker 的方式更优。另外这种计算的实现让这个limiter 有了一个有趣的特点，就是当调用 Wait(ctx context.Context) 的时候，如果 ctx 设置了过期时间，limiter 可以立即计算出这个调用者是否有机会获取到令牌（如果下一个令牌生成时间是 3 秒后，而 ctx 的过期时间是 1 秒，limiter 会立即返回一个错误，表示这个调用者不可能在过期时间内获取令牌），这不会让调用者一直在 Wait 方法上阻塞，也算是提升性能的一个小技巧 2 - 课程中自行实现的多个级别的 limiter 感觉是有一个 bug？即如果设置了 5 个级别的 limiter，用户已经获得了前 3 个 limiter 的令牌，但是在尝试获取第 4 个令牌的时候出错，那是否应该将前三个令牌放回去？ 3 - error 推荐使用 github.com/pkg/errors 4 - 一个 goroutine 如果没有使用 defer + recover 的方式来捕获 panic，这个 goroutine 将导致整个程序直接崩溃，如果你不想这样，要记得添加 defer + recover

老师，appHandler 讲解那里，viewUsers还有下面那个方法是不是漏了error 返回