ThinkPHP6.0模型关联需显式定义且参数不可省略，belongsToMany必须写全6个参数，否则静默失败；多对多中间表字段需通过through指定中间模型才能访问pivot数据。
ThinkPHP6.0 的模型关联不是“配好就能用”，而是必须显式定义、参数不能省、调用方式要匹配，否则查不到数据、不报错、静默失败——这是最常踩的坑。
belongsToMany 必须写全 6 个参数，少一个都不行
多对多关联只认 belongsToMany，写成 _belongsToMany 或 belongToMany 就直接失效。框架不会提示，->roles 返回空集合，连 SQL 都不发。
- 第 1 个参数是关联模型类，如
Role::class - 第 2 个参数是中间表名（不含前缀），如
'sys_user_role' - 第 3 个参数是当前模型在中间表的外键字段，如
'uid'（注意大小写必须和数据库一致） - 第 4 个参数是关联模型在中间表的外键字段，如
'rid' - 第 5 个参数是当前模型主键名，如
'id'；如果主键是user_id，就得写死 - 第 6 个参数是关联模型主键名，同理不能依赖默认
示例：return $this->belongsToMany(Role::class, 'sys_user_role', 'uid', 'rid', 'id', 'id');
验证是否生效：开调试模式，看日志里有没有类似 SELECT * FROM `sys_user_role` WHERE `uid` = ? 的语句。没有，说明参数没对上。
立即学习“PHP免费学习笔记（深入）”；
with() 里加条件 ≠ 关联筛选，要用 hasWhere() 或 whereExists()
with(['orders' => function ($q) { $q->where('status', 1); }]) 这种写法只会让 $user->orders 里只含 status=1 的订单，但 User::with(...)->select() 查出来的用户列表，仍是所有用户——哪怕其中很多人的订单全被过滤掉了。
- 想「只查有有效订单的用户」，用
hasWhere('orders', ['status' => 1]) - 想「只查订单总金额 > 1000 的用户」，用
whereExists()手写子查询，因为涉及聚合 -
hasWhere()生成 EXISTS，性能好；whereExists()灵活但得自己拼 SQL 片段，注意别漏$query->exp('users.id')这类绑定
错误示范：User::with(['orders' => fn($q) => $q->where('status', 1)])->has('orders') —— has() 不读闭包里的条件，白写。
关联字段输出控制必须分层做，不能只靠 toArray()
输出时关联数据乱七八糟？不是 toArray() 没用，而是你没在对的地方控制字段。
- 想隐藏
profile.email，得在查询后调$user->hidden(['profile.email'])，不是在模型里设$hidden - 想只输出
profile.avatar，用$user->visible(['id', 'nickname', 'profile.avatar'])，但注意：不能写['profile']，必须点号展开到字段级 - 想在 with 阶段就减少数据量，直接在预载入里控制：
User::with(['profile' => fn($q) => $q->visible(['avatar', 'bio'])]) - 追加虚拟字段如
fullname，先确保模型里有getFullnameAttr()和protected $append = ['fullname']，再调$user->append(['fullname'])->toArray()
关键点：主模型字段控制、关联模型字段控制、关联模型内部字段控制，这三层必须分开处理，混在一起必出错。
中间表字段（pivot）必须建中间模型 + through，否则拿不到
默认 belongsToMany 只返回关联模型实例（如 Role），中间表里的 created_at、status 等字段根本不会加载，$role->pivot 是 null。
- 先建中间模型，比如
UserRole，继承think\Model，并指定表名：protected $table = 'sys_user_role'; - 在
belongsToMany后链式调用->through(UserRole::class) - 之后才能访问
$user->roles[0]->pivot->created_at或$user->roles[0]->pivot->status
没走这一步，所有 pivot 相关逻辑都会静默失败——这不是 bug，是设计如此，但文档里容易漏掉这个前提。
