Python解释执行代码与打包可执行代码的差异、性能及适用场景

打包后性能会不会提升？ #

不会有本质性能提升，绝大多数场景下和直接解释执行的运行效率完全一致，冷启动速度还可能更慢。
py2exe、PyInstaller、cx_Freeze这类常说的"Python打包工具"，本质做的不是把Python代码编译成C/C++那样的原生机器码，而是做了个"自解压包裹"：把你的项目源码、对应版本的Python解释器、所有依赖的第三方库全部打包到一起。运行的时候程序会先把内嵌的环境释放出来，再走标准的Python解释执行流程跑你的代码，既没有做运行时的激进优化，也没有改变Python逐行解释执行的本质。
实际基准测试显示，同一段数值计算逻辑，本地直接用Python跑源码和打包成可执行文件后跑，纯计算耗时差不到3%，属于测试误差范围内的水平；单文件模式打包的程序因为启动时多了临时解压的步骤，冷启动速度反而会比直接跑源码慢0.5-2秒不等。
如果打包后真的出现了明显的性能提升，那基本是两种情况：要么你打包时用了带JIT的PyPy解释器替代了默认的CPython，要么你提前把核心计算逻辑用Cython编译成了二进制扩展，这部分性能收益和打包工具本身没有任何关系。

打包运行和原生解释运行的核心区别 #

• 依赖逻辑不同：打包生成的可执行文件完全自包含，不需要目标设备提前安装Python，也不需要手动安装任何第三方依赖；直接跑源码必须要求设备上装了版本匹配的Python解释器，且装全了项目依赖的所有库，缺任何一个组件都会启动失败。
• 分发门槛不同：打包后的产物是和操作系统绑定的原生可执行程序——Windows下是.exe、macOS下是.app/可执行二进制、Linux下是ELF格式文件，普通用户拿到双击就能运行；源码形式要求使用者具备基础的Python环境配置能力，对非技术用户极不友好。
• 启动流程不同：单文件模式打包的程序每次启动都会先把内嵌的解释器、依赖、源码解压到系统临时目录，再拉起解释器执行代码；直接跑源码是直接调用本地已安装的解释器加载代码，没有额外的解压开销。
• 代码暴露程度不同：打包后的代码不会以明文.py文件的形式直接分发，虽然做不到绝对防反编译，但比直接发源码的逆向门槛高很多；直接分发源码的话，任何人拿到都可以直接查看、修改代码逻辑。
• 体积差异极大：哪怕你只写了一行打印Hello World的代码，打包后的可执行文件因为内嵌了完整的Python解释器和基础依赖，体积基本也在5MB以上，带复杂依赖的项目打包后体积可能到几百MB；同功能的源码文件可能只有几百字节，只要本地有Python环境就能跑。

什么场景适合把代码打包成可执行文件？ #

• 面向非技术用户分发桌面小工具时：这是最普遍的使用场景，比如你写了个批量重命名文件的脚本、Excel批量处理工具、本地图片压缩工具，使用者是完全不懂Python的运营、行政、普通办公用户，打包成可执行文件发过去对方双击就能用，不用花几个小时教对方装Python、配环境变量、装依赖。
• 需要严格统一运行环境时：Python的版本碎片化、第三方库版本冲突问题非常常见，哪怕是技术用户，也可能因为本地装了多个Python版本、依赖版本不对导致程序跑不起来。打包后内嵌固定版本的解释器和依赖，不会被设备上其他版本的Python环境干扰，运行一致性极高。
• 离线/内网环境部署时：很多封闭办公环境、离线服务器不能连接外网，没法在线安装Python和第三方依赖，把程序打包成单个可执行文件拷过去就能直接运行，省去了离线部署整套Python环境的麻烦。
• 有轻度代码保护需求时：如果你给客户交付小工具不想直接暴露全部源码，打包可以挡住绝大多数没有逆向能力的用户直接获取源码，当然要注意这种方式防不住有经验的逆向人员，真有高强度的代码保密需求，还要配合代码混淆、核心逻辑编译为二进制扩展等手段。

误区提醒：不要觉得大型项目就必须打包。绝大多数服务端部署的Python项目（比如Web后端、离线数据计算任务）都不需要打包，因为服务器环境本来就是提前标准化配置好的，打包反而会增大部署体积、提升线上问题排查的难度，完全是多此一举。

内容的提问来源于stack exchange，提问作者ojete_sucio