Hyperf 3.0 中 $casts 和访问器在查询中失效，主因是类型转换仅作用于模型实例属性读取，不参与原始SQL字段处理；子查询、selectRaw、from()等绕过模型生命周期的操作会导致cast和accessor不触发，需确保字段存在、命名规范、重启服务并清理注解缓存。
Hyperf 3.0 中模型访问器（Accessors）和属性转换（Casts）在查询结果中失效，通常不是代码写错，而是框架机制、缓存或配置层面的隐性问题。重点排查方向集中在类型转换时机、访问器触发条件、查询构造方式和缓存干扰四个环节。
确认 cast 是否在查询结果中生效
Hyperf 的 $casts 只对模型实例的属性读取起作用，不作用于原始 SQL 查询字段。例如：
- ✅ 正确：使用
User::find(1)->created_at→ 触发'created_at' => 'date'转换 - ❌ 失效：用
User::selectRaw('MAX(created_at) as last_time')->first()→ 返回的是原生数组或 stdClass，$casts完全不参与 - ⚠️ 注意：使用
from()或子查询时（如Article::from("articles as a")->select(...)），即使指定了withCasts()，也仅在后续调用getAttribute()时才生效；若直接访问$model->content（该字段非模型原始字段），则不会走 cast 流程
检查访问器是否被正确调用
访问器方法名必须严格匹配命名规范：get{CamelCase}Attribute，且属性名需存在于数据库字段或 $appends 中：
- 模型中定义
public function getFullNameAttribute()，但查询未 selectname和surname字段 → 访问器内逻辑无法执行（因依赖字段未加载） - 使用
toArray()或jsonSerialize()时，只有$appends显式声明的访问器字段才会被包含 - 静默返回 null 的风险：若访问器中引用了不存在的属性（如
$this->email_address实际字段为email），Hyperf 不报错，而是返回null，容易掩盖问题
验证查询构建方式是否绕过模型生命周期
以下写法会跳过模型的属性转换与访问器逻辑：
-
User::select('id', 'name')->get()→ 字段存在，cast 生效 -
User::selectRaw('id, UPPER(name) as name')->get()→name是计算字段，$casts不处理，访问器也不触发 -
User::query()->withCasts(['created_at' => 'date'])->get()→ 有效，但仅对模型原始字段起作用；若字段来自 join 或子查询，仍需手动处理 - 使用
toBase()->get()或原生查询（Db::select()）→ 完全脱离模型机制，无任何 cast 或 accessor
排除缓存与热更新干扰
Hyperf 3.0 注解驱动强依赖运行时缓存，修改模型后常见“看似没生效”：
- 改了
$casts或访问器方法，但未重启server:watch→ 新代码未加载 - 注解扫描缓存未重建：执行
php bin/hyperf.php di:init-proxy清空runtime/container/annotation/ - OPcache 未刷新：确保
opcache.validate_timestamps = 1，或调用opcache_reset() - 自定义 Cast 类（如实现
CastsAttributes）未被自动加载：检查composer.json中autoload配置是否覆盖该路径，并运行composer dump-autoload -o
