列表推导式是解释器级优化，非语法糖；它绕过load_method和call_function指令，用c实现循环，比for+append快约50%，但受限于结构简单性、内存占用及无状态依赖等条件。
列表推导式 不是语法糖，是解释器级优化——它绕过了 Python 字节码中重复的 LOAD_METHOD 和 CALL_FUNCTION 指令，直接由 C 实现的底层循环驱动。用它替代 for + append，平均能省掉 50% 左右的每轮开销。
为什么 list.append() 在循环里特别慢
每次调用 append 都要：查方法对象、压栈、检查参数、触发内存扩容逻辑（可能触发 realloc）、更新长度计数。这些在纯 Python 循环中逐次发生，无法被 JIT 或提前优化。
-
append是动态绑定方法，每次循环都走属性查找路径（哪怕列表对象没变） - 列表预分配空间不生效——
append默认按 12.5% 增长策略扩容，小数据也触发多次 realloc - CPython 的
LIST_APPEND字节码虽快，但叠加函数调用开销后，仍比内置推导式多出约 16ns/轮（实测基线 32.158ns → 16.040ns）
列表推导式 的边界和陷阱
它快，但不是万能的。写错结构反而更慢，甚至报错。
- 嵌套过深（如
[x for a in A for b in B for c in C]）会退化为多层 Python 循环，失去优势；此时应改用itertools.product - 含复杂语句（如赋值、
try、yield）不能写进推导式，强行拆出会破坏可读性，不如保留显式for -
if条件放推导式里（[x for x in data if x > 0]）比在循环内if快；但条件本身很重（如调用函数），应先提取变量 - 别对生成器或大文件迭代器用列表推导式——它会强制展开全部，吃光内存；该用生成器表达式
(x**2 for x in data)
什么时候必须放弃 列表推导式
它只适合“输入→变换→收集”这一种模式。一旦涉及状态累积、跨元素依赖、副作用（如日志、IO、缓存更新），就该换思路。
- 需要累计中间状态？用
functools.reduce或显式变量累加 - 要边算边写文件？用普通
for+write()，推导式无法插入 IO 调用 - 结果需去重且保持顺序？
list(dict.fromkeys(data))比推导式 +set查重更稳（避免重复哈希） - 计算依赖前一项（如滚动均值）？必须用
for，推导式没有“上一轮变量”的概念
data[i] *= 2）无法用它表达。这种场景下，哪怕慢一点，for i in range(len(data)): 仍是更安全的选择。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
