pterm不适合生产级CLI主UI框架，因其体积大、依赖多、非终端下panic、缺乏CLI基础能力；需用IsTerminal()判断输出环境，避免Spinner与LivePrinter混用，并统一使用pterm样式而非color包。
pterm 不适合做生产级 CLI 工具的主 UI 框架，它更适合快速原型、调试辅助或内部脚本的视觉增强。 它的动画、颜色、布局能力确实炫，但代价是体积大、依赖多、输出不可预测（比如在 CI 环境或重定向时崩溃），且不提供命令解析、子命令管理、参数校验等 CLI 基础能力。
为什么 pterm.Print() 在管道或 CI 中直接 panic
pterm 默认检测 os.Stdout 是否为终端（tty），一旦发现不是（如 ./tool | cat 或 GitHub Actions 的 run 步骤），就会调用 panic("not a terminal") —— 它不 fallback，也不静默降级。
- 临时解决：启动前加
PTERM_DISABLE_OUTPUT=true环境变量，所有输出被丢弃（适合 CI） - 更稳妥：用
pterm.IsTerminal()主动判断，分支处理：if pterm.IsTerminal() { pterm.DefaultHeader.WithBackgroundStyle(pterm.BgCyan).Println("START") } else { fmt.Println("[INFO] START") } - 注意：
pterm.EnableColor()也会在非终端下 panic，同样要包裹判断
Spinner 和 LivePrinter 混用导致输出错乱
pterm 的 pterm.Spinner 和 pterm.LivePrinter 都靠 ANSI 转义序列控制光标位置，但它们互不感知。如果一个 spinner 正在旋转，你又调用 livePrinter.Update()，两套光标移动指令会打架，结果就是文字堆叠、换行错位、甚至卡死。
- 原则：同一时间只启用一个“动态输出器”
- Spinner 适合短时任务（如 HTTP 请求等待），用
Start()+Stop()明确生命周期 - LivePrinter 适合长时流式输出（如日志 tail），必须用
Printer.Stop()手动结束，否则 goroutine 泄漏 - 若需“spinner + 进度文字”，改用
pterm.Progressbar，它内置同步机制
自定义主题后 color.New() 创建的样式失效
pterm 使用全局主题（pterm.ThemeDefault）控制大部分组件的颜色，但它**不接管** github.com/pterm/pterm/color 包里的 color.New() 实例。你调 color.New().WithBackground(color.BgRed).Sprint("x")，结果仍按终端默认色显示，因为 pterm 的主题没注入到这个底层 color 实例里。
- 正确做法：统一用 pterm 自带的样式构造器，例如
pterm.Style{Background: pterm.BgRed}.Sprint("x") - 或者，手动把主题色映射过去：
color.New(color.BgRed)→ 但得自己维护 RGB 值，不推荐 - 额外注意：
pterm.ThemeDefault.Success = pterm.Green这类赋值只影响pterm.Success.Print()，不影响你手写的fmt.Printf或第三方 color 库
真正难的不是让文字变彩色，而是让炫酷不破坏可维护性——比如把 pterm.Info.Println() 写满业务逻辑里，之后想关掉所有花哨输出，就得 grep 全局改几十处。更好的方式是封装一层自己的 UI 接口，背后根据环境变量切换 pterm 或纯 fmt 实现。
