正确限速必须控制每次read/write调用的时机和大小，在read/write方法内调用rate.limiter.waitn(ctx, len(p))实现令牌桶限流，而非直接包装*os.file或使用io.limitreader；推荐固定4kb chunk size以平衡精度与开销。
限流对象不是字节流，而是 Read/Write 调用节奏
直接对 *os.File 套 rate.Limiter 没用——限流器管不了底层系统调用的缓冲行为。真正要控的是「每次 Read() 或 Write() 的时机和大小」。否则 io.Copy 仍会以默认 32KB 缓冲区疯狂刷盘，IOPS 瞬间拉满，fsync 积压、调度延迟、挤占其他进程 IO 都可能发生。
- 错误做法：
io.Copy(limitedReader, file)中的limitedReader若没实现Seek和Stat，HTTPRange请求会失败，浏览器报 “corrupted content” - 正确做法：封装
io.ReadSeeker或io.Writer，在Read(p []byte)/Write(p []byte)方法里先调limiter.WaitN(ctx, len(p))，再执行真实读写 - 别用
io.LimitReader替代限速——它只限总量（如最多读 1MB），不控速率；传io.LimitReader(f, 1024*1024)不是“每秒 1MB”，而是一次性放行最多 1MB 后就 EOF
读写 chunk 大小必须固定且提前可知
limiter.WaitN(ctx, n) 要求 n 是本次操作的准确字节数，不能是估算值或动态长度。流式场景（如 HTTP body 边读边写）必须统一 chunk 大小，否则令牌申请不准，要么欠配（阻塞过久）、要么超发（突破限速）。
- 推荐 chunkSize =
4 * 1024（4KB）：太小（如 1B）导致频繁调用WaitN，开销大；太大（如 1MB）则内存占用高、延迟不可控 - 读场景下，
buf := make([]byte, 4096)，每次Read(buf)后立即limiter.WaitN(ctx, 4096)（注意：即使实际读到n ，也按满 buffer 申请，避免后续调用因桶空被卡） - 写场景同理，
dst.Write(buf[:n])前必须limiter.WaitN(ctx, n)；若n == 0，跳过 Wait，否则会死锁
burst 参数至少等于 limit，且需预留抖动余量
rate.NewLimiter(rate.Limit(100*1024), 512*1024) 表示“每秒补 100KB 令牌，桶最大容量 512KB”。如果 burst 小于 limit（如 rate.NewLimiter(100*1024, 1024)），桶永远装不满，实际效果接近漏桶，突发请求极易被拒。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 生产建议：
burst ≥ rate × 2，比如目标 1MB/s，设burst = 2 * 1024 * 1024，应对 GC STW、网络抖动或内核调度延迟 -
burst = 0会 panic；burst = 1退化为严格匀速，无缓冲能力，用户连点两次就可能被拦 - 别写
rate.Every(time.Second/10)——编译器可能优化掉除法，显式写rate.Limit(10)
限流和持久化是两件事，别混在一起调
限速控制「写入节奏」，Sync() 或 O_SYNC 控制「落盘时机」。两者目标不同，参数和代价也完全不同。
- 如果业务强依赖不丢日志（如审计日志），即使已限速，也要定期调
dst.Sync()；但别每写一次就 Sync，性能极差 - 如果是临时缓存文件，可完全依赖 OS page cache，创建文件时去掉
os.O_SYNC，提升吞吐 - 不要因为开了限流就误以为数据已落盘——限流不改变 write() 系统调用的语义，只是让它更慢地发生
实际最难的不是写通逻辑，而是确保 ctx 来自请求生命周期、burst 经过压测验证、以及 ReadSeeker 的 Seek 和 Stat 方法返回值与原文件一致——这些地方出错，HTTP Range 和断点续传会静默失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
