nunu 和 osbuilder 是当前最值得投入时间掌握的两个 CLI 工具：nunu 适合单体 Web 服务快速落地，osbuilder 适合多框架、多存储、多部署形态的工程化团队；前者通过固化 Wire、Zap、Viper、Gin 等组件协作逻辑实现开箱即用，后者通过模板参数化解决框架/存储/部署组合爆炸问题，并内置校验与环境适配能力。

nunu 和 osbuilder 是当前最值得投入时间掌握的两个 CLI 工具，前者适合单体 Web 服务快速落地，后者适合多框架、多存储、多部署形态的工程化团队。选对脚手架比写业务逻辑还关键。

为什么 nunu 适合新手起步和中小项目

它不是“另一个模板复制器”，而是把 Wire 依赖注入、Zap 日志、Viper 配置、Gin 路由这些组件的协作方式固化进生成逻辑里。

• 执行 nunu new myapp 后，你拿到的不是一个空目录，而是一个能立刻 nunu run 启动、支持热重载、自带 cmd/server/wire.go 和 internal/handler/user.go 占位符的可运行结构
• nunu create handler user 会同时在路由注册、Wire 注入链、测试文件中写入对应引用，不是简单字符串替换
• 日志初始化在 cmd/server/main.go 顶层完成，避免中间件里用未初始化的 logger 导致 panic
• nunu wire 内建校验：如果某个 service 依赖未声明的 interface，会直接报错，而不是生成编译不过的 wire_gen.go

为什么 osbuilder 解决的是框架/存储/部署组合爆炸问题

当你需要同时维护 Gin + PostgreSQL + Docker 和 Kratos + Redis + Kubernetes 两套服务时，手动维护模板成本指数级上升。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

• osbuilder -t web --web-framework gin --storage-type postgres --deployment-mode docker 会生成带 pgx 连接池、Dockerfile 多阶段构建、健康检查端点的完整代码，且所有路径和 import 路径都严格匹配 Go module 名
• Gin 的 engine.Run()、Kratos 的 app.Run()、go-zero 的 srv.Start() 全部封装在 cmd/app/server.go 的统一入口里
• 选 --storage-type etcd 就不会出现 MySQL 的 gorm.Open 调用，也不会漏掉 etcd client 的 context.WithTimeout 包裹
• Dockerfile 中的 ARG GOOS、K8s YAML 中的 resources.limits.memory 都是根据当前环境或配置文件动态注入，不是硬编码

别踩 cookiecutter-golang 的“轻量”陷阱

它确实安装快、模板自由，但正因太自由，容易陷入“自己修模板”的泥潭。

立即学习“go语言免费学习笔记（深入）”；

• 你 fork 了某个模板，加了 JWT 中间件，结果某天 go mod tidy 发现 github.com/golang-jwt/jwt/v5 和模板里写的 v4 冲突——这时你得手动改 templ
• 没有内建校验机制，Viper 初始化时机、Zap 输出格式、Wire 注入顺序全靠人肉维护，CI 环境里静默失败是常态
• 不处理跨框架一致性：比如 Gin 的中间件注册方式和 go-zero 的 middleware 接口签名完全不同，模板无法自动适配

真正麻烦的从来不是“怎么生成代码”，而是“生成的代码能不能在不同 Go 版本、不同 CI 环境、不同部署目标上稳定跑起来”。nunu 和 osbuilder 的核心价值，是把那些反复踩过的坑，提前封进生成逻辑里——你不用再为每个新项目重写一遍 main.go 的启动顺序、重调一遍 pgx 连接池的 MaxOpenConns、重查一遍 Nacos 地址是否带 /nacos 前缀。