gin-ddd适合大型团队和复杂业务，强制四层架构、领域与基础设施分离；ginbro适合快速交付CRUD型服务，但耦合紧、扩展性弱。
选 ginbro 还是 gin-ddd？看团队规模和分层诉求
大型团队不是“越重越好”，而是要能收敛技术分歧、统一交付节奏。ginbro 适合快速交付 CRUD 型 API 服务，生成代码即用，但模型层和 handler 层耦合紧，后续加领域逻辑容易撕裂；gin-ddd 强制四层拆分（领域/应用/基础设施/接口），目录结构明确，domain.User 和 infrastructure.mysql.UserRepo 分开，适合多人并行开发不同模块。如果团队已有 DDD 经验或项目含复杂业务规则（如订单状态机、库存预占释放），直接上 gin-ddd；若当前以数据中台、管理后台为主，优先用 ginbro 省掉初期架构争论。
GOBIN 和 GOPATH 配置必须显式写进 shell 启动文件
很多团队成员执行 go install 后发现命令找不到，根本原因是 GOBIN 没进 $PATH。尤其在 CI/CD 流水线里，Docker 构建镜像时默认不加载用户 shell 配置，felix 或 gin 命令会报 command not found。解决方式不是临时 export，而是把这两行写死进 ~/.bashrc 或 ~/.zshrc：
export GOBIN=$HOME/go/bin export PATH=$PATH:$GOBIN
验证：新开终端执行 which felix 应返回路径；CI 脚本里也要先 source 对应配置文件再调用工具。
生成代码前必须确认数据库连接可通，且表名字段名符合 Go 命名习惯
ginbro 的 sql 参数直连数据库提取元信息，但遇到以下情况会静默失败或生成错误代码：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- MySQL 表名含下划线（如
user_profile）→ 生成的 struct 字段名是User_profile，不符合 Go 驼峰规范，后续json.Marshal无法导出 - PostgreSQL schema 不是
public→ 工具默认只扫public，其他 schema 的表直接忽略 - 字段类型为
JSON或ENUM→ ginbro 当前版本映射为string，没做类型增强，业务层需手动补Scan/Value方法
建议：生成前先用 mysql -u root -p -e "SELECT table_name, column_name, data_type FROM information_schema.columns WHERE table_schema='your_db';" 检查命名和类型，必要时加视图或改表结构。
编译产物体积大？别直接 go build，用 -ldflags 剥离调试信息
ginbro 或 gin-ddd 生成的项目默认依赖 logrus、viper、swag 等，go build 出来的二进制常超 20MB。线上部署时没必要保留 DWARF 符号表和调试信息。加这串参数能砍掉 30%~40% 体积：
go build -ldflags="-s -w" -o app ./cmd/app
其中 -s 去除符号表，-w 去除 DWARF 调试信息。注意：这样做后 delve 调试会失效，仅用于生产构建；CI 流水线里应区分 build-dev 和 build-prod 两个 target。
swagger.yaml 与 handler 实现的一致性，GORM 模型变更后是否强制跑 migration 脚本，这些细节比脚手架本身更影响长期协作效率。 
