在 Go 中，如果限流请求不能简单地“现在允许”或“现在拒绝”，而是希望提前知道还要等多久，可以使用 golang.org/x/time/rate 的 Limiter.ReserveN。它返回一个预约对象，调用 DelayFrom 就能得到从指定时刻开始的等待时长。
官方文档：https://pkg.go.dev/golang.org/x/time/rate
需要注意的是，这个时长表示令牌桶为本次预约安排的等待，不是网络请求本身的耗时预测。预约一旦成功，就会影响后续令牌分配；如果最终不执行，应及时取消。
先理解 ReserveN 返回的预约
rate.Limiter 使用令牌桶模型：令牌按设定速率补充，burst 表示一次最多可以消费多少个令牌。ReserveN 不只是检查，它会为未来的 n 个事件安排位置，因此调用本身会改变限流器对后续调用的判断。
预约结果主要看两个字段：
OK()为true，表示在当前 burst 约束下可以安排这 n 个事件；OK()为false，通常表示 n 大于 burst，继续等待也无法满足这一批请求。
用 DelayFrom 预估请求等待时间
下面的示例把当前时间显式传给 ReserveN 和 DelayFrom。这样在需要记录预约时间、统一计算多个任务的排队时间时，时间基准更清楚。
package main
import (
"fmt"
"time"
"golang.org/x/time/rate"
)
func main() {
// 每 200 毫秒补充一个令牌，最多允许两个令牌形成突发。
limiter := rate.NewLimiter(rate.Every(200*time.Millisecond), 2)
reservedAt := time.Now()
// ReserveN 会为这次事件预约一个未来位置，并影响后续调用。
reservation := limiter.ReserveN(reservedAt, 1)
if !reservation.OK() {
// n 超过 burst 时，即使等待也无法满足，不能继续执行任务。
fmt.Println("本次请求超过 burst，无法预约")
return
}
// 从同一个时间基准读取等待时长，避免把计算基准混在一起。
delay := reservation.DelayFrom(reservedAt)
fmt.Printf("预计等待：%s\n", delay)
// 示例把等待后的动作写成占位调用；真实项目中这里应发起业务动作。
time.Sleep(delay)
fmt.Println("可以执行本次动作")
}
如果令牌桶此刻有空闲令牌，delay 可能接近零；如果前面已有预约，新的预约会排在它们之后。用 Delay() 也可以读取延迟，但 DelayFrom(t) 更适合在代码中固定计算时刻。
处理 burst 不足和预约取消
OK=false 不是“再睡一会儿就行”。例如 limiter 的 burst 为 2，却调用 ReserveN(now, 3)，这次预约没有可执行的未来时间，应当直接降级、拆分任务或返回错误。
另一种容易遗漏的情况是预约成功后，业务又决定不执行。预约已经占用了未来的令牌，如果直接丢掉对象，后续任务可能被不必要地推迟。此时可以调用 CancelAt：
func reserveOrSkip(limiter *rate.Limiter, n int, deadline time.Duration) bool {
// 固定预约时刻，便于把等待时间与本次判断绑定在一起。
reservedAt := time.Now()
reservation := limiter.ReserveN(reservedAt, n)
if !reservation.OK() {
// 请求量超过 burst，等待不会改变结果。
return false
}
delay := reservation.DelayFrom(reservedAt)
if delay > deadline {
// 业务不接受这么久的排队，取消未来预约以减少对后续任务的影响。
reservation.CancelAt(reservedAt)
return false
}
// 这里只演示“接受预约”；真正执行时还应使用可取消的等待机制。
return true
}
取消并不意味着可以无条件恢复所有令牌。限流器会根据预约时间和已经发生的后续事件计算可返还部分，因此应把 CancelAt 看作“尽可能撤销未来预约”，而不是手工修改令牌数量。
ReserveN、AllowN 和 WaitN 怎么选
| 方法 | 适合的业务语义 | 结果 |
|---|---|---|
AllowN | 超限就丢弃或稍后由上层重试 | 立即返回布尔值，不排队 |
ReserveN | 需要提前知道排队时长，或自行安排执行 | 返回预约，可读 Delay，可取消 |
WaitN | 愿意等待，但必须服从 Context 截止时间或取消 | 内部等待，成功或返回错误 |
官方文档建议大多数普通调用优先考虑 Wait；只有当业务确实需要“先看等待多久再决定”时，才使用 ReserveN。如果采用 ReserveN 后还要等待，最好用定时器配合 Context，而不是无条件 time.Sleep，这样请求取消时可以及时退出。
常见问题
ReserveN 能不能用来预测 HTTP 响应时间？
不能。它只反映令牌桶排队时间，DNS、连接建立、服务端处理和重试都会产生另外的耗时。
为什么 ReserveN 成功后下一次 AllowN 变成 false？
因为预约已经计入 limiter 的未来分配。预约不是只读查询，连续预约本来就会让后续请求排队。
什么时候应该直接用 WaitN？
当调用方不需要展示或比较等待时长，只需要在 Context 未取消且截止时间允许时等待一个令牌，WaitN 通常更直接。
总结
ReserveN 的核心是“预约未来令牌”，Reservation.DelayFrom 用来读取从指定时刻开始的等待时长，OK 用来识别超过 burst 的不可满足请求。接受预约后要么按时执行，要么在业务放弃时调用 CancelAt；如果不需要这层调度能力，使用 AllowN 或 WaitN 会更简单。
Go quotedprintable.Writer 怎样冲刷尾部并保留底层连接 
