GoNext Template
一个 AI-Friendly 的全栈项目脚手架，基于 Go + Next.js，强调约定优于配置、端到端类型安全和一键启动。
1. 项目定位
这个项目不是面向某个具体业务场景的产品，而是一个偏 工程化底座 的项目模板。
它的价值在于：当我要开始一个新项目时，不需要每次从 0 手搓目录结构、配置方式、开发命令、构建流程，而是可以基于一套更统一、更可维护的模板快速起步。
我会一直想做这类模板，是因为新项目启动时总会反复遇到同一批问题。我更想把下面这些事情提前固定下来：
- 如何把团队常用约定沉淀成模板
- 如何降低新项目启动成本
- 如何把开发、测试、构建、运行方式标准化
2. 解决的问题
在实际开发里，新项目启动时经常会遇到这些低效问题：
- 后端目录结构不统一
- 前后端联调方式临时拼凑
- 环境变量和本地启动命令不一致
- 缺少可复用的 Makefile / Docker / CI 配置
- 团队每个人都有自己的一套初始化方式
这个模板的目标，就是把这些分散问题提前收敛成一套可复用骨架。
3. 技术选型
后端
- Go
- Gin：Web 框架
- GORM：数据访问
- Wire：依赖注入
- Viper：配置管理
- Zap：结构化日志
前端
- Next.js 15
- TypeScript
- shadcn/ui
- Zustand
- TanStack Query
工程辅助
- Makefile：统一命令入口
- docker-compose.yml：本地编排
- OpenAPI：前后端共享契约
- GitHub Actions：CI/CD 预留位置
4. 项目结构设计
这个模板的目录设计本身，就是我最在意的部分之一：
text
api/ # OpenAPI 契约
backend/ # Go 服务
frontend/ # Next.js 前端
scripts/ # 自动化脚本
.github/ # CI/CD 流程
docker-compose.yml
Makefile
.env.example它传递的不是“目录长什么样”，而是：
- 接口契约被前置出来
- 后端结构被按职责拆分
- 前端和后端都能被统一管理
- 自动化命令有明确入口
5. 为什么我会一直想做这个模板
这个项目吸引我的地方，不是业务复杂度，而是它逼着我提前想清楚几件很基础、但总会在后面反复影响效率的事：
- 新项目怎样起步更顺
- 团队约定如何落到目录、命令和契约里
- “先把功能写出来”之后的交付和维护成本，能不能在一开始就被照顾到
所以我把它放在这里，不是为了证明什么，而是因为它确实代表了我做项目时的一种习惯：先把地基搭稳。
6. 这个模板和我关心的方向为什么很近
虽然它本身是应用模板，但它和平台工程并不冲突，反而关系很近：
标准化
模板本质上是在把常见工程约定平台化、标准化。
降低重复劳动
通过统一目录、命令和依赖关系，减少每个项目重复搭建底座的成本。
为自动化交付做准备
当项目结构和命令足够统一后，CI/CD、镜像构建、部署脚本就更容易标准化。
提升协作效率
团队成员面对相似的项目骨架时，上手成本更低，交接也更顺畅。
7. 我希望继续完善的方向
如果继续打磨这个项目，我会优先补这些内容：
- 标准化的 CI 流程说明
- Docker / Compose 启动说明
- 环境变量设计说明
- 新模块生成器如何工作
- 模板适合哪些业务场景，不适合哪些场景
- 如果未来迁移到 Kubernetes，需要如何调整交付路径
8. 这个项目里我最在意的几件事
- 工程化地基：关注项目骨架，而不是只盯着某一个业务功能
- 规范沉淀：把约定转成模板，减少每次都重来一遍
- 协作体验：让项目更容易启动、维护和交接
- 可复用资产：把常见能力从单次项目经验抽象成更长期的底座