应优先用 spinner 处理不可预估耗时的任务，如数据库连接、api 请求；progressbar 适用于已知总量的场景，如文件下载，其 defaultbytes 自动解析 content-length 并计算速率。
用 spinner 做未知长度的等待动画，用 progressbar 做已知进度的数值反馈——两者定位不同，不能混用，但可以共存。
什么时候该用 spinner 而不是 progressbar
当任务总耗时或总量完全不可预估时，progressbar 的百分比逻辑会失效，强行传 -1 会退化为 spinner 模式，但此时你其实更需要的是语义明确、响应灵敏的等待指示器。
-
spinner.Start()启动后自动刷新，不依赖外部调用，适合数据库连接、API 请求等待等“卡点”场景 - 它默认不显示数字或百分比，避免误导用户（比如显示 “0%” 卡住 10 秒）
- 90 种内置样式中，
14（小球弹跳）、9（旋转齿轮）、32（呼吸灯）对人眼更友好，比默认0（点状循环）更易感知变化 - 注意：不要在
spinner运行期间手动调用fmt.Println或写入os.Stdout，否则会破坏动画位置；必须用spinner.Suffix = " 正在验证令牌..."这类字段追加文本
progressbar.DefaultBytes 为什么比 Default 更适合文件下载
因为 DefaultBytes 内部实现了 io.Writer 接口，并自动解析 Content-Length 和实时写入字节数，省去手动计数和单位换算。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 传入
resp.ContentLength是安全的，但若服务端没返回该 header（比如 chunked 编码），应改用progressbar.DefaultBytes(-1, "下载中")，它会切换为带速率估算的流式 spinner -
io.Copy(io.MultiWriter(f, bar), resp.Body)是关键：bar作为io.Writer接收每一批字节，同时触发重绘，无需额外 goroutine 控制 - 速率显示（如
1.2 MB/s）是自动计算的，基于最近 500ms 内写入字节数，不是平均速率，所以开头几秒可能不准 - 如果想禁用速率只留字节数，加选项
progressbar.OptionSetRenderBlankState(true)，否则空闲时仍会显示 “0 B/s”
progressbar.NewOptions 自定义主题时最容易错的三处
自定义主题看似只是填结构体字段，但顺序、字符集、ANSI 控制符三者稍有偏差，进度条就会乱码或静止。
-
Saucer和SaucerHead必须是单个 Unicode 字符或带 ANSI 颜色包裹的字符串（如"[red]█[reset]"），不能是多个字符拼接，否则宽度计算错误导致进度条错位 - 使用
[green]等颜色码前，必须启用progressbar.OptionEnableColorCodes(true)，否则原样输出方括号文本 -
BarStart/BarEnd如果用了 Unicode 字符（如"【"和"】"），需确认终端支持双宽字符，否则右侧会被截断；保守做法是用 ASCII："["和"]"
多 goroutine 更新进度时为什么有时卡在 99%
这不是渲染问题，而是 Add 方法的原子性边界被误用：它只保证单次加法线程安全，不保证多次加法的累计结果等于预期值。
- 例如 4 个 goroutine 各自执行
bar.Add(25)，理论上应到 100，但因竞争可能只加到 98 或 99（最后两次 Add 被调度到同一毫秒内，重绘未及时触发） - 正确做法是让一个 goroutine 专职监听 channel 中的进度事件，其他 worker 只发消息：
progressCh ，由监听者做 <code>bar.Add(n)并控制刷新频率 - 或者直接用
bar.Set64(int64(current))强制设值，但要注意current必须来自原子变量或 mutex 保护的变量，否则读到脏数据
真正难的不是让进度动起来，而是让动的节奏和用户心理预期对齐——比如下载大文件时，前 10% 花了 8 秒，后面 90% 只要 2 秒，那进度条匀速推进反而让人焦虑。这时候得用加权更新或分段回调，而不是依赖默认的线性映射。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
