Python打包工具：cx_Freeze-python介绍

作者：马育民 • • 阅读：10044

笔者不推荐使用该软件打包，推荐使用 pyinstaller

介绍

cx_Freeze 是一套开源、跨平台的 Python 应用冻结（freeze）工具。核心目标：将 Python 源代码、Python 解释器、第三方扩展库、依赖资源捆绑，生成平台原生可执行文件，使目标机器无需预先安装 Python 环境即可运行程序。
名称中 freeze（冻结）含义：把动态解释执行的 Python 程序，绑定固定版本解释器与依赖，固化成可分发的二进制程序包。
项目起源：由 Anthony Tuininga 开发，持续维护多年；区别于早期 py2exe（仅Windows、停止维护），是长期活跃的跨平台冻结方案。
开源协议：PSF license（Python Software Foundation License），宽松商业友好，允许闭源商业软件使用，无传染性开源约束（和 PyInstaller 的 GPL 协议存在关键区别）。

官方文档：
https://cx-freeze.readthedocs.io/en/latest/index.html

底层工作原理

Python 本身是解释型语言，.py 文件不能直接被操作系统内核执行。cx_Freeze 的核心思路不是编译Python代码为机器码（重点区分：≠ Cython、Nuitka）。
完整运行机制分为三部分：

  1. 启动器（stub / executable stub）
    cx_Freeze 会编译一个原生平台二进制启动器（Windows EXE、Linux ELF、macOS Mach-O）。
    这个原生程序不包含 Python 逻辑，职责：

    • 初始化操作系统运行环境；
    • 加载内置嵌入版 Python 解释器；
    • 设置模块搜索路径；
    • 载入编译后的 Python 字节码，启动入口脚本。
      Windows下区分两种启动器：控制台启动器、Win32GUI 无控制台GUI启动器。

  2. 嵌入Python解释器
    打包时捆绑对应版本的 Python 共享库（Windows python3xx.dll、Linux libpython.so、macOS Python.framework）。程序运行依靠这个附带的解释器执行代码。

  3. 依赖收集与字节码打包

    • 静态分析入口脚本，递归解析 import 导入语句，收集所有依赖模块；
    • 将 .py 源码编译为 .pyc 字节码（可选剔除原始py源码）；
    • 把标准库、第三方 wheel 模块、C扩展模块（.pyd/.so）一并收集；
    • 额外静态资源（图片、配置文件）作为外部文件一同存放。

关键结论：cx_Freeze 打包产物依旧运行Python字节码，不存在AOT编译为本机机器码。程序性能和原生Python运行几乎一致，不会提速。

产物形态设计

cx_Freeze 原生只支持「目录分发模式」，不存在内置单文件打包机制。
输出结构：一个独立文件夹，包含：

  • 主启动可执行文件
  • Python动态链接库
  • 所有第三方模块、标准库（pyc、pyd等）
  • 用户附加资源文件

为什么不提供原生单文件？

架构设计理念：优先追求运行稳定性。PyInstaller --onefile 的原理是运行时临时解压全部文件到系统临时目录；cx_Freeze 开发团队认为解压机制会带来启动变慢、杀毒软件误报、权限异常、临时文件残留等问题，因此不在内核实现该功能。
如果需要单文件，只能依靠第三方封装工具（Enigma Virtual Box、7-Zip自解压程序）外层二次封装。

功能与能力边界

支持能力

  1. 全平台支持：Windows、Linux、macOS；同时支持32位/64位构建。交叉编译不支持：只能在对应系统打包对应平台程序（Windows只能打包exe，不能直接产出Linux程序）。
  2. 兼容 CPython（主流官方Python），不支持 PyPy；支持 Python3.6 ~ Python3.13，持续跟随新版Python迭代。
  3. 完整支持纯Python模块，同时支持带二进制C扩展库的包（numpy、pandas、PyQt、OpenCV等）。
  4. 两种调用接口：
    • 命令行接口 cxfreeze（轻量化，适合小型脚本）
    • setuptools 集成接口（setup.py，标准化大型项目构建，可与pip生态打通）
  5. 精细的打包控制：手动包含模块、排除冗余模块、映射外部资源文件、自定义运行环境变量。
  6. 支持剥离源代码：仅打包pyc字节码，一定程度保护源码（注意：pyc可以被反编译，无法做到高强度加密）。

天然局限

  1. 依赖分析存在缺陷：动态导入代码无法自动识别
    代码中使用 __import__()、importlib 动态导入模块时，静态扫描无法捕获依赖，打包后运行出现 ModuleNotFoundError，必须手动显式声明需要包含的包。
  2. 打包体积偏大：默认会收集大量标准库组件，如果不主动exclude排除无用模块，输出文件夹臃肿。
  3. 不支持内嵌数据压缩，所有模块以松散文件形式存放。
  4. 无法脱离系统底层依赖：Windows程序依然依赖VC++运行库；Linux依赖系统glibc版本，打包产物不具备完全静态链接特性。
  5. 对特殊包兼容性偶尔较差：部分使用非常规加载机制的框架（部分异步框架、嵌入式GUI）需要额外配置。

架构设计特点（对比同类冻结工具）

1. cx_Freeze vs PyInstaller

  • 协议：cx_Freeze（PSF，宽松商用）；PyInstaller（GPL，分发程序存在开源合规风险）
  • 产物：cx_Freeze 默认目录包，无内置单文件；PyInstaller 原生支持文件夹 / 单文件两种模式
  • 实现：两者都是「启动器+嵌入解释器+字节码」模式，都不编译成本机代码
  • 生态：PyInstaller社区更大，遇到问题解决方案更多；cx_Freeze 更新节奏平稳，bug数量更少，误报相对低
  • 运行机制：cx_Freeze直接读取目录内文件；单文件模式的PyInstaller运行需要解压

2. cx_Freeze vs Nuitka

根本性区别：

  • cx_Freeze：冻结工具，打包解释器+字节码；运行性能不变
  • Nuitka：Python转C代码编译器，将Python翻译为C再编译二进制；属于编译方案，性能提升明显

3. cx_Freeze vs py2exe

py2exe仅支持老旧Windows与低版本Python，项目停止维护；cx_Freeze是现代化继任方案。

适用场景 & 不推荐场景

适合使用 cx_Freeze

  1. 需要开发闭源商业软件，在意开源许可证，规避GPL约束；
  2. 追求程序长期稳定运行，厌恶单文件解压带来的各种疑难bug；
  3. 软件以文件夹形式分发（绿色软件，解压即用），不强制要求单一exe；
  4. 跨平台项目，需要一套构建逻辑同时打包 Windows/Linux/macOS；
  5. 使用标准setuptools管理项目，希望构建流程融入python原生打包体系。

不推荐使用 cx_Freeze

  1. 硬性要求原生一键生成独立单exe文件，不愿意额外使用第三方封装工具；
  2. 大量使用动态import，模块繁多，不想手动维护依赖列表；
  3. 新手，遇到问题希望网上能找到海量现成解决方案（优先选择PyInstaller）。

分发相关客观说明

  1. 打包产物没有加密保护：提取目录后，可以直接拿到pyc字节码，借助反编译工具还原源代码，不能用于核心机密代码保护；
  2. Windows平台打包出来的exe依然容易被杀毒软件标记，程度略好于单文件模式的PyInstaller，但无法完全避免；
  3. 架构层面不提供防篡改、加壳能力，加壳需要外部工具独立完成；
  4. 版本绑定：打包时捆绑的Python解释器版本固定。不能将打包程序迁移到其他Python版本环境，互不通用。

安装

pip install cx_Freeze

打包

cxfreeze hello.py --target-dir dist

原文出处：/show_1EF6CoJVmrrR.html

吉ICP备15003043号