直接解包比索引访问更快，是因为解包在编译期生成unpack_sequence指令，直接按偏移量拷贝指针且无边界检查；而索引访问需两次__getitem__调用，含函数栈开销、边界校验及指针查找。
直接解包比索引访问更快，不是因为“语法糖优化”，而是因为少了一层对象引用跳转和边界检查。
解包是编译期结构映射，索引是运行时查表
当你写 a, b = my_tuple，CPython 在字节码生成阶段就确定了要取第 0 和第 1 个位置的引用，并直接生成 UNPACK_SEQUENCE 指令。这个指令从元组对象的内部数组里按偏移量拷贝两个指针到局部变量槽，全程不调用任何 Python 层方法，也不检查索引是否越界——因为长度匹配在赋值前已由解释器静态验证（否则抛 ValueError: not enough values to unpack）。
而 a = my_tuple[0]; b = my_tuple[1] 每次都要走完整的 __getitem__ 调用路径：先查 tp_as_sequence->sq_item 函数指针，再做边界校验（0 >= PyTuple_GET_SIZE(op)），最后才取 PyTuple_GET_ITEM(op, 0)。两次调用，两次校验，两次函数栈开销。
星号解包 *rest 的代价在哪？
看似灵活的 a, *rest, c = big_tuple 其实只在“中间部分”有额外开销：
-
a和c仍是 O(1) 直接取首尾引用 -
*rest必须构造新list对象，把中间所有元素逐个Py_INCREF并拷贝引用 —— 这是唯一真正耗时的操作 - 如果只是想跳过中间项（比如只取首尾），用
a, *_, c = big_tuple更轻量，_会被解释器识别为丢弃变量，不分配 list
元组长度未知时，别硬解包
解包快的前提是长度已知且匹配。如果从外部接收数据（如 JSON 解析结果、数据库行），贸然写 x, y, z = row 可能触发 ValueError，而 row[0] if len(row) > 0 else None 虽慢但可控。此时更推荐：
- 用
row[:3]切片 + 解包：x, y, z = row[:3] + (None,) * (3 - len(row[:3])) - 或直接上
operator.itemgetter(0, 1, 2)，它底层调用 C 函数，比多次[]略快
真正影响性能的从来不是“写法多一行还是少一行”，而是你是否清楚每个操作背后触达的是哪一层机制：是直接内存偏移，还是函数调用，还是新对象构造。解包快，是因为它尽可能贴近 CPython 的原始数据结构；一旦引入动态长度、类型转换或中间容器，优势就消失了。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
