incr能保证原子性是因为redis服务端采用单线程事件循环模型，所有命令串行执行，其底层为不可分割的读-改-写操作，不依赖jvm锁，跨进程、跨语言均一致；它仅支持64位有符号整数，key不存在时自动初始化为0，非数字值或溢出将报错。
INCR 是 Redis 实现原子性递增最直接、最常用的方式，它天然线程安全，无需额外加锁或事务包装。
为什么 INCR 能保证原子性？
Redis 服务端是单线程事件循环模型，所有命令串行执行。INCR 在底层由一个不可分割的内存读-改-写操作完成，不会被其他客户端请求打断。哪怕并发 1000 个 INCR 请求，最终结果也严格等于初始值 + 1000。
注意：这不是靠 Java 层面的 synchronized 或 CAS 实现的，而是 Redis 服务端强制串行化的结果 —— 所以跨 JVM、跨进程、跨语言调用都一致。
INCR 的使用限制和常见报错
它只接受能转为 64 位有符号整数的字符串值。一旦 key 存的是非数字内容，就会失败：
-
INCR mykey→ 如果mykey值是"hello"，返回错误：(error) ERR value is not an integer or out of range -
INCR mykey→ 如果mykey不存在，自动初始化为0，再 +1，返回1 -
INCR溢出时会报错：(error) ERR increment or decrement would overflow（超过9223372036854775807或低于-9223372036854775808）
Spring Boot 中用 StringRedisTemplate 调用 INCR
推荐走 opsForValue().increment()，它底层就是发 INCR 命令：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
Long result = stringRedisTemplate.opsForValue().increment("counter:order");
// 返回递增后的值，比如 1、2、3...
几个关键点：
- 不要用
get() + parseLong() + set()模拟递增 —— 这三步不原子，高并发下必然丢数 -
increment()默认步长为 1；如需自定义步长，用increment("key", 10L)（对应 Redis 的INCRBY） - 如果 key 不存在，
increment()同样会先设为0再加，行为和原生命令完全一致
需要带过期时间的递增场景怎么处理？
INCR 本身不支持设置过期时间，必须拆成两步，但要注意顺序：
- 先
INCR（或increment()），再EXPIRE—— 否则可能递增成功但过期失败，导致 key 永久存在 - 更稳妥的做法是：用
SET key 0 EX 3600 NX初始化带过期的 key，之后只用INCR - 如果要“整点重置”，别依赖
EXPIRE精确触发，而是按时间戳构造 key，比如counter:2026071312，让旧 key 自然失效或主动清理
真正容易被忽略的不是语法，而是 key 的生命周期设计 —— 原子递增只是工具，怎么组织 key 才能让业务逻辑可维护、可追溯、可清理，才是实际落地中最常翻车的地方。
