使用spf13/cobra而非手写flag，因其结构化命令树、自动注入--help/--version、透传PersistentFlags、RunE错误统一处理；交互菜单需可选触发、独立子命令封装、promptui显式Stdin；配置共享应通过PersistentPreRunE+Context传递；菜单跳转须用SetArgs+ExecuteContext避免os.Args污染。
为什么用 spf13/cobra 而不是手写 flag？
直接写 flag 处理多级子命令（比如 app user add、app config list）会迅速失控：参数绑定混乱、帮助文本要手动拼、子命令间共享配置难、自动补全和 Bash completion 几乎为零。而 cobra 是 Go 生态事实标准，它把命令树结构化，每个子命令是独立的 Command 实例，RunE 错误可直接返回，不用层层 os.Exit。
常见错误现象：手写 flag.Parse() 后发现 --help 逻辑要自己重写；多个子命令共用 flag 时，不小心在不同命令里重复定义同名 flag 导致 panic；想加个全局 --verbose 却得每个子命令都注册一遍。
-
cobra自动注入--help、--version，且支持嵌套 help（如app user --help） - 通过
rootCmd.PersistentFlags()添加的 flag 会向下透传到所有子命令 - 每个子命令的
RunE返回error，cobra自动打印并退出非零码，比log.Fatal更可控
如何让菜单式交互不破坏 CLI 的管道友好性？
CLI 工具的核心契约是：能被脚本调用、能接管道输入、能重定向输出。一旦引入交互式菜单（比如用 github.com/manifoldco/promptui 列出选项让用户按数字选择），就容易踩坑——程序卡在 stdin 等待输入，导致自动化场景失败。
正确做法是把交互作为“可选模式”，默认走非交互逻辑，仅当明确指定 --interactive 或无任何参数时才启动菜单。不要默认阻塞等待。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 检查
len(os.Args) == 1或cmd.Flags().Changed("interactive")再触发菜单渲染 - 菜单逻辑必须包裹在单独的子命令里（例如
app menu），而不是塞进rootCmd.RunE - 使用
promptui.Select时，设置Stdin: os.Stdin显式声明输入源，避免某些环境（如 CI）下静默 hang - 菜单选项应映射到已有子命令的调用逻辑，而非重复实现业务——点击“查看用户”就执行
user list的相同 handler
cobra 中怎么安全共享配置和状态？
菜单导航常需跨命令访问配置（如 API token、当前 profile 名）。若每个子命令都重新读配置文件或解析 flag，既慢又易不一致。但全局变量又难测试、难并发安全。
推荐方案：用 cobra.Command.PersistentPreRunE 在命令执行前统一加载，并把数据存入 cmd.Context()。这样既避免全局变量，又保证每次调用都有最新状态。
- 在
rootCmd.PersistentPreRunE里解析配置、校验 token、初始化 client，然后context.WithValue(cmd.Context(), key, value) - 子命令中用
cmd.Context().Value(key)取值，类型断言后使用 - 不要把 *http.Client 或数据库连接池塞进 Context——它们本身已线程安全，Context 更适合传请求级元数据（如
profileName、isDryRun） - 如果必须共享可变状态（如计数器），用
sync.Map或带锁 struct，别依赖 Context 传递指针
为什么菜单项跳转后要重置 os.Args？
当用户在菜单里选择“编辑配置”，你内部其实是调用 config edit 子命令。但如果直接调用 configCmd.Execute()，它会读取原始 os.Args（即 ["app", "menu"]），而不是 ["app", "config", "edit"]，导致 flag 解析失败或命令错乱。
根本原因是 cobra.Command.Execute() 默认只处理当前命令及其子命令，不模拟真实命令行调用链。临时方案是手动修改 os.Args，但更健壮的做法是用 cmd.SetArgs([]string{"config", "edit"}) + cmd.ExecuteContext()。
- 绝对不要直接改
os.Args[0]或os.Args = []string{...}—— 这会影响后续其他命令 - 对目标子命令调用
subCmd.SetArgs(args)，再用subCmd.ExecuteContext(ctx)执行 - 确保
subCmd已通过rootCmd.AddCommand(subCmd)注册过，否则ExecuteContext会报 “unknown command” - 若菜单跳转需传参（如选中用户 ID 后跳转
user show 123），把参数拼进SetArgs的 slice 里即可
菜单导航真正的复杂点不在 UI 渲染，而在命令上下文的隔离与复用——同一份代码既要响应脚本调用，又要支撑交互流程，边界稍不清晰就会污染状态或破坏管道语义。
