sum()比手写for循环快，因其是C实现的内置函数，跳过Python字节码解释和帧创建开销，在C层直接遍历累加；对纯数字列表通常快2–5倍，但带条件时生成器表达式可能更慢。
为什么 sum() 比手写 for 循环快？
因为 sum() 是 C 实现的内置函数，跳过了 Python 字节码解释和每次循环的帧创建开销。它在 C 层直接遍历迭代器、累加数值，没有 Python 层的 LOAD_NAME、INPLACE_ADD 等操作。
- 对纯数字列表，
sum()通常快 2–5 倍；元素越多，差距越明显 - 但若需带条件（如只加正数），用
sum(x for x in data if x > 0)反而可能更慢——生成器表达式本身有额外开销，此时手写for更可控 -
sum()要求所有元素支持+，且初始值默认为0；传入字符串或自定义对象容易触发TypeError: unsupported operand type(s)
len() 为什么几乎不耗时？
Python 容器（如 list、tuple、str）内部都缓存了长度值，len() 只是读一个 C struct 字段，不遍历、不计算。
- 无论列表有一万个元素还是一个，
len(my_list)耗时基本恒定（纳秒级） - 但自定义类若没实现
__len__，或实现里写了return len(self._data)这种嵌套调用，就失去这个优势 - 别用
for i in range(len(lst)):来“优化”索引访问——这多了一次len()调用（虽快）+ 一次range构造，不如直接for item in lst:
内置函数快，但不是万能加速器
快的前提是：输入类型匹配、语义契合、无隐式转换。一旦打破，反而引入额外成本。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
-
max()对小列表快，但对大列表 + 自定义key，性能会逼近手写循环（因每次比较都要调用 Python 函数） -
sorted()返回新列表，list.sort()原地排序——后者少一次内存分配，多数情况应优先选sort() -
str.join()快，是因为预计算总长、单次分配内存；但若传入生成器（如''.join(str(x) for x in nums)），就得先转成 tuple/list，失去优势 - 用
map(int, str_list)不一定比列表推导快，尤其当int调用涉及异常处理时，C 层无法短路，错误仍要抛到 Python 层
真正影响速度的，往往是算法层级
内置函数再快，也救不了 O(n²) 的误用。比如用 item in list 做高频查找，不管 in 多快，本质仍是线性扫描。
立即学习“Python免费学习笔记（深入）”；
- 查存在性：
list→O(n)，换成set→O(1)平均，这才是质变 - 字符串拼接：反复
+=是 O(n²)，不是因为+=慢，而是每次都在新建对象；改用list.append()+''.join()才是正解 - 不要为了用内置函数而扭曲逻辑，比如硬把字典计数写成
dict(zip(keys, map(...)))——可读性和实际性能都可能下降
