php方法调用开销极小，性能瓶颈多源于内部高成本操作；缓存需精准选型、严谨设计键名、原子读写及主动失效，避免盲目使用导致一致性风险或资源浪费。
PHP 方法调用本身开销极小，真正拖慢性能的几乎从来不是“调用”动作，而是方法内部重复执行的高成本操作——比如数据库查询、远程 API 调用、复杂计算或序列化/反序列化。缓存结果集是性价比最高的优化手段，但必须明确缓存什么、在哪里缓存、怎么失效。
缓存前先确认是否真该缓存
不是所有方法都适合加缓存。盲目套用 apcu_store() 或 $redis->setex() 可能引入一致性风险或内存浪费。
- 数据变更频率低（如配置项、地区列表、静态商品分类）→ 适合缓存
- 每次调用参数不同且无规律（如
get_user_by_id($id)中$id全局唯一且高频分散）→ 缓存单条可行，但需带参数构造键名，如'user_'.$id - 返回值含资源句柄（如
PDOStatement、mysqli_result）或闭包 → 不能直接缓存，会报错或导致后续调用失败 - 方法内有副作用（如写日志、发消息、修改全局状态）→ 缓存后这些逻辑会被跳过，行为不一致
选对缓存层：OPcache、APCu、Redis 各干各的事
别把 APCu 当 Redis 用，也别指望 OPcache 存业务数据。
-
opcache.enable=1是必须开启的，但它只缓存 PHP 文件编译后的 opcode，对运行时方法返回值无效 -
apcu_store()适合单机、高频读、低更新、小体积（get_all_permissions() 返回的权限数组；注意 CLI 和 Web 进程的 APCu 内存空间完全隔离 -
$redis->setex('key', 3600, $data)适合跨进程、需持久化、支持大对象或集群部署的场景；但网络往返和序列化成本真实存在，别缓存几字节字符串 - 文件缓存（
file_put_contents()）仅用于调试或极简部署，无并发安全机制，flock()处理不好会丢数据
缓存键设计与原子性读写必须严谨
缓存击穿、雪崩、脏读，90% 源于键名随意或读写非原子。
- 键名必须包含所有影响结果的输入参数，例如
'product_detail_v2_'.$product_id.'_'.$lang，避免因多语言或版本升级导致缓存污染 - 不要分开写
if (!apcu_exists($key)) { $val = expensive(); apcu_store($key, $val); }—— 高并发下多个请求会同时执行expensive()；改用apcu_entry($key, fn() => expensive(), $ttl)（PHP 7.4+）或加锁 - 缓存值必须可序列化，
json_encode()比serialize()更安全（不存资源、不依赖类定义），但注意浮点精度和 UTF-8 问题 - 设置 TTL 时避免全量缓存同一时间过期，可加随机偏移：
3600 + rand(0, 300)
失效策略比缓存逻辑更难写对
缓存写进去容易，让它在正确时机消失才见功力。
- 主动失效优于被动过期：数据更新时立刻
apcu_delete('user_'.$id)或$redis->del('user_'.$id)，而不是等 3600 秒后自动消失 - 无法精准失效（如批量更新用户状态）→ 改用“标记失效”：缓存里存一个带版本号的结构
['v' => 123, 'data' => [...]]，更新时只增版本号，读取时检查版本匹配 - 绝对不要用
apcu_clear_cache()清全局，它会把 OPcache 编译缓存也一起踢掉，引发雪崩式重编译 - 数据库直连更新但没通知缓存？考虑在事务提交后触发
redis publish或写个轻量钩子，别依赖定时任务扫表
最常被忽略的点：缓存不是银弹，它是用空间换时间、用复杂度换速度的权衡。一个没设 TTL 的 apcu_store() 调用，可能让线上 bug 隐藏数小时；一个没做 json_last_error() 检查的 json_decode()，会让整个缓存分支静默失败。动手前，先问自己——这个结果，到底变不变？变了谁来告诉缓存？
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
