gorm 官方现在专门把《the generics way to use gorm》泛型用法内容单独拆成了独立文档，明确说明泛型特性从 v1.30.0 版本开始正式可用。官方给出的核心逻辑很直白：这套泛型接口不仅能提升类型安全性，还能避免复用 gorm.db 实例时可能引发的 sql 污染问题，同时完全兼容旧版 api 和现有插件体系。
来源：GORM 官方文档
这篇文档传递的信号远不止“GORM 适配了 Go 泛型”这么简单，官方已经把泛型调用路线定为新写代码的默认推荐方案。文档里不仅给出了 Create、Find、Update、Delete 这些常用操作的泛型写法，还特意说明新旧 API 可以混合使用，之前已经接入的加解密、分库分表、读写分离、链路追踪这类现有插件完全不用重构。说白了 GORM 也没要求大家把老代码全量重写，只是建议新开发的模块、正在重构的模块，优先切换到这套更稳妥的调用模式上。
文档里还特意提了一个很值得注意的边界：泛型版本直接去掉了 FirstOrCreate、Save 这类本身容易出歧义、引发并发问题的接口，同时还顺手优化了 Joins、Preload 和事务超时的相关逻辑。这说明官方根本没把泛型做成一个额外的语法糖层，反而借着这次迭代，把之前历史上最容易被开发者误用的入口全给收严了。对于维护大型服务的团队来说，这类规范收口比多几个便捷方法重要得多，直接决定了整个代码库后续的可维护性。
来源：GORM 官方文档
文档末尾还提到，GORM 团队正在开发全新的 CLI 工具，后续会进一步强化代码生成、类型安全和代码 lint 的相关能力。把这个规划和前面的 API 调整结合起来看，GORM 后续的发展方向已经非常明确：它不只是想做一个能生成 SQL 的 ORM，而是要把查询、关联、插件调用的全流程，都约束到更容易做静态检查、适配团队开发规范的框架里。打算长期维护 Go 数据访问层的项目，这点比追着看单个版本的更新日志要重要得多。
最后要提醒：所有这类更新的判定标准，都要以 GORM 官方文档当前公开页面写明的版本号、修复项、支持范围和限制条件为准。官方白纸黑字确认的内容，可以直接加到团队的升级清单里，那些页面上没明确承诺的能力、兼容结论或者默认行为，建议先做灰度验证，没问题了再纳入团队的通用开发基线。
