字数 3079，阅读大约需 16 分钟

只用Python标准库，能替代多少第三方依赖？

做Python开发的同学，大概率都被依赖问题折腾过。想装个工具库，pip install一下，连带下载七八个传递依赖；部署到精简环境，缺个系统依赖直接报错；更别说时不时冒出来的供应链漏洞，很多漏洞藏在你根本用不上的代码路径里。

那有没有可能，很多常用的第三方库，其实只用Python自带的标准库就能实现？既不用装依赖，又没供应链风险，代价又有多大？最近芝加哥大学的团队做了一项实证研究，他们打造了名为zerodep的项目，用大模型辅助编写了44个纯标准库的单文件模块，挨个和主流第三方库对比正确性与性能，把标准库的能力边界摸得很清楚。今天我们就来聊聊这篇论文的核心发现。

先搞懂：zerodep是个什么项目？

简单说，zerodep是一套纯Python标准库实现的工具模块集合，每个模块对应一个流行的第三方库，满足四个严格约束：

1. 1. 零第三方依赖：源码内只能导入标准库，不允许任何外部包；
2. 2. 单文件交付：每个功能对应一个.py文件，直接拷贝到项目即可使用，无需打包安装；
3. 3. API兼容：常用接口和原第三方库保持一致，多数场景下仅需修改import语句即可替换；
4. 4. 强制正确性验证：每个模块都配套测试套件，以原参考库的行为作为基准做对拍校验。

整个项目目前包含44个模块，覆盖12个功能类别，按实现复杂度分为三个层级：

• • 简单层：聚焦单一窄场景的小工具，代码通常在200行以内，比如重试装饰器、环境变量解析、语义版本号校验；
• • 中等层：涵盖多个关联功能，代码量200-800行，比如HTML解析、WebSocket实现、Markdown渲染；
• • 子系统层：完整的协议或服务级实现，代码超过800行，比如HTTP客户端、Protobuf序列化框架、Agent通信协议。

从序列化、网络、加密到文本处理、配置管理、开发工具，常用的基础组件基本都有覆盖。所有模块都采用大模型辅助开发+人工迭代优化的模式产出，最终通过完整的功能与性能验证。

实验是怎么设计的？

为了保证对比公平，研究团队设计了两套核心测试体系。

第一套是正确性测试：给zerodep模块和对应的参考第三方库输入完全相同的用例，覆盖常规用法、边界值、异常格式等场景，对比两者的输出是否一致。最终所有44个模块都通过了对应的正确性测试；少数模块主动简化了极少用到的冷门功能，也都在文档中做了明确说明。

第二套是性能基准测试：所有测试在同一台机器、相同Python环境下运行，统计单次操作的平均耗时。论文将「性能持平」的标准划定为2倍以内——对于IO密集型操作，库本身的微秒级差异在网络或磁盘的毫秒级延迟面前基本感知不到；即便是CPU密集的工具场景，2倍以内的差距在绝大多数业务中也完全可以接受。

核心发现一：六成以上场景，标准库不仅够用，还更快

这是论文中最核心的性能对比结果，涵盖了所有模块的基准测试结论：

整理下来，44个模块中，19个稳定快于参考库，11个达到性能持平，6个明显更慢，其余模块在不同操作下表现有差异。也就是说，约三分之二的模块，纯标准库实现的性能都在可接受范围内，甚至不少场景下表现更好。

为什么纯标准库实现反而更快？核心原因是第三方库的架构开销。很多流行库为了兼顾通用性、扩展性、多场景兼容，设计了大量抽象层、插件体系和兼容逻辑。这些设计在复杂场景下很有价值，但在普通业务的常用路径上，就成了不必要的性能冗余。

举几个很有代表性的例子：

• • 常用的PyYAML，纯Python解析路径实现了完整的递归下降解析器，扩展性极强，但也带来了很多间接调用开销。zerodep的yaml模块只针对配置文件常用的YAML 1.1子集做优化，跳过了冗余抽象层，速度比PyYAML默认模式快6-7倍。
• • 处理带注释JSON的commentjson库，底层用eval处理中间表示，开销极大。zerodep的jsonc仅通过正则做轻量注释剥离，直接调用标准库json.loads，速度提升75-115倍。
• • 功能全面的httpx客户端，支持同步异步、多传输层、完整中间件体系，但也因此叠加了多层调度开销。zerodep的httpclient直接封装标准库http.client与ssl，抽象层极少，同步请求速度比httpx快18-32倍。

说白了，很多时候第三方库慢，不是因为功能本身复杂，而是它附带了很多你用不上的能力。针对性的标准库实现，刚好能避开这些冗余。

核心发现二：这几类场景，纯标准库确实打不过

当然标准库不是万能的，有一类场景性能差距非常明显，论文中将其称为「C扩展性能悬崖」。凡是参考库底层依赖C/Rust扩展做计算密集型工作的场景，纯Python实现的性能会出现断崖式下跌，典型的有三类：

1. 1. 图片处理：比如PNG编解码，Pillow底层是SIMD加速的C代码，处理像素级循环远快于Python循环。zerodep的png模块比Pillow慢7-45倍。
2. 2. 二进制序列化：比如Protobuf，官方库的核心编码逻辑由C扩展实现，纯Python用struct打包每个字段都有不小开销，速度慢6-72倍。
3. 3. 纯Python实现的加密算法：纯Python编写的AES加密，字节级操作在Python解释器中开销极大，比带C扩展的PyCryptodome慢300-17000倍，基本没有实用价值。

不过这也不是完全无解。论文给出了一个很实用的思路：用subprocess调用系统原生库。比如AES加密，zerodep提供了另一条实现路径，通过子进程调用系统自带的OpenSSL完成加密运算。这样既没有引入Python第三方依赖，又绕开了Python解释器的性能瓶颈，最终速度反而比PyCryptodome快1.5-8倍。这个思路可以推广到很多计算密集型场景——只要系统中有对应的原生工具，通过标准库的subprocess调用，就能在零Python依赖的前提下，拿到接近原生的性能。

大模型写这类代码靠谱吗？

这个项目的所有模块都采用大模型辅助开发，团队也总结了不同复杂度下的开发体验：

• • 简单层模块：比如重试装饰器、环境变量解析、版本号校验，大模型基本1-3轮迭代就能写出接近正确的代码，仅需人工微调少量边界情况。
• • 中等层模块：比如HTML解析、WebSocket实现，通常需要2-5轮迭代，修正重点集中在细微的行为差异，比如换行符处理、Unicode边界场景。
• • 子系统层模块：比如HTTP客户端、完整协议实现，大模型无法独立完成。必须先由人工做好架构设计、划定模块边界，大模型再填充具体实现、编写样板代码；否则要么收敛极慢，要么产出的代码结构混乱。

整个流程中最关键的环节，是用参考库作为正确性基准。每一轮生成代码后，都运行与参考库对拍的测试，将失败用例反馈给大模型进行修正，形成闭环迭代。如果没有这套自动验证机制，纯靠人工排查bug，迭代效率会大幅下降。

给普通开发者的实用建议

结合论文的结论，日常开发中可以参考这几个原则：

1. 1. 工具类、配置类、简单网络交互这类场景，零依赖方案完全可用。如果部署环境受限、对供应链安全要求较高，完全可以考虑用标准库替代轻量第三方库。
2. 2. 计算密集型场景（图片编解码、高性能序列化、高频加密），优先选择带原生扩展的成熟第三方库。如果确实不能引入依赖，可以考虑调用系统原生工具的方案。
3. 3. 如果打算自己用大模型编写零依赖工具，建议从简单模块入手；复杂模块一定要先做好人工架构设计，再让大模型填充细节，同时务必编写对照测试，用参考库的行为做校验。
4. 4. 不要盲目追求零依赖。如果需要完整的功能覆盖、流式处理、多后端兼容，成熟的第三方库依然是更稳妥的选择。

最后说两句

回到最开始的问题：只用标准库，能替代多少第三方依赖？答案是：大部分工具和基础设施类场景完全可以，而且性能往往不差甚至更好；但涉及原生加速的计算密集型场景，纯Python标准库还有明显差距。

零依赖不是银弹，也不是要取代整个PyPI生态。它的价值在于，给了我们另一个选项——在部署受限、安全要求高，或者只是不想为了一个小功能引入一堆依赖的时候，我们有经过验证的可靠替代方案。而大模型的存在，让从零打造这套零依赖工具集的成本大幅降低。它不能替代工程师的架构设计，但能帮我们省下大量编写样板代码、处理细节的时间，让这种「小而精」的工具开发变得更高效。

https://arxiv.org/pdf/2605.21405