nunu 和 osbuilder 是当前最值得投入时间掌握的两个 CLI 工具：nunu 适合单体 Web 服务快速落地，osbuilder 适合多框架、多存储、多部署形态的工程化团队。
选对脚手架比写业务逻辑还关键——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 - Wire 生成逻辑内建校验：如果某个 service 依赖未声明的 interface，
nunu wire会直接报错，而不是生成编译不过的wire_gen.go
osbuilder 解决的是框架/存储/部署组合爆炸问题
当你需要同时维护 Gin + PostgreSQL + Docker 和 Kratos + Redis + Kubernetes 两套服务时，手动维护模板成本指数级上升。osbuilder 把这种组合抽象成参数：比如 osbuilder -t web --web-framework gin --storage-type postgres --deployment-mode docker 会生成带 pgx 连接池、Dockerfile 多阶段构建、健康检查端点的完整代码，且所有路径和 import 路径都严格匹配 Go module 名。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 不同框架的启动模式被统一抽象：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 的“轻量”陷阱
它确实安装快、模板自由，但正因太自由，容易陷入“自己修模板”的泥潭。比如你 fork 了某个模板，加了 JWT 中间件，结果某天 go mod tidy 发现 github.com/golang-jwt/jwt/v5 和模板里写的 v4 冲突——这时你得手动改 template 中所有 import、type alias、error handling，而不是靠工具自动升级。
立即学习“go语言免费学习笔记（深入）”；
- 变量语法脆弱：
{{.ProjectName}}在文件名和内容里都生效，但一旦模板里混用{{.PackageName}}和{{.ProjectName}}，生成后可能 import 路径和实际目录名不一致 - 无依赖一致性保障：模板里写
zap.NewDevelopment()，但没声明go.uber.org/zap版本，新项目go mod init后可能拉到不兼容的 v1.26 - 扩展性假象：想加个 Prometheus metrics endpoint？得自己写模板片段、定义新变量、测试替换逻辑，而
nunu create或osbuilder直接提供--with-metrics开关
真正难的不是生成代码，而是让生成的代码能长期演进。nunu 的 wire 依赖图、osbuilder 的框架适配层，都在帮你把“改一处就要同步改五处”的耦合点提前收口。模板类工具省下的是 5 分钟，这两者省下的是后续三个月的重构时间。
