ThinkPHP怎么使用模型字段只读虚拟字段缓存命中统计_ThinkPHP分析缓存效益【教程】-ThinkPHP-PHP中文网

虚拟字段不参与缓存命中统计，因其不在数据库字段中、不参与缓存键生成，仅在数据取出后由php层动态计算；缓存统计仅反映底层存储key的命中，与getattr调用无关。

thinkphp怎么使用模型字段只读虚拟字段缓存命中统计_thinkphp分析缓存效益【教程】

ThinkPHP 的模型字段只读虚拟字段（getAttr / setAttr）本身不参与缓存命中统计，也不会被写入或读取缓存 —— 因为它根本不在数据库字段列表里，也不走 ORM 的缓存键生成逻辑。

为什么虚拟字段不会出现在缓存命中统计中

ThinkPHP 的模型缓存（如 cache(true) 或查询缓存）只对「真实字段 + 查询条件」组合生成缓存键，底层依赖 Db::name()->field()->where()->cache() 这类链式调用的 SQL 摘要。而虚拟字段是通过模型的 getXXXAttr 方法动态计算的，执行时机在数据从缓存/数据库取出之后，属于 PHP 层后处理。

常见错误现象：
• 在模型里定义了 getFullnameAttr，开启 cache(true) 后发现缓存命中率没变化
• 用 Cache::tag('user')->get('xxx') 手动查缓存，结果里没有 fullname 字段 —— 这是正常的，不是漏了

虚拟字段不参与 Model::withCache() 的键生成
即使你用 together 关联 + 虚拟字段，缓存仍只认主表字段和关联表原始字段
想统计“带虚拟字段的查询是否被缓存”，得自己在 getAttr 里加日志或计数器，不能依赖框架内置统计

想让虚拟字段影响缓存，只能手动干预

如果你确实需要“某虚拟字段值变了，就让整条记录缓存失效”，就得绕过自动缓存，改用显式缓存控制。核心思路是：把虚拟字段的计算逻辑前置到缓存键中，或作为缓存 tag 的一部分。

amphp

使用 AMPHP 框架编写非阻塞异步 PHP 代码，依赖 revolt/event-loop、amphp/amp ^3 及完整 amphp/* 生态（http‑server、http‑client 等）。

下载

不要用 cache(true)，改用 cache('user_'.$id.'_'.$version, 3600)，其中 $version 可基于虚拟字段依赖的数据变动来更新（比如用户头像修改时间戳）
在 setAttr 中触发缓存清理：Cache::tag('user_'.$this->id)->clear()，前提是你的虚拟字段依赖其他可追踪字段
避免在 getAttr 里做耗时操作（如 DB 查询、HTTP 请求），否则缓存虽命中，但响应仍慢 —— 这会掩盖真实瓶颈

示例：用户昵称含等级前缀，等级来自另一张表

public function getNicknameAttr($value, $data)
{
    // ❌ 错误：每次取都查一次 level 表，缓存命中也白搭
    $level = Db::name('user_level')->where('id', $data['level_id'])->value('prefix');
    return $level . $data['name'];
}

✅ 正确做法：把 prefix 预加载进主查询，或用关联 + 缓存 tag 管理

缓存效益分析时，虚拟字段是“噪声”而非指标

ThinkPHP 自带的缓存统计（如 think\Cache::getInfo() 返回的 hit/miss）只反映底层存储层（Redis/File）的 key 命中情况，和模型层是否调用了 getAttr 完全无关。

同一个缓存 key 被读 100 次，但每次调用 5 个 getAttr，框架统计仍是 100 次 hit，不是 500 次
如果你用 Xdebug 或 debug_backtrace() 发现 getAttr 被高频调用，问题大概率出在模板层反复访问（如 {$user.fullname} 在循环里），而不是缓存没生效
真正影响缓存效益的是：查询是否复用、where 条件是否稳定、关联是否 N+1、字段是否过度 field('*')

虚拟字段和缓存命中统计本质上是两条平行线，强行拉在一起分析，只会把问题定位引向错误方向。真要优化，盯住 SQL 日志和缓存 key 结构，别在 getAttr 里埋点找“命中率”。