go-flags仅解析命令行参数并映射为结构体，不监听stdin、不处理回车/历史/补全等交互行为；其ParseArgs返回后控制权交还用户，需自行集成bufio.Scanner、golang.org/x/term或bubbletea等库实现真正交互。
go-flags 本身不支持交互式输入（比如 readline 风格的逐行提示），它只负责解析命令行参数；想做“功能完整的命令行交互工具”，必须自己组合其他库，不能只靠 go-flags。
为什么 go-flags 解析完就结束了？
go-flags 的设计目标非常明确：把 os.Args 映射成 Go 结构体，验证必填项、类型、枚举范围等，然后返回。它不监听 stdin，不处理回车/上下键/历史记录，也不提供 prompt: 这类交互 API。
常见误解是以为加上 Usage 或 LongDescription 就算“交互”了——其实那只是帮助文本输出，程序执行完就退出。
- 如果你运行
./tool -h看到帮助，那是go-flags在起作用 - 但如果你希望运行
./tool setup后再问你 “数据库地址？”，这就得你自己写fmt.Scanln或集成lipgloss/bubbletea等库 -
go-flags的ParseArgs返回后，控制权完全交还给你，此时才该开始交互逻辑
如何把 go-flags 和交互逻辑安全串起来？
关键在于分阶段：先用 go-flags 锁定子命令和预设选项，再根据解析结果跳转到对应交互流程。避免在结构体字段上直接绑定用户实时输入（比如把 DBHost string `long:"host" description:"数据库地址"` 当作交互入口——这会让用户必须输在命令行里，失去“交互感”）。
- 为需要交互的子命令单独定义空结构体，仅用于触发逻辑分支，例如：
type SetupCmd struct{} - 在
SetupCmd.Execute方法里调用readString("数据库地址: ")这类自定义函数 - 用
parser.Command.LongDescription写清楚“该命令会引导你逐步配置”，而不是堆砌参数说明 - 注意信号处理：交互中用户按
Ctrl+C应该优雅退出，别让go-flags的 panic 捕获掩盖了你的os.Interrupt处理
哪些交互需求根本不能靠 go-flags 实现？
以下场景一旦出现，就必须引入额外依赖或手写逻辑，go-flags 无能为力：
- 带自动补全的输入（如输入
git chec<tab></tab>补成checkout）→ 需spf13/cobra+docker/cli风格补全器，或mattn/go-shellwords - 多步向导（步骤 A 完成后才问 B，且支持
←返回上一步）→ 得用状态机或charmbracelet/bubbletea - 隐藏密码输入（显示
******而非明文）→ 必须调用golang.org/x/term.ReadPassword - 动态选项列表（如“请选择环境：[dev, staging, prod]”，而 prod 是远程 API 拉取的）→
go-flags的Choice只支持编译期固定值
真正容易被忽略的是：很多人把参数解析和交互混在同一层结构体里，结果导致 help 输出混乱、默认值覆盖交互意图、甚至 --help 时意外触发了网络请求。交互逻辑永远要放在 Execute 方法体内，而不是靠 tag 驱动。
