只读虚拟字段必须用getAttr而非setAttr实现，因其仅在读取时触发；需通过append或显式访问确保JSON输出，且依赖关联数据时须预加载或手动load，hidden/visible对其无效。
模型里定义只读虚拟字段用 getAttr 还是 setAttr
只读虚拟字段不能靠 setAttr 控制写入，它只管“设”，不管“读”。真正起作用的是 getAttr —— ThinkPHP 在获取字段值时，如果数据库没这个字段，就会触发对应 getXxxAttr 方法（比如字段叫 full_name，就找 getFullNameAttr）。
常见错误是把逻辑写在 setFullNameAttr 里，结果调用 $model->full_name 时返回 null 或原始字段值，因为压根没走读取逻辑。
-
getAttr方法名必须严格匹配“驼峰字段名 + Attr”，如数据库字段为user_id，虚拟字段想叫userName，就得写getUserNameAttr - 方法参数固定是
$value, $data，其中$data是当前模型所有原始数据（含关联查询结果），别漏掉它 - 返回值会直接覆盖字段访问结果，不校验类型，也不触发验证或自动转换
虚拟字段不入库但要参与 JSON 输出的坑
ThinkPHP 默认把所有 public 属性和可读字段都塞进 toArray() 和 JSON 序列化结果里，但虚拟字段如果没被显式“读过”，getAttr 不会自动执行，导致 JSON 里字段缺失或为 null。
典型场景：API 返回用户列表，每个用户带 avatar_url（拼接 avatar 字段 + 域名），但接口响应里这个字段总为空。
立即学习“PHP免费学习笔记（深入）”；
- 必须在序列化前主动访问一次字段，比如
$user->avatar_url，或批量用append(['avatar_url']) -
append是最稳妥的做法，它强制触发getAttr并注入结果，支持链式调用：$user->append(['full_name', 'is_vip'])->toArray() - 注意
append只影响当前实例，不会污染模型类定义；若在关联模型中使用，需在关联定义里加->append(...)
虚拟字段依赖关联数据时的加载顺序问题
当 getAttr 方法里需要读取关联模型（比如 $this->profile），而该关联尚未加载，$this->profile 就是 null，不是延迟加载对象——ThinkPHP 不会在 getAttr 中自动预加载关联。
错误现象：本地开发没问题，线上偶尔报 Trying to get property 'nick_name' of non-object，本质是关联未查、属性访问失败。
- 要么提前用
with('profile')加载关联，再调用append - 要么在
getAttr内部手动判断并加载：if (!$this->relationLoaded('profile')) { $this->load('profile'); } - 避免在
getAttr里写 DB 查询，否则可能引发 N+1；优先用已加载的$data参数拼装，比如$data['profile']['nick_name']
hidden 和 visible 对虚拟字段无效？
是的。hidden 和 visible 只控制数据库字段和模型属性，对通过 getAttr 动态生成的虚拟字段不起作用。它们是否出现在 toArray() 里，只取决于有没有被 append 过，或者有没有被显式访问过。
容易混淆的点：给模型加 protected $hidden = ['password'];，顺手把 'full_name' 也加进去，结果发现它还在 JSON 里——因为 hidden 根本不认这个字段。
- 要隐藏虚拟字段，只能靠不
append、不访问，或在toArray()后手动unset - 想统一控制输出结构，建议封装一个
toApiArray()方法，在里面明确append和visible组合使用 - 虚拟字段命名尽量避开真实字段名，否则
$model->name可能返回数据库值或getNameAttr结果，行为不可控
虚拟字段真正的复杂点不在定义，而在它和加载时机、关联状态、序列化流程的耦合——稍不注意，同一个字段在列表页正常、详情页为空、导出 Excel 时又报错，根源往往就是 $data 里缺了某层嵌套数据。
