apcu扩展未启用会导致apcu_fetch报错，需确认php.ini中启用extension=apcu.so且非zts构建兼容；cli模式默认禁用，须设apc.enable_cli=1；写入失败静默返回false，应校验返回值并监控共享内存；高并发下apcu_inc不保证强一致，严格场景需apcu_cas配合fetch实现；无持久化、无自动续期，不可替代db或分布式缓存。
APCu扩展没启用，apcu_fetch直接报错
PHP调用apcu_fetch或apcu_store前，必须确认APCu已加载且启用。常见错误是只装了扩展但没在php.ini里开启，或者启用了apc（旧版）却误以为它能替代APCu。
检查方法：运行php -m | grep apcu，或查看phpinfo()输出中是否有“APCu”模块。若无，需安装并启用——Ubuntu下是sudo apt install php-apcu，然后确认extension=apcu.so在php.ini中未被注释。
- APCu不兼容PHP 8.2+的某些ZTS（线程安全）构建，如用的是容器镜像，优先选
non-zts版本 - CLI模式默认禁用APCu缓存（
apc.enable_cli=0），调试时记得设为1，否则php -r "var_dump(apcu_fetch('x'));"永远返回false - 如果和OpCache共存，二者互不干扰，但别把APCu当opcode缓存用——它只存用户数据
apcu_store写入失败但不报错，数据却读不出来
APCu写入失败通常静默失败，最常见原因是内存满了或键名非法。它不会抛异常，只返回false，而很多代码忽略返回值直接往后走。
典型场景：批量写入大量小数据，或键名含空格、控制字符、超长（默认限制4096字节，但实际建议≤255）、以数字开头（如"123key"可能被截断）。
立即学习“PHP免费学习笔记（深入）”；
- 务必检查
apcu_store返回值：if (apcu_store('user_123', $data, 300) === false) { error_log("APCu store failed"); } - 用
apcu_sma_info()查共享内存状态，关注num_seg、seg_size和avail_mem——如果avail_mem长期接近0，说明配置的apc.shm_size太小（默认32M） - 键名避免动态拼接未过滤的用户输入，比如
$_GET['id']直接进键名，可能触发非法字符或长度溢出
高并发下apcu_inc计数不准，或apcu_cas失效
APCu本身是进程级共享内存，不是分布式锁。在FPM多worker场景下，apcu_inc看似原子，但若多个请求同时读-改-写同一键，仍可能丢失更新——因为它的“原子性”仅限单次操作，不提供compare-and-swap语义的强一致性保障。
例如：两个请求同时执行apcu_inc('counter')，预期+2，实际可能只+1。真正需要严格计数或乐观锁时，得靠apcu_cas手动实现，但前提是先用apcu_fetch拿到旧值+校验戳。
-
apcu_inc适合统计类场景（如页面PV），不要用于库存扣减、余额变更等强一致性逻辑 - 用
apcu_cas前必须先apcu_fetch($key, $success, $ttl)拿到$ttl和当前值，再传给apcu_cas($key, $old_value, $new_value)，否则返回false - FPM下每个worker有独立APCu实例？不，APCu是共享内存段，所有worker可见同一份数据——但并发冲突依然存在，只是不跨机器
缓存穿透/雪崩没防住，APCu反而成瓶颈
APCu快，但不是万能保险。如果业务层没做空值缓存或降级逻辑，大量查不到的数据反复穿透到后端，APCu本身虽不慢，可高频apcu_fetch失败+后续DB查询叠加，会把CPU打满，甚至因内存碎片导致APCu分配变慢。
更隐蔽的问题是“缓存雪崩”：一批热点键同时过期，瞬间全量回源。APCu不支持自动续期，ttl一到就删，没法像Redis那样用getset兜底。
- 对可能为空的结果，也存一个占位符（如
null或''），并设较短ttl（如30秒），防止缓存穿透 - 避免所有热点键用同一ttl，比如用户信息统一设300秒，改成
300 + rand(0, 60)，分散过期时间 - APCu没有持久化，服务重启即清空——别把它当可靠存储，关键数据必须有DB兜底，缓存只是加速层
APCu的边界很清晰：单机、高频、短生命周期、允许丢失的数据。一旦涉及跨进程协调、持久保障或复杂过期策略，就得换方案，别硬扛。
