所以这次我决定把市面上主流的 Python 打包方式都跑一遍，每个都写写感受，说说坑，给大家一个真实参考。写之前我没看任何官方文档，全凭自己动手踩坑，这样写出来的东西才有烟火气。
先说结论：没有银弹，只有适合。不同场景用不同方案，强行用错工具只会让自己加班。
那些年，我被 Python 打包支配的恐惧
先聊聊为啥要写这篇文章。事情是这样的，上个月接了个活，要把公司一个数据处理脚本做成可执行文件，给运营同事用。他们电脑是 windows，没装 Python，也不会装。
我当时心想，pyinstaller 一把梭呗，结果搞了一下午。
为啥？因为这脚本依赖了 pandas、numpy、requests，还有一堆奇奇怪怪的库。打包出来 300 多 M，运营同事传个文件发邮件都不方便。更要命的是，第一次在他电脑上跑，直接报错说缺什么 dll，我人都麻了。
后来换了几种方式，发现每种都有它自己的脾气。今天就把我试过的几种全讲讲。
不过别期待太高，Python 打包这个领域，本身就是"能用"和"好用"之间的巨大鸿沟。你要是想找完美方案，那真的没有。
PyInstaller：这个老朋友，我又爱又恨
先说 PyInstaller，估计 90% 的 Python 开发者都用过它。
用起来真的很简单。一行命令搞定：
pyinstaller -F your_script.py
-F 是单文件模式，打包出来就一个 exe，用户拿着就能跑。对开发者友好度这块，PyInstaller 真的没得说。
我第一次用的时候，感觉这玩意简直是神器。我写了个小工具，打包成 exe 发给同事，他双击就能用，那种成就感，懂的人都懂。
但坑也多。
最典型的就是体积问题。我那个数据处理脚本，打包出来 280M。同事问我："你这啥程序啊，怎么比英雄联盟客户端还大？" 我无言以对。
为啥这么大？因为 PyInstaller 是把整个 Python 解释器和所有依赖库都塞进去了。pandas、numpy 这些库本身就大，再加上 PyInstaller 的运行时，动辄上百 M 起步。
还有更恶心的兼容性问题。
我那次在 Windows 10 打包的 exe，拿到 Windows 7 上跑不起来。报什么 "api-ms-win-crt" 错误，查了半天是缺 VC++ 运行库。还有在某些精简版系统上，连 tkinter 都跑不起来，要手动指定 hidden import。
pyinstaller --hidden-import=tkinter your_script.py
这种坑，第一次遇到真的能让人崩溃。
不过话说回来，PyInstaller 还是我最常用的。因为它跨平台，Windows、Linux、macOS 都能打，社区也活跃，遇到问题基本搜得到。对于一些内部小工具，不在乎体积的情况下，PyInstaller 仍然是首选。
有一次我做个小爬虫工具，就一个 py 文件，依赖只有 requests 和 beautifulsoup4，打包出来才 30M，体验就很好。所以体积这事，看你依赖什么库。纯 Python 库小，带 numpy、pandas 这些科学计算库就炸。
cx_Freeze：跨平台的另一种选择
cx_Freeze 这玩意，我接触得比 PyInstaller 少，但也有故事。
当时做项目要在 Linux 服务器上跑一个 Python 脚本，但服务器是个精简版系统，连 pip 都没有。我想着搞个绿色版，直接拷过去就能用。
cx_Freeze 生成的目录结构比较合理，library 和可执行文件分开。看着比 PyInstaller 整洁一些。
但这玩意用起来比 PyInstaller 麻烦。要写 setup.py：
from cx_Freeze import setup, Executable
setup(
name="myapp",
executables=[Executable("your_script.py")]
)
然后 python setup.py build，出一堆文件。配置项多，新手容易懵。
优点是跨平台做得不错，生成的结构清晰，库和可执行文件分离，对于一些需要定制部署的场景比较友好。
缺点就是配置复杂，文档也不如 PyInstaller 详细。我那次配置参数搞了半天，最后还是放弃了，转头用了 PyInstaller。
要是你项目有特殊需求，比如要打进一些自定义的 .so 文件或者 dll，cx_Freeze 的配置反而更灵活。但对普通用户来说，没那必要折腾。
Nuitka：把 Python 编译成 C，性能起飞
这个是我最近才认真试的，用完直接说一句：真香。
Nuitka 的思路不一样，它不是把 Python 解释器和代码一起打包，而是把 Python 代码编译成 C 代码，然后再编译成机器码。
对，你没看错，是真的编译，不是那种伪编译。
第一次跑的时候，我在 Linux 上测试一个数据处理脚本，编译完跑起来，速度直接快了一倍。我以为是我眼花了，又跑了几次，确实快了不少。
nuitka --standalone --onefile your_script.py
参数和 PyInstaller 类似，但生成的二进制文件运行效率高很多。
体积方面也很惊艳。同样的脚本，PyInstaller 打包 280M，Nuitka 编译出来 80M。差距不是一点半点。
但！坑也来了。
Nuitka 的编译速度是真的慢。我那个 300 行的脚本，编译花了 4 分钟。PyInstaller 几秒钟搞定。Nuitka 几分钟后才有结果。
还有就是兼容性。Nuitka 对一些冷门库的支持不如 PyInstaller 好。我有个脚本用了 pyexecjs，Nuitka 怎么都搞不定，最后还是退回 PyInstaller。
所以我的建议是：如果你的项目对性能有要求，Nuitka 真的值得一试。但要是项目复杂、依赖多，PyInstaller 还是更稳。
Nuitka 还有个加分项，它支持 Python 3.6 以上的所有版本，而且对一些 C 扩展库的支持做得不错，至少 numpy、pandas 这种常见的没问题。
但我得提醒一句，Nuitka 安装本身就是个坑。在 Linux 上还好，pip 直接装就行。在 Windows 上，你要先装 C 编译器，Visual Studio Build Tools，几 G 的东西。不像 PyInstaller 那样 pip install 就能用。
源码包与 wheel 包：最 Pythonic 的方式
说完编译型的，再说说 Python 圈子最传统的打包方式——源码包和 wheel 包。
这个就是用 setuptools 那一套，写个 setup.py 或者 pyproject.toml，然后 python setup.py sdist bdist_wheel。
这玩意严格说不算"打包成可执行文件"，但它在 Python 生态里太重要了，不得不提。
python setup.py sdist # 源码包
python setup.py bdist_wheel # wheel 包
wheel 包的好处，装起来快。因为是预编译的格式，pip 安装 wheel 包的时候不需要本地编译，直接解压就行。
我之前在树莓派上装过一个库，等编译等了 20 分钟。换 wheel 包，几秒钟。这种体验差异真的巨大。
wheel 包还有个隐藏好处：可以指定平台和 Python 版本。xxx-cp39-cp39-linux_x86_64.whl，这名字一看就知道是哪个平台哪个版本用的。
源码包（sdist）则更通用，里面就是 Python 源代码和 setup.py。pip 装了之后会自动编译，但有些纯 Python 包就直接拷贝了。
这两种方式适合的场景：你要发布的是库，而不是应用。用户拿到你的包后还会 import 使用，而不是直接运行。
我自己的项目，如果是写库给别人用，就用这种方式。如果是写工具给自己或者非技术人员用，就用 PyInstaller 或者 Nuitka 编译成可执行文件。
Docker：容器化才是终极方案？
说完传统的打包方式，再聊聊现在云原生时代的玩法——Docker。
严格说 Docker 不是 Python 打包工具，但用 Docker 部署 Python 应用真的太香了，我现在新项目基本都是这套。
Dockerfile 写起来简单：
FROM python:3.9-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "your_script.py"]
这一套下来，生成的镜像扔到任何装了 Docker 的机器上都能跑。不用管宿主机的 Python 版本，不用管系统库依赖，不用管这个那个环境变量。
优点太多了：
环境隔离得彻底。每个容器都是独立的 Python 环境，互不干扰。
部署一致性。开发环境测试过了，生产环境肯定一样。这点对运维来说简直是救命的。
资源利用高效。一个服务器可以跑几十上百个容器，密度比虚拟机高多了。
但也有代价：
镜像体积不小。最小的 python:3.9-slim 镜像也有几十 M，加点依赖就上百 M。不过相比 PyInstaller 的 280M，还是能接受的。
需要懂 Docker。不是说门槛多高，但要是团队没人用过 Docker，学起来还是要点时间。
启动速度比直接跑可执行文件慢。不过这点在生产环境一般不是问题。
我个人现在的做法：所有线上服务都走 Docker，本地开发也尽量用 Docker。桌面端的小工具才用 PyInstaller 这种。
Docker 还有一个隐藏的好处，可以多阶段构建。编译阶段用一个完整镜像，运行阶段用一个精简镜像，镜像体积能小很多。比如：
FROM python:3.9 AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --user -r requirements.txt
FROM python:3.9-slim
WORKDIR /app
COPY --from=builder /root/.local /root/.local
COPY . .
CMD ["python", "your_script.py"]
这样最终的镜像能小一半不止。
PyOxidizer：Rust 写的打包工具，性能怪兽
这个是最近挖到的宝，PyOxidizer。
它是用 Rust 写的，思路和 Nuitka 类似，但更激进——它把 Python 解释器嵌入到一个 Rust 二进制里。
听起来很硬核是吧？用起来其实没那么复杂：
# pyoxidizer.bzl
[[python_run_file]]
path = "your_script.py"
然后 pyoxidizer build，搞定。
这个工具的亮点：启动速度比 PyInstaller 快得多。Nuitka 我已经觉得很厉害了，PyOxidizer 比它还快。
我做了个简单测试，启动一个简单的 Flask 应用：
这差距真的不是一点半点。
而且它的单文件模式更彻底。PyInstaller 的 -F 模式本质上还是先解压到临时目录再运行，PyOxidizer 是真的把解释器和代码都嵌入到一个可执行文件里，没有解压过程。
但缺点也很明显：
首先，这玩意还比较新，文档不算完善，很多功能要翻 GitHub Issues 才能搞清楚。
其次，对 Windows 的支持还在完善中。我在 Windows 上用踩了几个坑，最后还是退回 Linux 环境。
还有就是，配置用的是 Starlark 语法（一种 Python 风格的配置语言），和 Python 本身有点区别，新手要适应一下。
我的评价是：PyOxidizer 是打包工具的未来，但现在还不够成熟。要是你项目允许用 Linux，对启动速度有极致要求，可以试试。
实战案例：我是怎么给运营做工具的
光说理论太空了，给大家讲讲我最近做的真实项目。
需求是这样的：运营部门每周要处理一批 Excel 文件，提取数据生成报表。原来是人工处理，一人一天。现在让我搞个自动化工具。
第一个版本，我用 PyInstaller：
写了个 Python 脚本，用 pandas 处理 Excel，openpyxl 写报表，tkinter 做了个简单界面。PyInstaller 打包出来 280M，运营同事收到邮件当天就吐槽："这啥玩意这么大？"
第二个版本，我换了 Nuitka：
编译出来 80M，运行速度还快了不少。运营同事勉强接受了。但有个问题，他们公司电脑有些是老款 Windows 7，Nuitka 编出来的二进制文件跑不起来，要装 VC++ 运行库，IT 部门不太愿意装。
第三个版本，我妥协了，用 Docker：
在内部服务器上起了个 Web 服务，运营同事用浏览器访问。镜像大小 200M 左右，但在服务器上运行，稳定得很。运营同事也不用装任何东西，打开浏览器就能用。
最后选了 Docker 方案。不是因为它最好，而是因为最适合运营同事的使用场景。
这个案例给我的最大启发：打包方式的选择，不是看技术多牛，而是看用户场景。给技术人员用和给非技术人员用，完全是两个思路。
选哪个？给你个参考
说了这么多，到底选哪个？我列个表给你参考：
我个人的优先级：Docker > Nuitka > PyInstaller > 源码包 > PyOxidizer
日常开发基本都 Docker，性能要求高的脚本用 Nuitka，分发小工具才用 PyInstaller。
这些坑你别再踩了
最后说几个常见的坑，新手一定要避开：
第一，不要在打包环境里瞎装东西。我见过有人在打包机器上装了一堆开发工具，结果打出来的包巨大，依赖混乱。最好用干净的虚拟环境打包，pip install 完依赖就打包，别多装。
第二，注意隐藏依赖。有些库是动态导入的，PyInstaller 静态分析找不到，要在 spec 文件里手动指定 hidden import。这事不复杂，但很多人栽在这里。
第三，路径问题。打包后的程序，file 这个变量的行为会变。在 PyInstaller 单文件模式下，file 指向的是临时解压目录，不是你的 exe 所在目录。要用 sys._MEIPASS 获取真实路径。
第四，不要忽略杀毒软件。PyInstaller 打包的 exe 经常被杀软误报，尤其是国内各种管家。我之前有个工具，运营同事的电脑装了 360，直接给拦截了，还给我归到"高危"。这种情况要么加白名单，要么换签名，要么用 Web 方案。
第五，不要忽视更新机制。PyInstaller 打包的 exe 没法自动更新，要重新打包让用户下载。Docker 容器可以拉取最新镜像，Web 应用根本不用管。这点对工具的长期维护影响很大。
写在最后
Python 打包这事，说简单也简单，说复杂也复杂。简单是因为大部分情况下 PyInstaller 就能搞定，复杂是因为真要做得完美，需要考虑的场景太多。
我没有最好的方案给你，只有最适合的方案。选择之前想清楚三件事：
- 部署环境是什么？Windows、Linux、还是云端？
想清楚这三个问题，答案自然就有了。
Python 打包这领域，未来肯定会越来越好。PyOxidizer 让我看到了一些希望，Nuitka 也在快速迭代。但现阶段，要学会"将就"着用，别追求完美。
行了，今天就聊这么多。下次有机会讲讲 Python 项目结构怎么组织，那个也是个大坑。
如果觉得这篇文章对你有帮助，点个在看、转发给身边搞 Python 的朋友。整理这些内容花了我不少时间，都是真实踩坑经验，不是网上抄的。
日常分享运维、Python、效率工具的干货，关注我，少踩坑，少加班。 公众号：耕云躬行录
个人博客：躬行笔记
