嵌套三层以上列表推导式严重降低可维护性，应拆为生成器函数或循环；禁用副作用；if过滤置末、if-else取值置首；大列表慎用推导式以防内存峰值。
嵌套三层以上的列表推导式会直接降低可维护性
超过两层嵌套的列表推导式，人眼解析成本陡增，调试时几乎无法快速定位哪一层漏了括号或搞错了顺序。这不是风格偏好，是认知负荷的硬限制。
- 两层嵌套（如
[x for row in matrix for x in row]）尚可接受，对应常见展平操作 - 三层（如带条件过滤+展平+转换）建议拆成生成器函数或普通循环——
itertools.chain或显式for循环反而更直白 - 若坚持用三层推导，必须加括号分组并换行对齐，但即便如此，PyCharm 和
black都会警告“line too long”或“complex comprehension”
带副作用的表达式放进列表推导式里是危险信号
列表推导式本质是纯表达式，不该承担 print()、file.write()、修改外部变量等动作。一旦这么写，代码行为就和直觉严重偏离。
- 例如
[print(x) for x in items]看似“遍历打印”，实则生成一个全是None的列表，且容易被误删（因为返回值没被接收） - 真正想“执行动作”，该用
for循环；想“收集结果”，才用推导式——二者目的不同，混用等于自埋逻辑歧义 - 静态检查工具（如
pylint）会报expression-not-assigned，不是小题大做，是提示你语义错位
if 和 if-else 在推导式里的位置差异极易出错
过滤条件（if）必须放在推导式末尾，而三元表达式（if-else）必须放在开头作为值生成部分——放反就会语法错误或逻辑翻车。
- 过滤写法：
[x for x in nums if x > 0]——if在最后，不带else - 变换写法：
["pos" if x > 0 else "neg" for x in nums]——if-else在最前，是整个元素的取值逻辑 - 常见错误：
[x if x > 0 else 0 for x in nums if x != 0]看似合理，但一旦nums含None，x > 0就抛TypeError，而这个错误在过滤前就触发了
大列表推导式可能引发内存峰值，但不是所有场景都得立刻换生成器
推导式生成的是完整列表，如果源数据大且后续只遍历一次，用生成器表达式（(...)）更省内存；但如果要多次索引、切片或传给需要 len() 的函数，强行改生成器反而增加复杂度。
立即学习“Python免费学习笔记（深入）”；
- 能用
[x*2 for x in big_list]就别写(x*2 for x in big_list)—— 除非你确认后续只迭代一次且内存敏感 -
list(...)包裹生成器表达式会抵消内存优势，还多一层调用开销 - 注意：
map()和filter()返回迭代器，但 Python 3 下它们本身不缓存结果，和生成器行为一致；是否替换取决于你是否需要惰性求值
可读性不是靠删空格或换行就能救回来的，它取决于你有没有把“人怎么想”和“机器怎么算”分开处理。越想在一个推导式里塞进所有逻辑，越容易在两周后看不懂自己写的啥。
