不能用 SADD 对 List 去重后再存入 List，因为 SADD 操作 Set 而 List 无序不支持去重，混用会导致顺序丢失、性能下降和并发不一致。
直接说结论：不能用 SADD 对 List 去重后再“存入 List”，因为 List 本身不支持去重，而 SADD 操作的是 Set —— 这是两种完全不同的数据结构，混用会导致逻辑错乱、数据丢失或额外维护成本。
为什么 SADD 和 List 不能串着用
SADD 只能往 Set 中添加元素，自动去重；List 是有序、可重复的链表结构，没有内置去重能力。常见错误是想“先用 SADD 过一遍数据，再把 Set 结果塞进 List”，但这样会丢失原始顺序（Set 无序），且多一次遍历 + 写入，反而更慢。
- Set 里存的是去重后的无序集合，无法还原插入顺序或频次
- 从 Set
SMEMBERS再LPUSH到 List，是 O(N) 额外开销，N 大时延迟明显 - 并发写入时，
SADD+LPUSH不是原子操作，可能产生中间态不一致
真正需要去重+保序时该用什么
如果业务既要避免重复、又要保持插入顺序（比如用户最近浏览的 100 个商品 ID），优先考虑组合方案而非强行套用单一类型：
- 用
SET记录是否已存在（如viewed:{uid}），每次SISMEMBER+LPUSH，只对新元素操作 - 用
LIST存顺序，SET做查重缓存，两者 key 关联（如都带{uid}后缀） - 若需严格原子性，封装成 Lua 脚本：
EVAL "if not redis.call('sismember', KEYS[1], ARGV[1]) then redis.call('sadd', KEYS[1], ARGV[1]); redis.call('lpush', KEYS[2], ARGV[1]); end" 2 viewed:123 list:123 456
大量重复数据写入 List 的实际瓶颈在哪
性能问题通常不出在“重复”本身，而出在 List 的底层实现和访问模式：
-
LPUSH/RPUSH本身很快，但LLEN或LRANGE全量读取大 List 是 O(N)，容易拖垮连接 - Redis List 底层用双向链表 + 压缩列表（ziplist），当单个元素 > 64 字节 或 总长度 > 512 项时，会转为链表，内存放大明显
- 高频
LPOP/RPOP+LPUSH做队列？直接换Blocking Pop（BLPOP）或考虑 Stream
真正要优化的不是“怎么去重后塞进 List”，而是明确：这个数据到底需不需要顺序？要不要实时去重？能不能接受最终一致性？——选型错一步，后面全是补丁。
