列表切片会触发完整拷贝，因为Python中data[i:i+1000]并非返回视图，而是分配新内存并逐个复制对应元素，导致每次操作均为O(k)时间与空间复杂度；对百万级列表分页时，实际是“造一份”而非“取一段”。
为什么列表切片会触发完整拷贝
当你写 data[i:i+1000] 时，Python 必须分配新内存、复制对应元素、返回新列表——哪怕你只读不改。对百万级 list 做分页，每次切片都是 O(n) 时间 + O(n) 内存开销，不是“取一段”，而是“造一份”。
为什么 in 查找在循环里特别危险
if x in big_list: 看似简单，实为线性扫描；嵌套在外部 for 循环中，直接变成 O(n²)。比如遍历 10 万条记录，每条都查一个 5 万元素的白名单，实际执行 50 亿次比较。
- 正确做法：把
big_list转成set（元素可哈希）或dict.fromkeys(big_list).keys()（需保持顺序） - 注意：
set构建是 O(n)，别在循环里反复调用 - 字符串成员检查也适用——
'error' in line比line.find('error') != -1稍慢但更可读，问题不在单次，而在高频嵌套
为什么 append 在长循环里隐式扩容
空列表 result = [] 反复 append，Python 会按 1.125 倍策略预分配空间，但频繁扩容仍导致多次内存重分配 + 元素搬运。尤其当最终长度已知（如处理固定行数文件），预分配能省下 20%+ 时间。
- 能预估长度？用
result = [None] * expected_len，再用索引赋值 - 不确定长度？优先用生成器表达式
(process(x) for x in data)，避免中间容器 - 真要累积结果？
list.extend()比多次append()更少扩容次数
为什么修改正在迭代的列表会跳过元素
for x in numbers: 底层靠迭代器按索引推进；numbers.remove(x) 后，后续元素前移，但迭代器已跳到下一个索引，导致漏判。
立即学习“Python免费学习笔记（深入）”；
- 安全删除：用列表推导式
numbers = [x for x in numbers if not should_drop(x)] - 需要原地修改且不能重建？反向遍历
for i in range(len(numbers)-1, -1, -1): - 最易错场景：一边遍历一边
pop()或insert()，几乎必然出错
真正卡住性能的，往往不是某一行代码多慢，而是“看起来无害”的操作在循环上下文里被放大了数量级。尤其是切片、in、append 这三类，写的时候很自然，跑起来才发现内存爆了或跑了十分钟。
