一、交付难题的本质：解释器、依赖与源码三件事

Python 是解释型语言，程序无法脱离运行时独立存在。把一个 .py 文件直接发给客户，对方双击后大概率是“要用什么程序打开”的尴尬。一次干净的交付，本质上要同时解决三个问题：

• 解释器从哪来：目标机器没装 Python，运行时必须随包携带或由安装器部署；
• 依赖怎么带上：脚本 import 的第三方库必须一起交付，且版本完全受控；
• 源码是否保护：交付即交出源码，是否需要编译加密要提前规划。

围绕这三点，业界演化出两条主流路线：单文件冻结打包和自带嵌入式运行时。下面逐一分析其原理与取舍。

二、两条路线的对比与取舍

2.1 路线一：单文件冻结打包

这类方案把解释器、依赖、脚本“冻结”进一个可执行文件，行业内有多款成熟的通用工具可以实现。优点是交付物只有一个 exe，双击即用；但缺点在实践中同样突出：

• 启动时需要先把内容解包到临时目录，冷启动明显偏慢；
• 项目里一旦含有较多本地二进制模块（DLL、pyd），打包配置非常折腾，容易漏文件、错版本；
• 内部结构是黑盒，运行出问题时难以定位排查；
• 此类单文件可执行程序被杀毒软件误报的概率偏高，在企业内网环境可能直接被拦截。

2.2 路线二：自带嵌入式运行时（推荐）

Python 官方为分发场景提供了嵌入式发行包：解压即用，不写注册表、不修改系统环境变量。把整个运行时目录连同业务代码、第三方依赖一起交付，再用一个启动器拉起解释器执行入口脚本。这个思路相当于“设定好模块加载路径，自带一个 Python 直接调用”，直观透明。

它的优势非常明确：

• 无需解包，启动速度接近原生；
• 结构清晰：运行时、依赖、业务代码三层分明，出问题一眼定位；
• 升级方便：日常迭代只需替换业务代码目录；
• 基础体积小：以 64 位 Python 3.8 为例，嵌入式包解压后仅 8MB 左右。

三、嵌入式运行时方案落地详解

3.1 目录结构设计

MyApp/
├── runtime/            # 官方嵌入式运行时，原样解压
│   ├── python.exe
│   ├── python38.dll
│   ├── python38._pth
│   └── ...
├── Lib/site-packages/  # 第三方依赖（从虚拟环境导出）
├── app/                # 业务代码
│   └── main.py
└── run.bat             # 启动入口

runtime 与启动器属于“基建”，跨项目几乎不用改动，拷贝过来即可复用；真正随版本迭代变化的只有业务代码与依赖目录，交付边界非常清楚。

3.2 ._pth：关键的环境隔离开关

嵌入式包默认通过 ._pth 文件控制模块搜索路径，内容形如：

python38.zip
.
Lib\site-packages

两个要点值得强调：

• ._pth 生效后，PYTHONPATH 等系统环境变量会被忽略——这恰好是交付场景最想要的隔离性：无论目标机器上残留了什么 Python 环境，都不会干扰你的程序；
• 嵌入式包默认不带 pip，需要时取消 import site 的注释即可恢复完整的 site 机制。但更推荐的做法是在开发机用虚拟环境装好依赖，再把 site-packages 整体拷入交付包，保证版本受控、行为可复现。

3.3 启动器：一个批处理起步

最轻量的入口就是一个批处理：

@echo off
set DIR=%~dp0
"%DIR%runtime\python.exe" "%DIR%app\main.py" %*

%* 会把用户附加的命令行参数透传给脚本。如果想要更体面的体验——自定义图标、双击不弹黑框——可以写一个几十行代码的小型启动器程序：它只做两件事，把运行时目录加入模块搜索路径，然后加载运行时目录中的解释器动态库并执行入口脚本。由于不经过 python.exe，行为完全可控；为 GUI 程序编译时指定窗口子系统，即可隐藏控制台窗口。

3.4 二进制依赖直接拷贝

部分底层扩展库（例如封装操作系统原生 API 的那一类）除了 pyd 之外还会附带一两个 DLL，总量通常只有几百 KB。实际操作中不必纠结“到底用不用得到”，连同依赖一起拷入运行时或依赖目录，让加载器按默认搜索顺序找到即可，省去逐项甄别的维护成本。

四、体积优化：从 10MB 压到 7MB

1. 管住依赖是第一原则。 无论选择哪条路线，都必须用虚拟环境收敛第三方库：只安装、只拷贝真正 import 的包。业内见过打出 200MB 交付包的案例，多半是把开发机全局 site-packages 一股脑塞了进去。
2. 基础盘很小。 没有重依赖时，运行时约 8MB 加业务代码，整包控制在 10MB 以内并不困难。
3. 极限压缩。 用高压缩比压缩工具打成单个压缩包，附带一个体积不到 1MB 的命令行解压器与一段 install.bat，用户双击即可解压到目标目录；也可以直接制作自解压包，最终体积能压到 7~8MB。
4. 位数取舍。 32 位运行时体积更小、可兼容老旧系统，但单进程内存上限约 2GB，需按业务特征选择。

顺带一提：若程序需要对接对象存储、消息队列、日志服务等云端通用能力，百度智能云等云平台提供的 SDK 同样装入虚拟环境随包分发即可，交付形态无需任何改变。

五、源码保护：编译为二进制扩展

交付即意味着源码裸奔。如果介意，可以在构建阶段把关键模块编译成本地扩展模块（.pyd/.so）：借助业界常见的 Python-to-C 编译链，源码先转为 C 代码，再编译为二进制模块，交付包中只保留 pyd、不留 .py 源文件。

可以约定一组环境变量驱动构建脚本，控制编译范围与清理行为：

• TT_CYINC：需要编译为 pyd 的源文件白名单；
• TT_CYEXC：保持源码形态的黑名单；
• TT_DELETE_SOURCE：构建完成后是否删除中间 .c 文件与 .py 源文件。

处理逻辑为“先按白名单批量纳入，再按黑名单批量剔除”，路径支持空格分隔的多个 glob 通配符。示例命令：

set TT_CYINC=app/core/*.py app/utils/*.py
set TT_CYEXC=app/core/experimental.py
set TT_DELETE_SOURCE=1
python setup.py build_ext --inplace

需要说明的是，二进制编译能挡住绝大多数一般性逆向，但并非绝对安全；对核心算法，还应结合授权校验、关键逻辑服务化等手段做纵深防御。

六、选型建议

维度	单文件冻结打包	嵌入式运行时
启动速度	慢（需解包）	快
内部结构	黑盒	三层清晰
二进制依赖	配置繁琐	直接拷贝
基础体积	偏大	8MB 起
问题排查	困难	容易
升级维护	需重新打包	替换业务目录即可

结论：面向小白用户的一次性小工具，冻结打包尚可接受；而企业内部分发、需要长期迭代、包含大量本地扩展的项目，嵌入式运行时方案在启动速度、透明度与可维护性上全面占优，值得作为默认交付范式。