ThinkPHP模型中通过getXXXAttr方法定义只读计算字段，需显式声明$append并注意避免在其中执行IO操作。
ThinkPHP 模型里怎么加只读计算字段（不存数据库）
直接在模型类里定义一个普通方法，用 getXXXAttr 命名约定，ThinkPHP 会自动把它当虚拟字段处理。比如想有个 full_name 字段拼接 first_name 和 last_name，就写 getFullNameAttr 方法。
注意：这个方法必须有 $value 和 $data 两个参数（即使不用 $value），否则运行时可能静默失效或报错 Missing argument 2。
- 方法返回值就是字段值，支持任意 PHP 表达式，包括调用其他模型、查缓存、甚至简单日志埋点
- 字段不会出现在
$model->toArray()的默认结果里，除非显式调用visible或在append中声明 - 不能用
setXXXAttr反向控制——它只读，赋值会被忽略
为什么 getXXXAttr 里改数据库或写日志会出问题
因为 ThinkPHP 在很多场景下会批量调用所有 getXXXAttr 方法，比如 select() 查出多条记录后统一转换为数组，或者做 JSON 输出前遍历所有附加字段。这时候如果每个 getFullNameAttr 都去写一次日志，实际会触发 N 次磁盘 I/O，性能崩得比想象中快。
- 常见错误现象：
select()->toArray()响应慢、日志文件暴涨、并发下 MySQL 连接被打满 - 真实使用场景：后台列表页查 50 条用户，每条都触发
getLoginCountAttr，而它内部又查了一次LogModel表 - 正确做法是把日志/统计类逻辑抽到独立服务层，模型只负责“表达”，不负责“执行”
想让计算字段依赖日志表数据，该怎么安全关联
别在 getXXXAttr 里查日志表。改用模型的 withAttr + 关联预加载，或者更稳妥的：在控制器里手动补字段。
立即学习“PHP免费学习笔记（深入）”；
- 推荐方式：查主表时用
with(['logs' => function ($q) { $q->limit(1)->order('id desc'); }])，再在getLatestLogTimeAttr里从$data['logs'][0]['created_at']取值 - 避免用
Db::name('log')->where(...)这种硬查询——它绕过 ORM 缓存和连接池，也难测难 mock - 如果日志量大且字段要高频计算，考虑把关键聚合值（如最近登录时间、操作次数）冗余到主表，用定时任务或数据库触发器更新
append 字段没显示？检查这三处
append 不是万能开关，漏掉任一环节都会让计算字段“消失”。
- 模型类里没定义
protected $append = ['full_name'];—— 必须显式声明，否则getXXXAttr方法只是“存在”，不“启用” - 用了
hidden或visible，且没把计算字段包含进去 —— 它们优先级高于append - 调用的是
$model->getData()而不是$model->toArray()—— 前者只返回原始数据，不触发getXXXAttr
复杂点在于：计算字段的依赖可能跨模型、跨请求生命周期，一旦掺了日志或统计逻辑，就很容易变成“看似正常，压测就崩”的隐性坑。
