同样的功能，别人用Python三行搞定，你却需要十行循环。差别不在智力，而在对语言特性的理解。很多人把Python当成逐行执行的脚本，却忘了它天生自带的表达力。今天我想讲五个效率技巧，它们不是花哨的黑魔法，而是能让你在写代码时少走弯路、在调试时少揪头发的实用工具。第一个值得记住的结论是：写代码快不等于效率高，调代码快才是真的高效。
推导式：把循环压缩成一行的艺术
先从一个最常见的场景说起：你需要从一个列表里挑出所有偶数，并把它们平方。新手会写一个for循环，先初始化一个空列表，然后append。老手会写一行：[xx for x in nums if x % 2 == 0]。这就是列表推导式的魅力。它把“创建一个新容器”“遍历”“筛选”“变换”四件事压缩进一个表达式里，读起来就像在说人话：对每一个x，如果它是偶数，就把它平方。推导式让“先建空列表，再循环append”这种过时写法无处遁形。
你可能觉得这只是语法糖，但它的价值远超表面。推导式不仅在语义上更紧凑，在性能上也通常快于普通的for循环，因为它是在C层面优化迭代的。更重要的是，它减少了中间变量的数量，也就减少了出错的机会。你不需要在一个循环体里维护多个状态，只需要关注“输入变成输出”的规则。字典推导式和集合推导式同样值得善用，比如快速交换字典的键和值：{v: k for k, v in original.items()}。一行代码，清晰，优雅，还自带可读性。
不过，推导式也有使用边界。当你发现一个推导式超过两行，或者里面嵌套了三层循环，它就会变成一场灾难。效率的本质不是把代码写短，而是让每个看到它的人都能更快地理解它。所以，适度使用推导式，配合良好的变量命名，才是真正高效的选择。
生成器：内存友好的迭代艺术
如果说推导式帮你在“空间”上压缩代码，那么生成器帮你在“内存”上压缩数据。假设你要处理一个10GB的日志文件，逐行读取时使用readlines()会把整个文件读入内存，机器直接卡死。而用生成器表达式或带yield的函数，你可以每次只取一行，处理完再取下一行。它不会一次性生成所有结果，而是按需生产。生成器不是不占内存，而是让你不再需要把整个宇宙装进内存。
这种惰性求值的思想，在处理无限序列或大数据流时特别有用。比如你想产生一个永不停止的斐波那契数列，用列表根本无法实现，但生成器却可以。它允许你写出“看起来像是整体”的程序，实际上却是流式运行的。更重要的是，生成器与Python的迭代协议无缝配合，你可以把它们塞进for循环、传给sum()、用next()手动推进。惰性不是拖延，而是一种对资源的敬畏。
但生成器也有个容易踩的坑：它们是一次性的。遍历完后，再想遍历就得重新创建。很多人在这里栽跟头，以为生成器就是个节省内存的列表，结果用第二次时发现什么都拿不到。所以，当你需要一个可以反复访问的数据集时，别用生成器；当你只需要顺序处理一遍时，生成器是效率之王。懂了这一点，你就掌握了内存与灵活性之间的取舍。
f-string：字符串格式化的效率革命
字符串拼接是Python开发里最常见的“暗坑”。用加号拼接多个变量，写起来啰嗦，还得小心类型转换；用%格式化，参数多了容易错位；用.format()，虽然灵活但冗长。直到Python 3.6引入了f-string，这一切才终于有了最优雅的解法。f"用户{name}的ID是{user_id:08d}"看起来就是一段普通文本，但你在花括号里可以直接嵌入表达式，甚至调用函数。f-string的流行不是偶然，是无数个拼接事故换来的必然。
f-string的效率不仅体现在书写速度上，它比%和.format()都要快，因为它在编译期就解析成FORMAT_VALUE指令，运行期几乎零开销。调试时，你可以直接在f-string里写上f"变量x的值是{x}"，不用再为打印信息额外写一堆字符串函数。这种便利，会让你在回报bug时更愿意输出清晰的上下文，从而更快定位问题。
有人会说，格式化字符串而已，能有什么技术含量？但真正的效率，往往藏在最不起眼的日常代码里。一个每次省三分钟、每天用几十次的技巧，累积起来就是一笔巨额财富。当然，如果字符串要求更复杂的模板结构，可以考虑string.Template或第三方库，但普通开发场景下，f-string已经足够了。记住，你的时间应该花在解决问题上，而不是纠结该用单引号还是双引号拼接。
上下文管理器：你和资源泄漏之间的最后一道防线
打开文件却忘了关闭，连接数据库却没释放，这种错误几乎每一个Python开发者都犯过。以前我们写try...finally来保证资源被释放，但代码变得又臭又长。with语句的出现，让“打开-操作-关闭”变成了一个语言结构。你不用再记着最后要close()，因为上下文管理器会在离开with块时自动完成清理。上下文管理器让你把“打开-操作-关闭”变成一种语言结构。
更妙的是，你可以自定义上下文管理器。用contextlib.contextmanager装饰一个生成器函数，把需要初始化的代码放在yield之前，清理代码放在yield之后。比如一个临时切换当前目录的上下文，或者一个计时器，都能用几行代码实现。这种能力让你的代码既安全又富有表达力。真正的效率，是让那些容易忘记的事情自动发生。
但要注意，上下文管理器不是万能保险。如果你在with块里捕获了所有异常，然后又继续执行，资源清理的时机可能比你想象的晚。另外，with只对资源管理负责，不负责业务逻辑的复杂度。别指望一个魔法工具能拯救混乱的设计。但至少，它把最常见的“忘记释放资源”这个问题，从你的脑海里彻底删除了。这就是效率：少一个需要记住的细节，多一分专注主逻辑的清醒。
itertools与functools：标准库里的效率涡轮增压器
许多开发者沉迷于装第三方包，却忘了Python标准库里藏着两个效率神器：itertools和functools。前者提供的chain能一次遍历多个序列，product能生成笛卡尔积，permutations能枚举排列，accumulate能计算累加值。后者提供的lru_cache能自动缓存函数计算结果，partial能固定函数的某些参数，reduce能把一个序列持续折叠成一个值。itertools让你在组合爆炸的世界里，优雅地挑选每一种可能。
举个例子，你需要处理三个列表的所有组合，手写三层for循环不仅难看，还容易错。用product，一行代码就搞定。你需要计算一个列表的前缀和，accumulate也是现成的。这些函数不仅仅是工具，更是一种“声明式”的编程思路：你描述“要什么”，而不是“怎么做”。用现成的抽象，比你从零开始造轮子，安全一个量级。
特别想说lru_cache，它简直是为递归和动态规划而生的。比如计算斐波那契数列，不加缓存的递归会指数级爆炸，加上@lru_cache，同样的代码立刻变成线性复杂度。这就是效率的魔力：不需要改变算法逻辑，只增加一层智能记忆。当然，使用这些工具时要理解它们的限制，lru_cache在对象参数上容易因为不可哈希而报错，reduce也别用得过度导致不可读。工具再好，也架不住你拿着锤子把所有问题都看成钉子。但掌握了正确的用法，标准库本身就是一个微型涡轮增压器。
这五个技巧看起来各自独立，实际上共享一种效率思维：用语言自带的能力去解决问题，而不是用笨拙的体力劳动补拙。推导式让你描述数据变换，生成器让你驾驭数据规模，f-string让你清爽地输出日志，上下文管理器让资源管理自动兜底，标准库函数让你立于巨人的肩膀上。它们无法替代你对业务的思考，但能让你在思考业务时不被语言的细节绊倒。学会偷懒，才是程序员最该掌握的技能。所以，下一次当你准备写一个for循环时，先停三秒，想想有没有更Pythonic的做法。这五秒的思考，可能为你省下五小时的重构。代码的简洁不是目的，而是通往正确性和可维护性的捷径。愿你今后写的每一行Python，都既有力，又从容。
