hyperf 自带 @cacheable 不支持 spel 表达式、条件缓存（unless/condition）、null 值防穿透及类型化反序列化；需自定义注解继承 abstractannotationaspect，用 expressionevaluator 解析 key，设 priority=100 避开事务切面，并安全读写 redis。
Cacheable 注解为什么不能直接用 Hyperf 自带的
Hyperf 自带的 @Cacheable 仅支持方法返回值缓存，且要求目标方法必须是 public、非 static、非 final，同时不支持动态 key 表达式（比如 #user.id 这类 SpEL 风格），也不支持条件缓存（unless = "result == null"）和类型化反序列化。实际项目中你常需要：按参数组合生成 key、只在特定条件下缓存、自动把 DTO 转成 JSON 再存 Redis、甚至对 null 值做空对象缓存防穿透——这些自带注解都做不到。
如何定义自己的 @Cacheable 注解并支持 SpEL 表达式
核心是继承 AbstractAnnotationAspect，自己解析注解属性 + 用 ExpressionEvaluator 计算 key 和 condition。关键点：
- 注解类需加
@Target({ElementType.METHOD})和@Retention(RetentionPolicy.RUNTIME) - 定义
key()（String 类型，用于 SpEL 解析）、condition()、unless()、ttl()等字段 - 切面里用
$this->expressionEvaluator->parseExpression($annotation->key())->getValue($evaluationContext)动态求值 -
$evaluationContext要手动构建，包含 method、args、target、result（后置时才有）等变量
示例 key 表达式："'user:info:' + #id" 或 "'user:profile:' + #user.username"，其中 #id 和 #user 来自方法参数。
切面中怎么安全地读写 Redis 并处理 null 值
不能在切面里直接 new Redis 实例，要用 Container::get(RedisInterface::class)；更关键的是 null 值处理逻辑：
- 前置拦截时：先 try 从 Redis 读，命中则直接 return，注意判断是否为
NULL_CACHE占位符（如"__NULL__"）并转成 null - 后置拦截时：若 result 为 null 且配置了
cacheNull = true，则存占位符 + 短 TTL（如 2 秒），防穿透 - 反序列化要兼容多种类型：基础类型直接 json_decode；对象类型用
Serializer::unserialize($data, $returnType)（需提前注入反射信息） - 务必用 try/catch 包裹 Redis 操作，失败时 log 并 fallback 到原方法调用，避免缓存雪崩或服务不可用
为什么 Cacheable 切面一定要设 priority = 100 且避开事务切面
Hyperf 的事务切面默认 priority 是 50，如果你的缓存切面 priority ≤ 50，就可能在事务 commit 前就读到脏数据；而 priority > 100 又可能被其他增强（如日志、监控）干扰执行顺序。所以显式设 priority = 100 是经验值。
更要命的是：如果目标方法被 @Transactional 包裹，而你的缓存切面在事务开启前就写了 Redis，那 rollback 后 Redis 里就是错的数据。解决办法只有两个：
- 在切面里检测当前是否已开启事务（
Db::connection()->isTransactionActive()），若是则跳过缓存写入 - 或者改用「事务提交后」钩子（
afterCommit事件）异步刷新缓存，但这会增加架构复杂度
多数业务场景下，宁可让缓存短暂不一致，也不要因强一致性引入死锁或延迟——这点很容易被忽略，直到压测时出现大量 Redis timeout 和事务超时。
