del+rpush重建是最高效去重方式，适用于能获取全量去重数据的场景；必须配合expire重设过期时间，不适用于超大或持续写入的list。
直接用 DEL + RPUSH 重建是最高效的选择
如果你能拿到全部去重后的数据（比如应用层已用 Set 或 Stream 处理好），就别在 Redis 里做“原地去重”。DEL 原 key，再 RPUSH 新数据，是 O(1) 操作、原子、无残留、不阻塞主线程。
常见错误是硬写 Lua 遍历删重——List 没有内置去重命令，所有“边读边删”逻辑都要多次调用 LINDEX/LREM，网络往返多、非原子、高并发下极易漏删或重复插入。
-
DEL会清除原有过期时间，重建后必须立刻执行EXPIRE - 若 List 元素含特殊字符（如换行、空格），
RPUSH仍能正确处理，无需额外转义 - 不适用于超大 List（如百万级）或持续被其他客户端写入的场景——此时你拿不到“全量快照”
Lua 脚本在线去重必须用 SET 辅助保序
当必须维持服务连续性（比如任务队列不能中断），唯一可行方案是 Lua + SET：用 SET 记录已见元素，遍历 LRANGE 后逆序 LPUSH 到原 key，靠顺序还原保证原始插入序。
下面这段脚本是经过验证的最小可行实现：
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
local list = redis.call('LRANGE', KEYS[1], 0, -1)
local seen = {}
local unique = {}
for i = 1, #list do
if not seen[list[i]] then
seen[list[i]] = true
table.insert(unique, list[i])
end
end
redis.call('DEL', KEYS[1])
for i = #unique, 1, -1 do
redis.call('LPUSH', KEYS[1], unique[i])
end
return #unique
- 必须用
KEYS[1]传入 key 名，不可硬编码；ARGV在此场景中不参与 - 逆序
LPUSH是关键：因为LPUSH是头插，从尾到头插入才能让结果与原顺序一致 - 超过 10 万元素时，该脚本会阻塞 Redis 单线程，建议拆成每次 5000 条的小批次，由客户端轮询调用
别用 LREM 实现“留一删余”
LREM 的语义根本不支持去重逻辑：LREM key 0 "a" 是删光所有 "a"，LREM key 1 "a" 只删第一个匹配项——没有“删第二个起”的语法，也没有原子方式跳过首项删后续。
试图组合 LINDEX + LREM 实现去重，本质是模拟循环，需多次 Redis 往返，在并发写入下必然出错。错误现象包括：部分重复项残留、原顺序错乱、甚至误删非重复项。
- 脚本里调用
LREM无法规避竞争条件，因 Redis 单线程只保证单个命令原子，不保证多命令组合原子 - 哪怕加了
WATCH，List 的结构特性也让乐观锁失效——LREM改变长度后，后续索引完全不可靠
复杂对象去重要先提取唯一标识再进 SET
如果 List 存的是 JSON 字符串（如 {"id":"123","name":"foo"}），直接用整个字符串做 SADD 效率低且易冲突。正确做法是在 Lua 中解析或截取唯一字段，比如用 string.match 提取 id：
local json = list[i] local id = string.match(json, '"id"%s*:%s*"([^"]+)"') if id and not seen[id] then seen[id] = true table.insert(unique, json) end
但注意：Lua 内置 JSON 解析能力极弱，生产环境建议在应用层完成字段提取，只把精简后的唯一键（如 "123"）和完整数据分两路写入 SET 和 List。
- Redis 7.0+ 支持
JSON.GET，但 Lua 脚本中无法调用，只能靠字符串处理凑合 - 若唯一标识含分隔符（如
#、_），需提前约定并校验，避免string.match误切
