Python内置函数是类型协议的快捷入口，如len()调用__len__()、max()依赖__iter__()和比较方法，理解此机制可避免参数类型错误与兼容性问题。
Python内置函数不是“功能列表”，而是“类型协议的快捷入口”
Python的内置函数（BIF）绝大多数不是独立实现的逻辑，而是对对象__len__、__iter__、__lt__等特殊方法的统一调用封装。比如len(x)实际触发x.__len__()，max(x)依赖x.__iter__()和元素间的__gt__或__lt__。理解这点，才能避开“为什么len()对dict快但对生成器报错”这类困惑。
常见错误现象：TypeError: object of type 'generator' has no len()——因为生成器没实现__len__；TypeError: 'int' object is not iterable出现在sum(42)里，是因为sum()要求第一个参数可迭代，而数字不是。
-
len()只认实现了__len__的对象（list、str、dict、tuple、set都行，generator、int、float不行） -
max()/min()要求所有元素支持比较（1 > 'a'在Python 3会直接报TypeError，不靠内置函数也能暴露问题） -
sum()默认初值是0，所以参数必须是数字类型；若要拼接字符串或列表，得显式传start参数，如sum(['a','b'], start='')或sum([[1],[2]], start=[])
len/max/min/sum这四个最常用BIF的参数陷阱
它们看着简单，但参数结构差异大，混用容易出错。尤其注意max()和min()有两种签名：max(iterable, *, key=None) 和 max(a, b, *args, key=None)——前者接受一个可迭代对象，后者接受多个位置参数。写成max([1,2,3], [4,5])不会比大小，而是比较两个列表对象本身（按字典序），且返回的是[4,5]这个列表，不是5。
-
len()只接受一个参数，且必须有__len__方法；传None或自定义类但没实现该方法，直接TypeError -
sum()第一个参数必须是可迭代对象，第二个参数start是可选的初始值（默认0）；误写成sum(1, 2, 3)会报TypeError: sum() takes at most 2 arguments -
max()和min()如果只传一个空可迭代对象（如max([])），抛ValueError: max() arg is an empty sequence；加default=...参数可避免（Python 3.4+） - 所有这四个函数都不支持
None混入数值序列：例如max([1, None, 3])在Python 3中直接报错，不是返回3
性能和兼容性：别在热路径上用BIF替代手写循环
sum()对纯数字列表确实比手写for快，因为它在C层展开；但一旦涉及key函数（如max(items, key=lambda x: x.price)），开销就接近手动遍历——因为每个元素都要调用lambda。更隐蔽的问题是兼容性：len()在Python 2里能用于file对象（返回剩余字节数），但在Python 3中已移除该行为，len(f)现在一定报错。
- 对小列表（sum()和手动累加性能差别可忽略；对大数组，用
numpy.sum()比sum()快10倍以上 -
max()带key时，内部仍是一次遍历，但函数调用开销存在；若key计算昂贵，先预计算再用max(zip(keys, items))可能更稳 -
len()对list/dict是O(1)，但对某些自定义类（比如懒加载的数据库查询结果），__len__可能触发全量fetch，这时len()就不是“廉价操作”了
哪些内置函数容易被当成“工具函数”却其实不该这么用
像all()、any()、reversed()、sorted()也常被列进“常用BIF”，但它们的行为边界更模糊。比如reversed()返回的是迭代器，不是新列表；sorted()返回新列表，而list.sort()才原地排序——混淆这两者会导致“为什么我的列表没变”这类问题。
-
reversed(seq)不支持所有序列类型：它要求对象有__reversed__或支持__len__+__getitem__；range对象有__reversed__，但自定义类若只实现__iter__，reversed()会失败 -
sorted()的key函数若返回None，排序时会被当作0（Python 3.8+），但这是隐式行为，不推荐依赖 -
all()和any()对空可迭代对象分别返回True和False——这个逻辑反直觉，但符合数学定义；写if all(items):前得确认items非空，否则永远为真
真正需要警惕的，是把BIF当黑盒去套用。它们省代码，但不省思考；多数时候，错不在函数，而在没看清它背后调用的是哪个__xxx__方法。
