Cobra是Go CLI的事实标准，rootCmd.Execute()必须作为main()最后一行调用以驱动命令树加载；rootCmd须为包级变量且由cmd/root.go初始化；子命令需在Execute()前注册；flag作用域分Flags()（仅当前命令）和PersistentFlags()（透传所有子命令）；应统一用RunE替代Run并做panic兜底；配置优先级需配合Viper实现。
别再手写 flag 解析——Cobra 不是“可选”，而是 Go CLI 工具的事实标准。它解决的不是“能不能跑起来”，而是“要不要重复处理 help/version/子命令嵌套/多源配置合并”这些胶水逻辑。
rootCmd.Execute() 必须在 main() 最后一行调用
几乎所有“命令不存在”“子命令不生效”“--help 没反应”的问题，根源都是没真正触发命令树加载。Cobra 不靠 init() 自动注册，而是靠 rootCmd.Execute() 驱动整个解析流程。
- 确保
main.go最后一行是rootCmd.Execute()（不是ExecuteC()，除非你手动处理 error） -
rootCmd必须是包级变量，且由cmd/root.go初始化；不能定义在函数里再 return - 如果用
cobra.AddCommand()动态挂子命令，挂载动作必须发生在Execute()调用之前（比如放在init()或main()开头）
Flags 作用域搞错：PersistentFlags() vs Flags()
标志（flag）收不到？八成是作用域设错了。Cobra 的 flag 分两种作用域，混用就失效。
-
cmd.Flags()：只对当前命令生效。比如mytool server start --port 3000，--port应该在startCmd.Flags()里定义 -
cmd.PersistentFlags()：对该命令及其所有子命令都可见。比如mytool --config config.yaml server start，--config必须挂在rootCmd.PersistentFlags()上 - 验证方法：运行
mytool --help看 flag 是否列出；再运行mytool server --help，如果 flag 消失了，说明没设成 persistent
子命令 panic 导致静默退出，必须用 RunE 替代 Run
子命令里直接 panic（比如 flag 解析失败、读配置出错），程序会直接终止，不报错、不打印 stack trace，用户只看到“没反应”。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 统一把
Run改成RunE，返回error而非触发 panic - 在
RunE函数里加defer func() { if r := recover(); r != nil { cmd.Println("panic:", r) } }()做兜底 - 避免在
init()里做可能 panic 的事（如读文件、连接 DB），移到RunE中并显式 error 处理
交叉编译后 help 对齐错乱或中文显示异常
这不是 Cobra 的 bug，是 Go 标准库 text/tabwriter 在不同平台对 \t 和宽字符（如中文）的渲染不一致，尤其 Windows 编译 Linux 二进制时常见。
- 典型表现：
--help输出中选项列不对齐、中文后面多空格、短选项缩写（-h）显示不全 - 临时缓解：在
rootCmd初始化时加rootCmd.SilenceUsage = true关闭默认 usage 输出，改用自定义 help 模板 - 根本解法：避免在 help 文本里混用中英文 tab 对齐；用
cmd.SetHelpFunc()替换默认 help 渲染逻辑，绕过 tabwriter
最常被忽略的一点：Cobra 本身不处理配置优先级，它只负责把 flag 解析出来。真正要支持“命令行 > 环境变量 > 配置文件 > 默认值”这套链路，必须配合 Viper，并用 viper.BindPFlag() 显式绑定——否则你写的 flag 就只是个孤立参数，不是配置系统的一部分。
