PHP程序员转型AI与Golang：管理员角色组关联

这是一个系列文章，我将以PHP全栈工程师的身份，借助AI工具（TRAE、claude code、codex、deepseek、豆包等），从零开始学习Golang语言，并最终完成ai-go-admin开源项目的制作。全程记录，分享经验。

上一期我们完成了“增加管理员角色组管理”，这一期接着做：管理员和角色组的关联。

管理员和角色组的关联

系统里目前还没用上关联表，这次就拿管理员和角色组来跑通整个流程。先让AI给个方案，切换到plan模式：接下来需要完成Admin和AdminGroupAccess模型的关联，它们定义在@internal/model/admin.go，用什么方式关联比较好？同时，我需要为基类增加快速配置关联的功能，在什么地方配置，配置名叫什么比较好？

GORM 预加载复习

上面那段提示词说得比较笼统，连关联模式都让AI自己选。在它分析的时候，我赶紧翻出GORM的学习笔记，重新过一遍各种关联方式的预加载写法。

预加载的写法有：

Preload

type User struct {
    gorm.Model
    Username string
    Orders []Order
}

type Order struct {
    gorm.Model
    UserID uint
    Price float64
}

// 预加载 Order 数据，参数二可以传递一个 func(db gorm.PreloadBuilder) error 闭包函数，里边拼接查询条件、排序方式等
.Preload("Order", nil)

// 条件预加载
.Preload("Orders", "state NOT IN (?)", "cancelled")

// 嵌套
.Preload("Orders.OrderItems.Product")

Joins 预加载

还是上面的模型定义，用 Joins 预加载是这样写的：

// 参数二同样可以传递一个闭包，签名是: func(db gorm.JoinBuilder, joinTable clause.Table, curTable clause.Table) error
.Joins(clause.JoinTarget{Association: "Order"}, nil)

Joins 预加载性能最好，因为它在单条 SQL 里用左连接加载关联数据。

AI 初版完成

AI 给的方案一般般，刚复习完笔记再看，甚至有点low。首先是在控制器里加了个可选参数函数WithPreloads，然后把设置的Preloads传到仓储层，仓储层直接：

// 预加载关联
for _, p := range opts.Preloads {
    q = q.Preload(p, func(pb gorm.PreloadBuilder) error { return nil })
}

用的是Preload写法，加载是加载了，但闭包函数固定返回nil。下面逐一列出问题和改进点。

参数和 GORM 的 Preloads 同步

// Preload 预加载关联配置
type Preload struct {
    Name  string                                                       // 关联名称
    Query func(gorm.PreloadBuilder) error // 可选的自定义查询条件，为 nil 时仅按名称预加载
}

AI 上来就定义了一个type Preload struct，第一个字段是Name string。我对比了一下Preload的签名，它第一个参数是association string，这个 AI 不严谨，先让它改过来。

控制器层关联配置优化

// PreloadFields 声明对应方法的预加载关联配置
type PreloadFields struct {
    Get    []repository.Preload
    List   []repository.Preload
    Update []repository.Preload
    Create []repository.Preload
}

这是 AI 模仿ActionFields搞出来的，给Get、List、Update、Create各配了一个Preload位置。但Update、Create里这些东西基本没用，直接去掉。List是主要使用方，Get用得少，就算额外查了List的Preload也没关系。所以简化成单个Preloads []repository.Preload配置就行，不需要区分方法。

仓储层 Preload 调用优化

AI 原本这样写：

for _, p := range opts.Preloads {
    query := p.Query
    if query == nil {
        query = func(pb gorm.PreloadBuilder) error { return nil }
    }
    q = q.Preload(p.Association, query)
}

实际上直接写q = q.Preload(p.Association, nil)就行，不需要nil守卫，直接去掉。

关联筛选查询

我们的表格支持多字段筛选，比如用关联模型group的name字段模糊查询。前端几乎不用改，表格组件和表格管家的公共搜索组件自然能传递这种数据到服务端：

{
    wheres: [
        { field: 'group.name', operator: 'ILIKE', value: '1' },
        { field: 'group.title', operator: 'ILIKE', value: '1' }
    ],
    or: true
}

问题在于服务端在哪里应用这些筛选数据。首先想到的是用Preload(association string, query func(db gorm.PreloadBuilder)的第二个闭包函数，但这个理解是错的：

gorm.G[Admin](db).Preload("Group", func(pb PreloadBuilder) error {
    pb.Where("name LIKE ?", "%foo%")
    return nil
}).Find(ctx)

会产生两条 SQL：

-- 1. 主查询：所有 Admin，全部返回
SELECT * FROM admins;

-- 2. 预加载：只加载 name LIKE 'foo' 的 group
SELECT * FROM admin_groups WHERE id IN (?, ?, ?) AND name LIKE '%foo%';

结果就是所有Admin都会出现在结果里，只是部分行（不匹配的）的Group数据被置为nil。

我们想要的筛选语义是：只返回group.name匹配的Admin行。这需要主查询过滤，Preload帮不上忙。唯一干净的方式是子查询，顺着关联链层层套EXISTS/IN子查询就行。

SELECT * FROM admins WHERE admins.group_id IN (
    SELECT id FROM admin_groups WHERE name LIKE '%foo%'
);

就按子查询的方式让AI实现出来，在已有的BuildWhereScopes、BuildWhereExpr里完成关联表字段名检查等。实际实现比较复杂，人工review了很久，好在最终做出来了，而且很优雅。现在前端可以直接发任意表的筛选数据，最终组装好对应的SQL进行查询，比如主表的name LIKE '%foo%'，关联表的group.name LIKE '%foo%'。