iris 是 web 框架，不提供 cli 解析能力；它与 cobra 职责分离：cobra 管命令生命周期和配置注入，iris 专注 http 服务运行；二者应通过配置对象解耦集成，避免混用参数解析、共享错误处理与配置源。
Iris 本身是 Web 框架，不提供命令行解析能力；它和 Cobra 是两类工具：一个跑 HTTP 服务，一个管 CLI 交互。想用 Iris 写命令行工具，本质是「用 Iris 构建服务端逻辑，再用 Cobra 控制启动、配置、子命令等生命周期」——不是把 Iris 塞进命令行里，而是让命令行成为它的“操作面板”。
为什么不能直接用 Iris 处理 CLI 参数？
Iris 的核心是 iris.Application 实例，它绑定 http.Server、注册路由、中间件、模板等，所有入口都围绕 Listen / Serve 展开。它没有内置参数解析器，也不处理 os.Args。强行在 main() 里混写 flag 或 os.Args 会带来三个问题：
- 参数校验逻辑散落，和 Web 启动耦合，难测试
- 无法支持子命令（如
myapp serve --port=8080、myapp migrate up） - 环境切换（dev/staging/prod）、配置加载（Viper 集成）变得生硬
Cobra 初始化时如何避免 Iris 启动冲突？
关键点：不要在 cmd/root.go 的 Run 函数里直接调用 app.Listen()。要拆开「构建应用」和「运行服务」两步，确保配置已就绪、日志已初始化、依赖已注入。
- 把
iris.New()和路由注册封装进独立函数（比如newApp(cfg Config)），接收配置对象而非硬编码 - 在 Cobra 的
RunE中构造配置（从 flag、Viper、env 读取），再传给newApp - 显式控制
app.Listen()只在serve子命令中触发，其他命令（如version、health）只做轻量操作
示例片段（cmd/serve.go）：
var serveCmd = &cobra.Command{
Use: "serve",
Short: "Start the Iris web server",
RunE: func(cmd *cobra.Command, args []string) error {
cfg := loadConfig() // 从 Viper + flags 合并
app := newApp(cfg)
return app.Listen(cfg.Addr) // 不用 goroutine 包裹，让 Cobra 正确捕获 panic
},
}
怎么让 Cobra 的 flag 和 Iris 的配置真正联动？
常见错误是：Cobra 定义了 --port，但 Iris 还是从 os.Getenv("PORT") 读——两边没对齐。正确做法是统一由 Viper 管理，Cobra 只负责注入值。
- 在
initConfig()中调用viper.BindPFlag("server.port", rootCmd.Flags().Lookup("port")) -
Iris启动时读viper.GetString("server.port")，而不是自己解析 flag - 支持多源优先级：flag > env > config file > default（Viper 默认行为）
- 注意类型转换：Viper 返回
string，Iris.Listen()需要string，但若你用app.ConfigureHost(...)自定义 server，则需转int，用viper.GetInt("server.port")
启动失败时的错误输出容易被 Cobra 吞掉
Iris 启动失败（如端口被占、TLS 配置错）默认会 log.Fatal，而 Cobra 的 RunE 期望返回 error。直接 panic 会导致堆栈不完整、exit code 固定为 1、且无法自定义错误提示。
- 禁用
Iris的自动 fatal：创建app时传入iris.WithoutServerError(iris.ErrServerClosed)等选项，但更重要的是捕获app.Listen()的 error - 显式判断并包装错误：
if err != nil { return fmt.Errorf("failed to start server on %s: %w", cfg.Addr, err) } - 避免在
RunE外部调用log.Fatal，否则 Cobra 无法格式化错误、加前缀或控制输出方式
Cobra 和 Iris 的集成边界其实很清晰：Cobra 是“指挥官”，决定做什么、用什么配置；Iris 是“执行者”，专注 HTTP 流量处理。最容易被忽略的是错误传播路径和配置所有权——一旦让两者各自维护一套配置或各自 panic，调试成本会指数上升。
