lpush + lpop 是实现栈的核心组合，因二者均操作列表左端，天然满足lifo语义；混用lpush与rpop会变成fifo，而rpush+rpop虽可行但违背主流直觉与文档惯例。
LPUSH 和 LPOP 是实现栈的核心组合，所有操作集中在列表左端，天然满足 LIFO（后进先出）语义。
为什么用 LPUSH + LPOP 而不是其他组合？
栈要求“最后压入的元素最先弹出”，必须保证入和出在同一个端点。如果混用 LPUSH 和 RPOP，就变成 FIFO 了；用 RPUSH + RPOP 也行，但实际中几乎没人这么写——因为 LPUSH/LPOP 更符合“栈顶在左”的直觉，且 Redis 官方文档和主流 SDK（如 redis-py、Jedis）示例都默认采用左侧操作。
LPUSH 插入时多个值的顺序容易搞反
执行 LPUSH stack a b c 后，列表实际是 ["c", "b", "a"]，不是 ["a", "b", "c"]。这是因为 Redis 从左往右依次插入：先插 a（位置 0），再插 b（挤到位置 0，原 a 变成位置 1），最后插 c（变成位置 0）。所以批量压栈要小心顺序，必要时拆成多次单元素 LPUSH。
空栈调用 LPOP 返回 nil，不是报错
这是关键行为差异：LPOP 在列表为空时不抛异常，而是返回 nil（或 null，取决于客户端）。这意味着你必须显式检查返回值，不能依赖异常捕获来判断栈空。例如 Python 中：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
r.lpush('stack', 'x')
val = r.lpop('stack') # val == b'x'
val = r.lpop('stack') # val == None
常见错误是直接解包或类型断言，导致 TypeError。
阻塞式弹栈要用 BLPOP，但注意它不支持纯栈语义
BLPOP stack 0 确实能阻塞等待，但它返回的是 [key, value] 二元组，且一旦有数据就立即返回——这没问题。但陷阱在于：BLPOP 是“弹出并返回”，不可逆；如果你需要“ peek + pop”两步（比如先看栈顶再决定是否弹出），Redis List 没有原子化的 LPEEK 命令，得靠 LINDEX stack 0 配合业务逻辑处理，而这两步之间可能被并发修改。
真正要注意的，是“栈顶”这个概念只存在于你的使用约定里——Redis 本身没有栈类型，LPUSH/LPOP 只是普通命令。一旦有人误用 RPOP 或 LRANGE 修改中间元素，整个栈结构就破坏了。生产环境建议用专用 key 命名（如 job:stack:worker-123）并配合监控 LLEN 异常波动。
