结论：新手首选gonew，因其由Go官方维护、零依赖、仅做复制+路径替换；nunu适合需分层架构与Wire注入的企业级Web服务。
直接说结论：不用纠结选哪个，先用 gonew 跑通最简流程，再根据项目类型换更重的工具。
为什么 gonew 是新手第一选择
它不是功能最全的，但它是唯一一个由 Go 官方工具链维护、零依赖、只做一件事的模板工具：把一个已有模块复制过来，自动替换 go.mod 路径和包名。没有配置文件、不拉远程模板、不生成额外目录结构——就是干净的复制+文本替换。
- 常见错误现象：
go install golang.org/x/tools/cmd/gonew@latest后提示command not found: gonew→ 检查$GOBIN是否在$PATH中，国内用户建议用镜像：go install gitcode.com/gh_mirrors/too/tools/cmd/gonew@latest - 使用场景：想快速验证某个标准库示例（如
rsc.io/quote）、或基于自己维护的一个最小可运行模块（含go.mod和main.go）批量生成新项目 - 参数差异：
gonew srcmod dstmod dir中，dstmod必须是合法模块路径（如example.com/myapp），不能是相对路径；dir才是目标文件夹名
nunu 适合需要分层架构 + Wire 注入的 Web 服务
如果你的项目要跑 HTTP 服务、连数据库、带 JWT 鉴权、还要支持热重启，nunu 就比 gonew 实用得多。它默认集成 gin、gorm、wire、viper、zap，且目录结构明确区分 cmd、internal、config。
- 常见错误现象：
nunu new myapp报错failed to clone template→ 默认模板托管在 GitHub，国内网络不稳定，必须显式指定国内镜像：nunu new myapp -r https://gitee.com/go-nunu/nunu-layout-advanced.git - 使用场景：企业级 API 服务、需要长期维护的后台系统、团队希望统一依赖注入方式
- 性能影响：生成的项目自带
wire_gen.go，每次增删依赖都要重新运行wire，对小项目略重；但对中大型项目，它避免了手写初始化逻辑出错
别忽略本地模板的硬编码风险
很多工具（cookiecutter-golang、longclaw、甚至 nunu 的自定义模板）都支持从本地路径加载模板。但要注意：这些模板里的变量替换逻辑（如 {{.ProjectName}}）是工具私有的，不是通用语法。同一份模板文件，在 cookiecutter 里能用，在 longclaw 里可能完全不解析。
立即学习“go语言免费学习笔记（深入）”；
- 容易踩的坑：把别人公开的
cookiecutter模板直接丢给longclaw用 → 变量不会被替换，生成的go.mod还是原始路径 - 正确做法：确认模板文档是否标明“兼容 XXX 工具”；或者干脆自己写一个极简模板，只包含
go.mod、main.go、.gitignore三个文件，用gonew验证能否正常替换 - 兼容性影响：模板一旦写死某些路径（如硬编码
github.com/xxx/yyy），后续迁移到私有 Git 服务器时就得全局搜索替换，不如一开始就用工具变量控制
真正难的不是选工具，而是决定哪些东西该固化进模板、哪些该留给开发者手动填。比如日志轮转策略、DB 连接池大小、JWT 密钥来源——这些参数如果写死在模板里，后期改起来反而更麻烦。模板越轻，后期自由度越高。
