ThinkPHP模型save()不自动更新关联字段，需用setAttr修改器实现联动；saveAll()绕过模型逻辑，关联字段失效；跨模型同步须事务保障。
模型 save() 时关联字段没更新？检查是否启用了 autoWriteTimestamp 或 type 配置干扰
ThinkPHP 模型的 save() 默认只写入显式传入的字段，不会自动同步关联字段（比如 update_time、status_text 这类派生值）。很多人以为加了 protected $autoWriteTimestamp = true 就能联动更新时间戳以外的字段，其实不能。
常见错误现象：save(['name' => 'xxx']) 后，数据库里 update_time 没变，或自定义的 full_name 字段始终为空。
-
autoWriteTimestamp只影响create_time/update_time，不触发其他字段逻辑 - 若字段依赖其他字段计算（如
status_text = ['0'=>'待处理','1'=>'已完成'][$status]），必须手动赋值或用setAttr定义访问器+修改器 - 使用
type配置（如'status_text'=> 'text'）会强制类型转换，但不会自动填充——它只管“怎么存”，不管“要不要存”
想让 status 改变时自动同步 status_text？用 setAttrStatus + getAttrStatusText
ThinkPHP 的修改器（mutator）是唯一可靠、可复用的联动方案。不要在控制器里反复写 $model->status_text = $map[$model->status]，既重复又容易漏。
使用场景：状态码转文字、金额乘以 100 存整数、密码字段自动加密等需要“写入前加工”的情况。
立即学习“PHP免费学习笔记（深入）”；
- 在模型中定义
setAttrStatus方法，内部同时设置status和status_text（注意：不要调用$this->status_text = ...，会触发无限递归） -
status_text字段需声明为protected $readonly = ['status_text']，防止被外部直接覆盖 - 读取时用
getAttrStatusText返回映射值，这样$model->status_text始终准确，且不占数据库字段
示例：
public function setAttrStatus($value) {<br> $this->data['status'] = $value;<br> $this->data['status_text'] = ['0'=>'草稿','1'=>'已发布'][$value] ?? '未知';<br>}
saveAll() 批量更新时，每个记录的关联字段都不生效？因为没走单条模型生命周期
saveAll() 底层调用的是 Db 类批量写入，绕过了模型实例的 setAttr*、事件、验证等机制。所有联动逻辑都会失效，包括时间戳、状态映射、加密等。
性能影响明显：看似一行代码搞定，实则丧失数据一致性保障，尤其在有业务规则约束时风险极高。
- 如果必须批量操作，改用循环 + 单条
save()，并开启事务包裹：$this->startTrans(); foreach (...) { $model->save(...); } - 或者改用
Db::name('table')->update([...])手动拼好全部字段（含关联字段值），但要自己维护映射逻辑 - 切勿依赖
saveAll()自动推导关联字段——它根本不会调用你的修改器
关联模型（hasMany/belongsTo）字段不同步？那是两个模型的事，不是“联动”而是“事务协调”
比如订单主表 order.status 更新后，想同步更新所有子订单项 order_item.status，这不是字段联动，是跨模型业务动作。ThinkPHP 不提供自动级联更新能力，强行在主模型里写子表逻辑会污染职责边界。
容易踩的坑：在主模型的 afterUpdate 事件里调用子模型 saveAll()，结果子表更新失败时主表已提交，数据不一致。
- 必须用事务控制：主模型保存 → 子模型批量更新 → 全部成功才提交
- 避免在模型事件中做重操作；更适合放在 service 层统一编排
- 如果只是读取时需要关联字段（如查订单时带出用户昵称），用
with()+ 关联定义即可，无需写入同步
复杂点在于：字段联动从来不是“配置一下就行”的事，它本质是业务规则的编码表达。哪个字段由谁负责更新、失败如何回滚、并发下是否加锁——这些都得自己想清楚。ThinkPHP 只提供钩子，不替你做决定。
