有报道指出，这是一个系列 Blog，作者将以一个 PHP 全栈工程师的身份，利用 AI 工具（claude code、codex、deepseek、豆包等）：从零开端学习 golang 语言，并最终完成 ai-go-admin（github | gitee）开源项目的制作（感谢 star ~），全程记录分享。 科技新闻。
还是上面的模型定义，使用 Joins 预加载是这样写的：
以上提示词说的比较笼统，甚至使用什么关联模式都是让 AI 提供方案，在它分析的时候，这里我也是赶紧打开 GORM 的学习笔记，查看一下各种关联方式的预加载写法。
从P背景与起因
问题在于，服务端在何处应用这些筛选数据，首先肯定是考虑使用 Preload(association string, query func(db gorm.PreloadBuilder) 的第二个闭包函数，但这个理解是错误的：
这里是 AI 模仿的 ActionFields，给 Get、List、Update、Create 各提供了一个定义 Preload 的位置，其中在 Update、Create 中这东西基本没用，直接去掉，List 几乎是主要使用方，Get 使用频率低且就算额外查了 List 的 Preload 也没关系。
我们要的筛选语义显然是：只返回 group.name 匹配的 Admin 的行。这需要主查询过滤，Preload 帮不上。
从P事件经过
唯一干净的方式：子查询，顺着关联链层层套 EXISTS/IN 子查询即可。
目前系统内，还没有一处使用了关联表，这里就以 管理员 和 角色组 来跑路关联的流程，先直接让 AI 提供建议，切换为 plan 模式：接下来需要完成 Admin 和 AdminGroupAccess 模型的关联，它们定义于 @internal/model/admin.go，用什么方式关联比较好？同时，我需要为基类增加快速配置关联的功能，在什么区域配置，配置名叫什么比较好？
在上一期，我们进行了 “增加管理员角色组管理”，本期将完成：管理员和角色组的关联
从P各方回应
Joins 预加载的性能无疑是最好的，因为它在 单条 SQL 中 使用左连接来加载关联数据。
预加载的写法有：
提供的方案一般般，在刚刚复习完笔记的我来看，甚至有点 low，首先是控制器加了个可选参数函数 WithPreloads，然后将设置的 Preloads 传递到仓储层，于仓储层直接：
从P影响分析
实际上，直接写 q = q.Preload(p.Association, nil) 都是可以的，并不需要 nil 守卫，直接去除。
产生两条 SQL：
AI 原本是这样写的：
Preload 写法，然后加载是加载了，闭包函数是固定的 return nil，以下是找到的难题或改善点。
控制器层，定义预加载选项 Preloads 时，支持到第二个参数，其类型和 GORM 的 Preloads 第二个参数同步。
就按子查询的方式，让 AI 实现出来，在已有的 BuildWhereScopes、BuildWhereExpr 完成关联表字段名检查等；这里实际上的实现比较复杂，而且人工 review 了很久，不过好在是实现出来了，而且很优雅。
总而言之，简化为单个 Preloads []repository.Preload 配置即可，不需要区分方法。
结果是：所有 Admin 都会在结果里，只是部分行（不匹配的）的 Group 数据将被置为 nil。
我们的表格是支持多字段筛选的，比如使用关联模型 group 的 name 字段模糊查询，前端几乎无需改动，表格组件和表格管家的公共搜索组件自然就能传递这种数据至服务端：
我要做不只是写好管理员和角色组的预加载（这直接重写仓储层就行），我的目的是在控制器配置一个字段，仓储层就能给我加载好供我使用，即 基类 对关联预加载的支持。
AI 上来就定义了一个 type Preload struct，第一个字段为 Name string，我对比了一下 Preload 的签名，它第一个参数是 association string，这个 AI 不严谨啊，让它先改正。
现在前端可以直接发送任意表的筛选数据，最终组装好对应的 SQL 进行查询，比如主表的 name LIKE '%foo%'，关联表的 group.name LIKE '%foo%'，引发了热烈讨论。
