ThinkPHP 的 Cache::inc() 返回错值的根本原因是 PHP 层将 INCR 与 EXPIRE 拆分为两步执行，破坏原子性；正确做法是用 setex 初始化 key 后仅调用 incr，并严格校验返回值类型。
ThinkPHP 中 Cache::inc() 为什么有时返回错值
根本原因不是 Redis 不原子，而是 PHP 层调用方式破坏了原子语义。ThinkPHP 的 Cache::inc($key, $step, $ttl) 在 TTL 参数非 null 时，会先执行 INCR，再单独发 EXPIRE 命令——这两步不原子。网络抖动、Redis 主从切换或命令重试都可能导致 key 有值但没过期时间，或反过来：有过期时间但计数没加成功。
常见错误现象：Cache::inc('counter:order', 1, 3600) 在高并发下统计总数比实际请求少；同一秒内多个请求返回相同递增值；凌晨清零后首笔请求拿到 0 而不是 1。
- 必须改用原生命令组合：
$redis->incr($key)+$redis->expire($key, $ttl)分开调用，并捕获异常后重试 - 更稳妥的做法是提前设好带过期的 key：
$redis->setex($key, $ttl, 0)（初始化），后续只用incr - 别依赖
Cache::inc()的第三个参数做“自动过期”，它在 TP6/TP8 中仍存在竞态窗口
Redis key 设计不当导致计数跨天错乱
用 date('ymdHis') 拼接 key（如 order_sn_240817120000）看似精确，但秒级粒度在每秒数百请求时，key 数量爆炸，且无法对齐“自然日”。更糟的是，若用 microtime(true) 直接拼 INCR 结果，PHP 浮点精度丢失会让多个请求拿到完全相同的时间前缀，最终生成重复单号。
- 正确做法：统一按「分钟」或「小时」对齐时间维度，例如
order_sn_2408171200（2024-08-17 12:00），所有该分钟内请求共享同一个 key - key 必须带业务前缀和可读性分隔符，如
api:count:login:admin，避免和其他模块冲突 - 设置 TTL 时，不要硬写 86400，而应算出到下一个整点/整分的毫秒差，防止因系统时间跳变导致 key 提前失效
INCR 返回 false 或 null 时没兜底，直接拼字符串出脏数据
Redis 连接超时、集群 slot 迁移、OOM 拒绝写入等场景下，$redis->incr($key) 可能返回 false 或抛出 RedisException。若业务代码直接 $sn = $date . '_' . $redis->incr($key)，就会得到类似 2408171200_ 这种缺数字的非法单号。
立即学习“PHP免费学习笔记（深入）”；
- 必须检查返回值是否为整型：
is_int($ret) && $ret >= 0 - 建议封装重试逻辑：while 循环 ≤3 次，每次失败后
usleep(500)，避免打满 Redis - 极端情况下（如 Redis 宕机），需启用本地内存计数器（如
apcu_inc()）或降级为 UUID 前缀 + 时间戳，但要标记为「降级单号」便于后续人工核对
多实例部署下未处理 key 冷热不均与连接池耗尽
TP 默认每次 Cache::store('redis') 都可能新建连接，循环中高频调用 inc() 会导致 Redis 连接数飙升，最终触发 maxclients 拒绝新连接，部分请求 fallback 到本地缓存或直接失败，计数开始漏掉。
- 确认 config/cache.php 中 redis 配置已开启持久连接：
'persistent' => true，并确保 php.ini 启用redis.pconnect = 1 - 高并发接口中，避免在 for 循环里反复调用
Cache::inc()，应先获取 Redis 实例单例：$redis = app('cache')->store('redis')->getHandler()，再复用 - 若用 Swoole，必须配置协程 Redis 池，否则每个协程都持有一个独立连接，连接数呈线性增长
incr() 调用后必须校验返回值类型，不能假设它一定成功。Redis 的原子性只保证命令本身，不保证你的 PHP 代码怎么用它。 
