redis set底层使用intset或hashtable实现：1. 元素全为整数且数量≤512时用intset（升序存储，与插入顺序无关）；2. 否则用hashtable（哈希槽位决定位置，不记录插入顺序），因此set天然无序。
Redis Set底层用哈希表或intset，天然不维护顺序
Set不保证插入顺序，根本原因在于它的底层实现不是链表或数组这类有序结构。当元素全是整数且数量 ≤ 512（默认值，由 set-maxintset-entries 控制）时，Redis 用 intset；否则切换到哈希表（dict）。两者都以“快速判重+O(1)查找”为目标，而非记录插入位置。
哈希表靠 hash(key) 决定存储槽位，intset 虽是紧凑数组，但内部按数值升序排列——这和插入顺序无关，只和元素值有关。所以哪怕你按 sadd key a b c 插入，smembers key 返回的顺序可能是 c a b，甚至每次执行都不一样。
List用QuickList，天然保持插入顺序
List 的底层是 QuickList（双向链表 + 压缩列表 ziplist 的组合），每个节点按写入时间前后链接，lpush、rpush、linsert 等操作都明确作用于头/尾/指定索引位置。因此 lrange key 0 -1 总能稳定返回插入顺序。
这种设计代价是：查找某个值是否在 List 中必须遍历，时间复杂度 O(n)；而 Set 查 sismember key xxx 是 O(1)。顺序保障和查找效率，在这里是一对互斥目标。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
用错场景时的典型错误现象
把 Set 当作“去重版 List”来用，结果发现：
-
smembers返回顺序不稳定，前端渲染或日志打点出现乱序 - 想取“最新加入的 5 个用户”，却无法用类似
lrange的方式获取最后插入项 - 用
sinter计算两个标签交集后，再试图按“共同关注时间先后”排序，发现原始时间信息已丢失
这些都不是 bug，而是数据结构语义决定的必然行为。Set 只回答“有没有”，不回答“什么时候加的”或“加在第几位”。
需要顺序 + 去重时该选什么
没有银弹，得看具体需求：
- 要严格插入顺序 + 去重 → 用
LinkedHashSet（应用层）或 Redis +ZSET（score 设为时间戳，用zrevrange拿最新） - 只要去重 + 集合运算 → 死守
Set，别碰顺序假设 - 要顺序 + 允许重复 →
List或Stream
最容易被忽略的一点：Set 的“无序”不是随机打乱，而是“不承诺任何顺序”。它可能某次返回 A B C，下一次还是 A B C，但你绝不能依赖这个表现——因为升级 Redis、内存碎片变化、甚至 intset 切换到哈希表，都可能让顺序突变。
