应使用 LRANGE 取首尾元素而非 LINDEX，因 LINDEX 时间复杂度为 O(N)，而 LRANGE 0 0 和 -1 -1 均为 O(1) 且语义明确；空列表时返回空数组，需判空防越界。
用 LINDEX 取首尾元素？别这么干
LINDEX 确实能取任意索引位置的元素，但拿它专门取首尾，属于“杀鸡用牛刀”。Redis 为 List 的头尾操作提供了更轻量、更语义清晰的原生命令：LPOP/RPOP（带删除）和 LPACK/LRANGE（只读）。LINDEX 内部仍需遍历链表节点，时间复杂度是 O(N)，而首尾访问本应是 O(1) —— 用错指令会让性能从常数退化成线性。
常见错误现象：LINDEX mylist 0 和 LINDEX mylist -1 能跑通，但压测时延迟突增、CPU 升高；尤其当 List 很长（上万元素）时，LINDEX 会明显拖慢响应。
- 取首元素（不删）：用
LRANGE mylist 0 0，返回单元素数组，再取第一项 - 取尾元素（不删）：用
LRANGE mylist -1 -1 - 想取完就删：直接
LPOP/RPOP，原子且高效 - 如果必须用索引（比如中间某位），才考虑
LINDEX，且要确认 List 长度可控
LRANGE 取首尾的边界细节
LRANGE 是安全取首尾的首选，但它对负索引和空 List 的处理容易踩坑。Redis 中负索引从 -1 开始（尾），-2 是倒数第二，以此类推；但若 List 为空，LRANGE mylist 0 0 返回空数组 []，不是 null 或报错 —— 客户端代码若没判空，可能触发下标越界。
- 空 List 执行
LRANGE key 0 0→ 返回[]，不是nil -
LRANGE key -1 -1在空 List 下同样返回[] - 索引超出范围（如
LRANGE key 100 100）也返回[]，行为统一 - Python 客户端示例：
r.lrange("mylist", 0, 0)返回[b"first"]或[]，需先检查长度再取[0]
为什么不用 LLEN + LINDEX 组合？
有人想“先 LLEN 拿长度，再 LINDEX key len-1 取尾”，逻辑看似严谨，但实际引入竞态和冗余开销。LLEN 和 LINDEX 是两个独立命令，中间 List 可能被其他客户端修改（增/删），导致 LINDEX 访问越界或取到错误位置；同时多一次 round-trip，延迟翻倍。
-
LLEN时间复杂度 O(1)，但无法解决并发修改问题 -
LINDEX key -1本身就能定位尾部，无需长度计算 - 若真需要长度 + 尾元素，应改用 Lua 脚本保证原子性，但多数场景没必要
- Node.js 示例中直接写
client.lrange("mylist", -1, -1)比client.llen(...).then(len => client.lindex("mylist", len-1))更稳更快
不同语言客户端对返回值的处理差异
各 Redis 客户端对 LRANGE 返回格式不完全一致，容易在解包时出错。核心差异在于：是否自动展开单元素数组、是否转字符串、空结果怎么表示。
- redis-py：
r.lrange("k", 0, 0)返回[b"val"]，需decode()或用encoding="utf-8"初始化连接 - node-redis（v4+）：
client.lRange("k", 0, 0)返回["val"]（字符串数组），但空时是[] - go-redis：
client.LRange(ctx, "k", 0, 0).Val()返回[]string，空时是空切片，不是nil - 所有客户端中，
LRANGE key 0 0和LRANGE key -1 -1的返回结构一致，可复用同一套解析逻辑
真正麻烦的是负索引在极短 List 中的行为：比如 List 只有 1 个元素，LRANGE key -2 -2 返回 []，而不是报错 —— 这个“静默失败”容易被忽略，调试时得盯住实际返回长度。
