Redis不能在列表中间按索引插入元素；LINSERT仅支持基于存在值的前后插入，不支持下标定位，且锚点不存在时返回-1，无原子性索引插入方案。
Redis 能不能在列表中间插入元素？
不能直接按索引插入。Redis 的 LINSERT 不是“在第 N 个位置插入”，而是“在某个值的前/后插入”——它依赖的是**值匹配**，不是下标。如果你脑子里想的是 list.insert(3, "x") 那种行为，LINSERT 会让人困惑甚至失效。
LINSERT 的真实行为：靠值找锚点，不是靠位置
LINSERT 必须指定一个已存在的元素值作为锚点，再决定插在它前面还是后面。如果锚点值重复出现，Redis 只匹配**第一个**（从左往右扫描）；如果锚点不存在，命令直接返回 -1，不报错但也不写入。
- 语法：
LINSERT key BEFORE|AFTER pivot value -
pivot必须是列表中**实际存在的字符串值**，区分大小写 - 即使列表有 10 万个元素，只要没找到
pivot，就返回-1 - 不支持用索引（如
2）或通配符（如"user:*"）当锚点
示例：LPOP mylist 后列表是 ["a", "b", "c", "d"]，执行 LINSERT mylist AFTER "b" "x" → 结果为 ["a", "b", "x", "c", "d"]；但若执行 LINSERT mylist AFTER "z" "x"，返回 -1，列表不变。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
为什么不用 LPUSH/LPUSHX/RPUSH 做“中间插入”？
因为它们只能在头或尾操作。真要按索引插中间，唯一办法是：先 LRANGE 拉出全部数据 → 在客户端做切片拼接 → DEL 原 key → RPUSH 新序列。但这在大列表上极危险：
- 网络传输开销大（比如 10MB 列表全拉到客户端）
- 并发时可能被其他客户端修改，导致覆盖写入
- 没有原子性，失败后原数据可能已丢失
- Redis 单线程处理大
RPUSH会阻塞其他命令
所以，除非列表极小（
替代方案：改用有序集合（ZSET）或哈希（HASH）
如果业务本质需要“按顺序维护、并频繁在中间增删”，Redis 原生列表（LIST）就是错的选型。更合适的是：
-
ZSET：用分数（score）模拟逻辑位置，ZADD插入时设中间分数（如前后分数是 10 和 20，新元素设 15），天然支持范围查询和排序 -
HASH：把每个“位置”存成字段（pos_0,pos_1...），配合HLEN+HSCAN管理，适合稀疏或需随机访问的场景 - 实在要用 LIST，就把“锚点值”设计成稳定标识（如用户 ID 字符串），而不是临时内容（如“待审核”这种状态值，容易重复或消失）
记住：LINSERT 的锚点不是占位符，是真实数据。一旦那个值被 LREM 或别的命令删掉，所有依赖它的插入逻辑就断了。
