Go 数据库持久层选型：是坚守老牌 GORM 还是拥抱类型安全黑马 sqlc？

各位 Gopher 们好呀！最近周末在折腾一个数据服务的重构，又一头撞进了 Go 持久层的世纪难题：到底选哪个？

一边是统治力依旧的老大哥 GORM（ https://github.com/go-gorm/gorm ），生态极全、Hooks 和关联加载很爽，但动辄 interface{} 和反射机制，字段写错全靠运行时甚至上线后排查，心里总有点发毛……

另一边是我最近在 GitHub 疯狂安利的工具 sqlc（ https://github.com/sqlc-dev/sqlc ）！拉了一下它这两年的 star 走势图，斜率真的非常夸张（现在已经狂飙到 13k+ 了 📈）。它的思路完全是反过来的：先写原生 SQL，然后根据 Schema 静态分析直接生成 100% 类型安全的 Go 代码。我自己复现跑了几个复杂查询，编译期直接报错拦截，零反射性能直接拉满，体验相当惊艳！

不过深入写业务时也遇到了坎：遇到字段巨多、条件组合复杂的动态查询（Dynamic SQL）时，sqlc 确实没有 GORM 的链式拼接那么顺手。

想来社区调研一下大家的真实选型：

1. 你们现在的线上生产环境更倾向于上哪一套？
2. 拥抱 sqlc 的朋友们，多条件的动态查询目前是怎么优雅处理的？（手写 COALESCE 还是混用 squirrel 这类 Query Builder？）

评论区求分享真实踩坑姿势，蹲一波大家的架构经验！👇