我写代码写了快十年见过太多把十行代码能搞定的事写成一百行的项目。Python 这门语言很有意思它的“隐藏功能”往往不是那种偏门得一辈子用不上的特性而是藏在标准库里、每个正经开发者都应该顺手用上的工具。今天挑 6 个我用得最频繁、性价比最高的功能全部来自标准库不需要装任何第三方包每一个都能实打实帮你砍掉一半样板代码。这篇内容适合刚入门 Python 没多久、想写出更地道代码的新人也适合写了两三年 Python 但一直用 C 风格写法的朋友看完可以直接抄进自己的项目。1. 灵活到犯规的参数传递*args与**kwargs很多人学函数的时候见过这两个写法但只是“知道”根本没用起来。实际这两个东西是 Python 函数设计的灵魂你能用它写出高度复用的通用代码。1.1 不只是“随便传几个参数”这么简单先明确概念。*args把所有多余的位置参数打包成一个元组**kwargs把所有多余的关键字参数打包成一个字典。这个机制最大的价值在参数转发场景。举个例子你写了一个日志装饰器希望被装饰的函数不管长什么样都能原样收到自己的参数import functools def log_call(func): functools.wraps(func) def wrapper(*args, **kwargs): print(f调用 {func.__name__}, 参数: {args}, {kwargs}) return func(*args, **kwargs) return wrapper没有*args, **kwargs这个装饰器根本写不出来——你不可能知道将来装饰的函数需要几个参数。这就是转发最典型的使用场景。1.2 定义通用接口一份代码服务多种入口我前阵子做一个数据同步工具需要从不同数据源拉数据然后统一做清洗和入库。每个数据源的连接参数完全不一样MySQL 要 host、port、user、passwordHTTP 接口要 url、headers、timeout如果给每个数据源单独写一个函数代码会膨胀得非常快。用**kwargs可以做一个统一入口def load_data(source_type: str, data_path: str, **kwargs): if source_type mysql: host kwargs.get(host, localhost) port kwargs.get(port, 3306) user kwargs.get(user) # 连接数据库... elif source_type api: url kwargs[url] headers kwargs.get(headers, {}) timeout kwargs.get(timeout, 30) # 请求接口... ...调用的时候既可以用load_data(api, data_path, url..., timeout10)也可以用load_data(mysql, data_path, host..., port3307)。新数据源加一个分支就行旧调用方完全不用改。这种扩展性就是**kwargs给的。1.3 参数解包从列表和字典里直接展开除了在定义函数时打包参数在调用函数时还可以解包。这个配合使用起来相当顺手def draw_chart(title, x_data, y_data, **style): ... config { title: 月度销量, x_data: [1, 2, 3], y_data: [30, 45, 22], color: blue, grid: True, } draw_chart(**config) # 字典自动展开成关键字参数配置文件里写好参数一行**config全传过去代码立刻清爽。我个人的习惯是凡是参数超过三个的函数都倾向于用关键字参数组织凡是和外部配置对接的场景优先考虑**kwargs接纳额外字段。这套东西配合 type hints 使用既灵活又不失可读性。2. 数据类的救星dataclass写 Python 最痛苦的样板代码之一就是定义一个“装数据的类”。以前你得手动写__init__、__repr__、__eq__一个简单的数据结构能写出三十行全是套路的内容。Python 3.7 开始内置的dataclasses模块把这件事彻底简化了。2.1 从 30 行样板到 5 行声明先看传统写法class Product: def __init__(self, name, price, stock): self.name name self.price price self.stock stock def __repr__(self): return fProduct(name{self.name}, price{self.price}, stock{self.stock}) def __eq__(self, other): if not isinstance(other, Product): return NotImplemented return (self.name, self.price, self.stock) (other.name, other.price, other.stock)再看 dataclass 写法from dataclasses import dataclass dataclass class Product: name: str price: float stock: int 0__init__、__repr__、__eq__全自动生成还自带类型注解。代码量差了整整一个数量级。在数据清洗、接口返回结构管理、配置项管理等场景里这个功能几乎每天都在用。2.2 更进阶的玩法field与__post_init__dataclass 真正的威力在于field这个工具。比如列表这种可变默认值直接写items: list []会踩共享引用的坑所有实例共用同一个列表。正确做法是from dataclasses import dataclass, field from typing import List dataclass class Order: id: int items: List[str] field(default_factorylist)default_factory会在每个实例创建时生成一个新的空列表这个细节不知道坑了多少人。再比如数据校验__post_init__允许你在初始化完成后自动跑一段逻辑dataclass class Temperature: celsius: float fahrenheit: float field(initFalse) def __post_init__(self): self.fahrenheit self.celsius * 9 / 5 32再比如把从接口拿到的原始 dict 转换成结构清晰的对象配合**data一行搞定。这些都是我实际项目里高频出现的场景用 dataclass 之后代码的可读性提升非常明显。3. 标准库里躺着的高级函数库itertoolsitertools是我最喜欢的 Python 隐藏宝藏它把很多“你能想到但懒得写对”的循环逻辑封装成了现成函数。用它的核心收益不是性能当然性能也很好而是消灭嵌套循环。3.1product帮你去掉三层 for以前要生成所有组合新手会写三层嵌套循环for a in list_a: for b in list_b: for c in list_c: process(a, b, c)现在一行from itertools import product for a, b, c in product(list_a, list_b, list_c): process(a, b, c)这不是简单的语法糖。product是 C 语言实现的迭代速度比纯 Python 嵌套循环快不少。更重要的是它从结构上消灭了缩进地狱代码一眼就能看出“这是在遍历三个集合的笛卡尔积”。3.2combinations与permutations算法题的搬运工需要从列表里选所有两两组合以前你得写两个 for 循环还要处理索引去重。现在from itertools import combinations teams [alpha, beta, gamma, delta] for pair in combinations(teams, 2): print(pair) # (alpha, beta), (alpha, gamma) ...排赛程、做关联分析、算特征组合全是它在干活。类似的还有permutations处理排序场景combinations_with_replacement处理可重复选择场景。这些都是数学上写清楚、但代码实现容易出错的操作现在直接调用就完事。3.3chain与groupby列表摊平与分组杀器chain可以把多个可迭代对象串成一个合并列表不必再用号或extendfrom itertools import chain all_items list(chain(list_a, list_b, list_c))如果是嵌套列表摊平用chain.from_iterablematrix [[1, 2], [3, 4], [5, 6]] flat list(chain.from_iterable(matrix)) # [1, 2, 3, 4, 5, 6]groupby则是把相邻的相同元素分组。注意它只对“连续相同”生效所以实际使用中一般先排序再分组from itertools import groupby records [ {city: 北京, sales: 100}, {city: 上海, sales: 90}, {city: 北京, sales: 80}, ] records.sort(keylambda x: x[city]) for city, group in groupby(records, keylambda x: x[city]): total sum(item[sales] for item in group) print(f{city}: {total})这段逻辑如果自己写 while 循环去处理连续相等判断很容易写出 bug。itertools的模块风格非常统一全部返回迭代器惰性求值内存占用极低处理几十万条数据也不怕。4. 一行搞定缓存functools.lru_cache递归函数和重复计算是性能杀手。比如经典的斐波那契数列不加缓存时间复杂度是 O(2^n)加缓存后直接降到 O(n)。functools.lru_cache正是干这个的加一个装饰器Python 自动帮你缓存所有计算结果。4.1 装饰器一挂递归立刻起飞from functools import lru_cache lru_cache(maxsizeNone) def fib(n): if n 2: return n return fib(n - 1) fib(n - 2)就这么简单。maxsizeNone表示不限制缓存条数算到 fib(400) 也就是一瞬间的事。没有装饰器时fib(40) 已经要等几秒了fib(100) 这辈子算不完。4.2 不只是递归动态规划的懒惰写法我做过一个编辑距离计算的工具用的是动态规划。传统写法要手动填表代码长还容易下标越界。用了lru_cache之后直接按递归语义写把中间结果交给缓存lru_cache(maxsizeNone) def edit_distance(s1, s2): if not s1: return len(s2) if not s2: return len(s1) if s1[0] s2[0]: return edit_distance(s1[1:], s2[1:]) return 1 min( edit_distance(s1[1:], s2), # 删除 edit_distance(s1, s2[1:]), # 插入 edit_distance(s1[1:], s2[1:]), # 替换 )这里有个细节值得说lru_cache对参数要求是可哈希的。字符串、数字、元组都没问题但如果参数里有 list 或 dict 就会直接报错。需要缓存带可变参数的函数时通常把参数转成元组或字符串再调用。另外maxsize不是越大越好。缓存无限增长会占内存对真正的大规模场景要考虑用maxsize128或者配合cache_clear()手动清理。我见过不少项目因为无脑maxsizeNone把内存吃满的这个参数要按数据量权衡。5. 路径处理的现代姿势pathlib过去 Python 处理路径用os.path.join拼字符串写起来啰嗦还总得担心 Windows 和 Linux 的分隔符差异。Python 3.4 引入的pathlib把路径变成了对象操作方式彻底改变。我大概是 2018 年开始全面切换到pathlib的以后再也没回去过。5.1 拼接、读写、判断一条链全搞定传统写法import os base_dir os.path.dirname(os.path.dirname(os.path.abspath(__file__))) data_dir os.path.join(base_dir, data, 2024) if not os.path.exists(data_dir): os.makedirs(data_dir)pathlib 写法from pathlib import Path base_dir Path(__file__).resolve().parent.parent data_dir base_dir / data / 2024 data_dir.mkdir(parentsTrue, exist_okTrue)/运算符直接把路径拼起来可读性提高了不止一个档次。mkdir自带parentsTrue递归建目录、exist_okTrue不报错比os.makedirs更直观。读写文件也完全兼容with open(data_dir / report.txt, w) as f: f.write(hello)Path对象可以直接传给open()也可以用Path.write_text()和Path.read_text()一行完成整个读写data_dir.joinpath(report.txt).write_text(hello)5.2glob与rglob批量找文件必备我有一个批量处理日志的小工具要遍历全部子目录下的.log文件以前要用os.walk写三层循环现在一行for log_file in Path(logs).rglob(*.log): process(log_file)rglob(*.log)递归匹配所有日志文件返回生成器几万个文件也能从容处理。想限定单层目录就用glob()。这俩方法是我日常写脚本使用频率最高的工具方法配合Path.stat().st_size还能顺手看文件大小。处理文件类的自动化任务用 pathlib 能把代码缩小一大半。5.3 一个容易忽略的坑不是所有库都认识 Path虽然pathlib是标准姿势但部分第三方库的老版本 API 只接受字符串路径。这时候用str(path_obj)转一下就行。另外判断路径是否存在用path.exists()判断是文件还是目录用path.is_file()/path.is_dir()这些语义化的方法比os.path那套直观得多。6. 上下文管理器不用类contextlib.contextmanagerPython 的with语句是好东西资源自动关闭、异常自动处理。但传统写一个上下文管理器得定义一个类实现__enter__和__exit__两个方法光模板就够写一阵子。contextlib.contextmanager给了你一个更轻的解决方案用生成器写上下文管理器。6.1 一个装饰器实现的计时器想给一段代码计时常规做法是start time.time()然后结束再减一次到处插入计时逻辑很破坏代码节奏。用contextmanager可以写一个可复用的计时器import time from contextlib import contextmanager contextmanager def timer(name): start time.perf_counter() try: yield finally: elapsed time.perf_counter() - start print(f{name} 耗时: {elapsed:.3f}s) with timer(数据导入): import_data()yield之前的代码在进入with时执行yield之后的代码在退出with时执行。finally保证即使中间抛异常也会执行收尾逻辑。这个模式比写类清爽太多。6.2 临时改环境变量、临时切换目录我经常写需要临时改变环境变量的脚本比如调某个 API 前临时设置 tokenimport os from contextlib import contextmanager contextmanager def temp_env(key, value): old_value os.environ.get(key) os.environ[key] value try: yield finally: if old_value is None: os.environ.pop(key, None) else: os.environ[key] old_value with temp_env(API_TOKEN, test-token): call_api()类似地临时切换工作目录也可以这样实现。用contextmanager写这些辅助工具代码量只有类实现的三分之一。6.3 让业务代码只剩“动作”本身最推荐的使用方式是把每个资源生命周期都封装成上下文管理器业务代码里只写动作。比如连数据库、开文件、发起 HTTP 会话全部写成一个with块。这样业务代码的可读性非常高资源管理逻辑集中在工具函数里一处维护。一个常见的注意点contextmanager装饰的函数里yield如果想返回值with语句可以用as接收contextmanager def get_db_connection(): conn create_connection() try: yield conn finally: conn.close() with get_db_connection() as conn: conn.query(...)这里容易踩的坑是如果yield之后发生异常yield改代码会抛出异常给 with 块你的finally依然会执行这是正确行为。不要把收尾逻辑写在yield之后的普通代码里而不放在finally中否则异常会导致资源泄漏别问我怎么知道的。7. 实战中的坑与排查清单这部分是我在实际代码审查和跑项目时整理的每个点都真实坑过人。整理成速查表直接能用功能模块常见坑排查与解决*args, **kwargs签名中默认参数被意外覆盖明确的关键字参数放在**kwargs之前传递前用kwargs.get()带默认值dataclass可变默认值直接 []导致共享引用必须用field(default_factorylist)itertools返回迭代器只能遍历一次第二次拿不到数据需要复用就list()转换注意大数据量时慎转lru_cache参数里有 list/dict 导致报错传入前转成元组/JSON字符串或者手动实现缓存pathlib老库不认 Path 对象传参处str(path)转换contextmanager收尾代码没放在finally确保yield后面的清理代码放在finally块内再说几个排查思路第一遇到“为什么第二次跑数据不对”的问题优先怀疑迭代器被消费完了检查是否有itertools、map、filter相关代码这些返回的都是懒加载迭代器。想重现数据就list()固定住。第二lru_cache的缓存是不会自动处理“参数内部变化”的。比如传一个自定义对象对象属性变了但哈希没变缓存还是旧的。这种场景要在函数内部处理或者在传入前用新对象重新拼参数。第三dataclass 和类型注解一起用时我建议把“必填参数不放默认值、选填参数放在后面”的顺序严格遵守否则会报TypeError提示 non-default argument follows default argument。这个错误新手经常遇到其实就是普通函数参数规则被 dataclass 带进来了。第四大量使用pathlib以后如果看到奇怪的TypeError大概率是把 Path 对象传给了os.path系列的旧函数。统一在项目入口做一次str()转换或者在旧代码处逐步替换不要混着用。这些功能全部来自标准库不需要pip install任何东西也就意味着在任何 Python 环境里都能用。真正成熟的项目靠的不是堆依赖而是把语言本身提供的东西用到位。根据我个人经验建议把dataclass和pathlib作为第一个改造对象因为你现有的数据模型和文件处理代码里十有八九都有大量样板代码可以立刻压缩不需要额外承担任何风险。先改 100 行试试代码量和可读性的变化会非常直观。