根本原因是阻塞主goroutine，未调用app.Run()或在Run()外执行同步耗时操作；UI更新必须通过app.QueueUpdateDraw()在主线程触发，音频处理需放独立goroutine，进度条用ticker定时更新并基于真实播放时长计算。
为什么 tview.NewApplication() 启动后界面卡死不动
根本原因通常是阻塞了主 goroutine，没调用 app.Run()，或者在 Run() 之外写了同步耗时逻辑（比如直接读取音频文件、解码、sleep 等）。tview 是事件驱动的，所有 UI 更新必须在主线程（即 app.Run() 的 goroutine）中发生。
- 确保只在
app.Run()前设置好初始页面，之后所有交互响应（播放/暂停/进度跳转）都通过app.QueueUpdateDraw()触发 UI 变更 - 音频解码、采样率转换、缓冲读取等操作必须放在独立 goroutine 中，结果通过 channel 或闭包回调通知 UI
- 别在
SetChangedFunc或按键处理里做time.Sleep()—— 这会直接冻结整个界面
怎么让进度条实时更新且不抖动
tview.NewSlider() 本身不主动刷新，它只响应用户拖拽；要实现“播放中自动滑动”，得自己驱动更新节奏，并注意帧率和精度取舍。
- 用
time.Ticker（比如 200ms 间隔）触发app.QueueUpdateDraw()，在回调里调用slider.SetCurrentPercent() - 不要每 10ms 更新一次：tview 渲染有开销，高频重绘反而卡顿，且终端刷新率有限
- 百分比计算务必基于音频真实已播放时长 / 总时长，而不是靠 ticker 累加 —— 解码延迟、IO 暂停都会导致 drift
- 如果音频库（如
oto或ebiten/audio）提供当前播放帧数接口，优先用它算位置，比纯计时可靠
按键绑定后按了没反应？检查这三处
tview 的键盘事件不是全局捕获，而是绑定到具体 primitive（比如 Flex、TextView），且焦点状态决定谁响应。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 确保目标 primitive 调用了
.SetInputCapture()，或整个页面被设为可聚焦（.SetFocusable(true)） - 确认 app 当前焦点在你期望的控件上 —— 按
Tab切换焦点试试，或者启动时显式调用app.SetFocus(yourPrimitive) - 某些终端（尤其是 Windows 的默认控制台）会拦截
Ctrl+C、Ctrl+Z等组合键，改用j/k、l、h或功能键更稳妥
退出时音频还在后台跑？资源没清理干净
tview 不管音频设备、decoder 实例或 goroutine 生命周期，这些全得手动关。
立即学习“go语言免费学习笔记（深入）”；
- 在
app.SetRoot().SetDoneFunc()或os.Interrupt信号处理里，先停止播放器（调player.Pause()或player.Close()），再关闭音频上下文（如context.Cancel()） - 所有长期运行的 goroutine 必须监听
context.Context的Done()，收到信号后退出循环并释放 buffer、close channel - 别依赖
defer关音频设备 —— 主 goroutine 退出时其他 goroutine 可能还在跑，defer 只在当前函数返回时执行
最常被忽略的是：以为 app.Stop() 会等所有 goroutine 结束，其实它只停止 UI 循环，其余全靠你自己收尾。
