Web服务与CLI命令必须分离启动：Web用gin.New()+r.Run()阻塞监听，CLI用cobra或flag解析后立即执行；共享逻辑应抽为纯函数，避免共用gin.Context；信号处理需隔离，CLI禁用Gin信号监听。
不能直接用 gin.Default() 启动 Web 服务再混着跑命令行逻辑——两者生命周期、错误处理、退出机制完全不同，强行共存会导致信号处理错乱、资源泄漏或 panic 无法捕获。
gin.WebServer 和 CLI 命令必须分离启动流程
Web 服务靠 r.Run() 阻塞监听，CLI 命令靠 flag 或 spf13/cobra 解析后立即执行并退出。混在一起会卡死 CLI，或让 Web 服务在命令执行完后意外退出。
- Web 启动路径：只走
gin.New()+ 路由注册 +r.Run("addr")，且应放在main()最后一行（或单独 goroutine 中，但需加 sync.WaitGroup 控制） - CLI 启动路径：用
cobra.Command.Execute()或原生flag.Parse()，解析完立刻执行业务逻辑，不调用任何r.Run() - 共享代码可抽成包（如
pkg/db、pkg/config），但启动入口必须物理隔离
如何复用 Gin 的路由和中间件逻辑给 CLI 调用
Gin 的 *gin.Engine 本质是 HTTP handler，不能直接喂给 CLI；但路由定义、参数绑定、JSON 解析等能力可以剥离复用。
-
c.Param()、c.Query()、c.ShouldBindJSON()这些方法依赖*gin.Context，而 CLI 没有请求上下文——得手动构造测试用的*gin.Context，但不推荐（易破环中间件行为） - 正确做法：把业务逻辑从 handler 函数里拆出来，变成纯函数或 service 方法，例如：
func CreateUser(ctx context.Context, req CreateUserReq) error - Web handler 只负责解析输入、调用 service、写响应；CLI command 直接调用同一 service，传入本地构造的参数
信号处理冲突：Web 服务监听 SIGINT/SIGTERM，CLI 也需要退出控制
默认 r.Run() 会注册 os.Interrupt 和 syscall.SIGTERM，如果 CLI 命令也用相同信号做清理，可能被 Web 的 signal handler 提前截断。
立即学习“go语言免费学习笔记（深入）”；
- CLI 场景下禁用 Gin 的信号监听：改用
r.RunWithoutSignals("addr") - Web 服务若需优雅关闭，应自己用
http.Server封装 +signal.Notify，而不是依赖r.Run()的黑盒行为 - CLI 命令若需模拟请求（如调试接口），用
http.DefaultClient.Do()调真实 endpoint，别试图“绕过 Gin 启动”去触发 handler
配置加载和初始化顺序容易踩坑
Web 和 CLI 共享配置（如数据库地址、JWT 密钥），但初始化时机不同：CLI 可能只需连 DB 执行迁移，Web 则需完整中间件链就绪。
- 避免在
init()里做重操作（如连 DB、读文件），它会在所有包导入时执行，CLI 和 Web 都会触发 - 推荐用 lazy init：定义
var db *gorm.DB全局变量，首次调用getDB()时才初始化 - CLI 命令入口函数里显式调用
loadConfig()+initDB()；Web 入口同样调用，但顺序要确保中间件注册前完成
真正难的是初始化依赖图——比如某个中间件依赖 DB 实例，而 DB 初始化又依赖 CLI 传入的 migrate 标志。这种交叉依赖没法靠框架自动解，得靠你手动拆清边界、加 guard 条件、或者干脆拆成两个二进制（myapp-web 和 myapp-cli）。
