简介：围绕 Python 应用独立分发需求，这份 PyInstaller 早期版本源码分发包面向希望将脚本打包为可执行文件、研究冻结机制或复现旧版构建环境的开发者，也可用于缺少 Python 解释器时的程序分发、课程演示和实验复现。压缩包共 19 个文件，约 37KB，以 py 源码和 txt 测试/说明为主，辅以 pkg-info 元数据与 cfg 配置，体量轻巧但结构完整，便于直接阅读核心逻辑、测试用例和文档线索，对了解早期打包工具的文件组织也有帮助。已有 590 人学习或下载，说明其对打包工具入门与实现研究具有一定参考价值。读者可从中了解依赖收集、脚本冻结、配置项组织及旧版打包流程的基本轮廓，并借助测试说明排查资源遗漏、动态库依赖等常见问题，同时可据此整理自己的打包检查清单，适合作为理解 PyInstaller 工作方式、进行二次开发或教学拆解的辅助材料。
1. 从「打包成功却跑不起来」的现场说起：pyinstall安装包到底在装什么
上个月帮某开发者看一个交付现场：他做的 pyinstall安装包在自己机器上双击就开，拷到同事电脑上窗口闪一下就没影了，任务管理器里进程出现又消失，连一行报错都没留下。后来在命令行里跑同一个 exe，才看到一行ModuleNotFoundError——源码里import的那个库，打包时被静态分析漏掉了。这种翻车不是个例，它几乎是每个第一次用 PyInstaller 把脚本变成 exe 的人都会撞上的墙。
pyinstall安装包这件事，真正难的地方从来不是pip install pyinstaller那一行，而是版本怎么对、依赖怎么收、资源路径怎么在「开发态」和「打包态」之间切换，以及出了问题去哪儿看日志。这套东西常见到什么程度：只要你想把 Python 脚本交给一个没装 Python 的同事、想在没网的内网机器上跑个小工具、想给客户一个双击就能用的可执行文件，基本绕不开它。
这篇记录写给三类人：第一次给脚本打包、装完不知道从哪下手的新手；被闪退和缺库折腾过、想弄清 spec 文件里每个字段到底管什么的老手；以及需要把打包流程固化成交付规范的运维。下面按「装什么版本 → 怎么装 → 怎么配 → 坏了怎么救 → 怎么验证」的顺序走。
2. 环境准备与版本选型：Python 解释器、PyInstaller 与虚拟环境怎么搭配
装 PyInstaller 之前，先想清楚一件事：它不是那种「装完独立运行」的工具，它在打包时会把当前这个解释器的 CPython 运行时一起塞进产物里。所以你在哪个 Python 版本、哪个位数、哪个平台上打包，产物就带着那个环境的基因。这一条决定了后面所有的选型逻辑。
2.1 先钉死 Python 解释器版本，再谈 PyInstaller
很多人是先pip install pyinstaller，装完发现报错才回头查版本兼容。正确顺序反过来：先确定项目要跑在哪个 Python 上，再挑能配合它的 PyInstaller。常见组合我整理成下面这张表，版本号是经验值，实际以pip解析结果和官方发布说明为准：
| Python 版本 | 建议 PyInstaller | 适用场景 |
|---|---|---|
| 3.8 | 5.13.x 或 6.x 早期 | 老项目依赖多，先按 5.13.x 验证 |
| 3.9 / 3.10 | 6.x | 兼容性最稳的一档，新项目优先 |
| 3.11 | 6.x | 主流库基本都跟上了 |
| 3.12 | 6.3 及以上 | 少数老库还没出对应 wheel |
| 3.13 | 较新的 6.x | 生态还在跟进，谨慎用于交付 |
还有两个容易被忽略的约束。一是位数：32 位解释器只能打出 32 位产物，目标机是 64 位系统时虽然能跑，但一旦项目里有原生扩展（numpy、pillow 这类带 C 扩展的库），位数不匹配会直接崩在加载阶段。二是操作系统：Windows 上打不出 Linux 产物，反过来也一样，PyInstaller 不支持交叉编译，要哪个平台的包就在哪个平台上打。
先确认本机到底装了哪些解释器：
# Windows：列出所有已安装的 Python 解释器及其路径 py -0p # 确认当前激活的是哪一个，以及它的位数 python -c "import sys, platform; print(sys.version); print(platform.architecture())"py -0p是 Windows Python Launcher 提供的列表命令，输出里带-V:3.10这种标记，后面建虚拟环境时可以直接用py -3.10 -m venv指定版本，避免多版本机器上装错地方。platform.architecture()输出('64bit', 'WindowsPE')表示 64 位解释器，产物也是 64 位。
如果项目对版本没有强约束，我一般建议锁 3.10 或 3.11。原因是这两个版本上主流第三方库的 wheel 覆盖最全，打包时不用现场编译 C 扩展，省掉一大截玄学问题。3.12 以上不是不能用，但每次装依赖前先pip download试一遍，确认全都能拿到二进制包再说。
2.2 用独立虚拟环境装，不要在全局 site-packages 里滚
PyInstaller 的依赖收集是「把当前环境里能扫到的模块都收进去」。如果你在全局环境装了几十个项目共用的包，打出来的 exe 会莫名其妙大一圈，还会把别的项目用的库一起带进去，出问题时根本分不清是哪个依赖惹的。
建虚拟环境这一步没什么花活，关键是目录名固定、每次都用它：
# 在项目根目录建独立虚拟环境，目录名固定为 .venv，方便脚本和 CI 复用 python -m venv .venv # Windows 激活 .venv\Scripts\activate # Linux / macOS 激活 source .venv/bin/activate # 激活后确认 pip 指向虚拟环境内部，而不是全局 python -m pip --versionpython -m pip --version输出的路径里如果带.venv\Lib\site-packages，说明激活成功；如果还指向C:\Python310\Lib\site-packages，那多半是激活脚本没执行对，或者当前 shell 里PATH有更早的 Python。这种情况别硬装，先deactivate再重新激活。
装依赖之前先把 pip 本身升级一下，老版本 pip 解析 wheel 标签的能力弱，容易退回去编译源码：
python -m pip install --upgrade pip setuptools wheel # 按项目实际依赖装，没有 requirements.txt 就手动列 python -m pip install -r requirements.txt # 装完做一次依赖一致性检查，冲突会在这一步暴露 python -m pip checkpip check这一步值得单独拿出来说。它会把「A 要求 B<2.0，但环境里装的是 B 2.3」这类冲突打出来。打包阶段很多ImportError的根因就在这里——源码直接跑时因为 import 顺序碰巧没触发，打包后模块加载顺序变了，冲突就冒出来了。国内网络环境拉包慢的话，把索引地址换成本地镜像，但镜像源一定要写进pip config，别每次命令行手敲，否则换台机器就忘了。
2.3 安装 PyInstaller 与装完的自检
PyInstaller 本身装在刚才那个虚拟环境里，不要装到全局：
# 装本体，不指定版本时默认拿最新稳定版 python -m pip install pyinstaller # 确认装上了，并且确认是虚拟环境里这个 pyinstaller --version where pyinstaller # Windows 查可执行文件位置pyinstaller --version输出形如6.11.1。where的输出路径应该落在.venv\Scripts\pyinstaller.exe，如果落在别的地方，说明你调到的是另一个环境里的旧版本，后面打出来的包行为会跟预期不一致。
装完还有一步自检，很多人跳过：跑一遍pyinstaller --help，看输出里有没有--collect-all、--copy-metadata这些选项。老版本的 PyInstaller 没有这两个参数，如果你的构建脚本里写了它们，会直接报unrecognized arguments。与其等到打包脚本跑到一半才炸，不如装完就看一眼。
另外提一句pyinstaller和PyInstaller两种写法。装完之后一般会同时生成pyinstaller.exe和pyinstaller.exe之外的一个pyi-*系列工具（pyi-archive_viewer、pyi-bindepend等），前者是主命令，后者是排查产物内部结构用的。pyi-archive_viewer后面会用到，先记着它在。
3. 首次打包闭环：从 hello 样例到能双击运行的 exe
环境装好之后，最忌讳的就是直接拿真实项目开打。真实项目依赖多、资源多、入口逻辑复杂，第一次打包大概率失败，而失败信息往往指向不了真正原因。我的习惯是先拿一个十行的样例跑通全链路，确认「打包 → 产物 → 双击运行」这条路上没有环境性问题，再上真实项目。
3.1 先拿最小样例跑通，别拿真实项目试水
写一个最小入口脚本，只做三件事：打印、读参数、等回车。等回车这一行很关键，它能让窗口停住，你才有机会看到输出。
# hello_tool.py —— 最小可打包样例，用来验证工具链是否正常 import sys def main(): print("hello from packaged exe") print("argv:", sys.argv[1:]) input("按回车退出") if __name__ == "__main__": main()然后打第一个包：
# -F 打成单文件，-c 保留控制台窗口，方便看输出 pyinstaller -F -c hello_tool.py # 产物在 dist 目录下 dist\hello_tool.exe-F是 onefile，把所有东西压进一个 exe；-c是 console，保留黑窗口。这两个参数是排查阶段的最佳组合，因为所有print和 traceback 都能直接看到。等一切正常了再考虑去掉-c。
首次运行会在项目根目录生成三个东西：build/中间产物目录、dist/输出目录、以及hello_tool.spec文件。build/可以随时删，dist/是交付物，spec是下一次打包的配置来源——从第二次开始，你应该打spec而不是打.py。
3.2 spec 文件长什么样，哪些字段值得改
直接对.py执行pyinstaller时，它每次都会重新生成一份默认 spec，你在命令行上给的那些参数只是临时覆盖，改动留不下来。真正要固化配置，就得改 spec。
# 先生成一份带名字的 spec，不真正打包也可以 pyinstaller --name demo_tool -F -c hello_tool.py生成的 spec 大致长这样，我在每个字段后面加了注释：
# demo_tool.spec —— 首次由 pyinstaller 生成，之后手改这个文件再打包 # -*- mode: python ; coding: utf-8 -*- a = Analysis( ['hello_tool.py'], # 入口脚本，路径相对 spec 所在目录 pathex=[], # 额外的模块搜索路径，项目分多目录时填这里 binaries=[], # 非 Python 的 dll / so，一般交给 hook 自动收集 datas=[], # 数据文件，格式为 (源路径, 目标目录) hiddenimports=[], # 静态分析漏掉的模块，写模块名不是文件路径 hookspath=[], # 自定义 hook 目录 hooksconfig={}, runtime_hooks=[], # 运行时钩子，在入口脚本之前执行 excludes=[], # 明确排除的大包，用来压体积 noarchive=False, optimize=0, ) pyz = PYZ(a.pure) exe = EXE( pyz, a.scripts, a.binaries, a.datas, [], name='demo_tool', # 产物文件名，不带扩展名 debug=False, # 打开后会输出大量加载日志，排查用 bootloader_ignore_signals=False, strip=False, upx=False, # UPX 压缩开关，后面单独说 console=True, # False 即无窗口程序 icon=None, # 图标文件路径 )几个字段的取舍讲清楚。pathex是很多人第一次改 spec 时会漏的：如果你的项目是src/下面放包、入口脚本在根目录，静态分析可能扫不到src里的模块，把src的绝对路径塞进pathex就能解决。hiddenimports里写的是模块名（如pkg_resources），不是文件路径，写成路径会静默失效。excludes则相反，是用来做减法的——把tkinter、matplotlib.tests这类确定用不到的包排掉，体积能掉一大截。
改完 spec 之后，打包命令变成：
# 对 spec 打包，--noconfirm 覆盖 dist 里的旧产物，--clean 清掉 build 缓存 pyinstaller --noconfirm --clean demo_tool.spec--clean这一步别省。PyInstaller 会缓存上一次的分析结果，改了hiddenimports却不清理，很容易出现「明明加了为什么还报缺模块」的假象。我吃过这个亏，现在固定两个参数一起用。
3.3 单文件（-F）与单目录（-D）的取舍
这是新手最常问的一个问题，答案取决于交付方式，不取决于个人喜好。
| 对比项 | 单文件-F | 单目录-D |
|---|---|---|
| 交付形态 | 一个 exe，最省事 | 一个文件夹，含 exe 和依赖 |
| 启动速度 | 慢，每次要解压到临时目录 | 快，直接加载 |
| 体积 | 略大，压缩包内已有压缩 | 略小 |
| 排查难度 | 高，产物是黑匣子 | 低，能直接看到收集了哪些文件 |
| 适合场景 | 给非技术同事的小工具 | 内网部署、依赖多的项目 |
单文件的启动慢是结构性的：每次双击，引导程序要把内嵌的压缩包解到%TEMP%下的一个临时目录，程序退出后再清理。依赖多的项目，这个过程能到三五秒，用户会以为卡死了。所以我的做法是：排查阶段一律用-D，能直接翻目录看收集了哪些 dll 和 pyc，出问题一眼能定位；最终交付再用-F，如果启动慢到影响体验，就改成-D加一个快捷方式。
还有一个细节：单文件模式下，程序运行时的「当前目录」不是 exe 所在目录，而是启动时的工作目录。任何用相对路径读配置的代码，在单文件模式下都会失效。这个问题放在第 4 章的资源路径里解决。
4. 配置进阶：数据文件、隐藏导入与图标资源在 spec 里的写法
样例跑通只证明工具链正常，真实项目一上来，九成的问题集中在三件事上：数据文件没进去、模块没被扫到、窗口模式配错。这一章把这三件事拆开讲，每个都给出可直接抄的写法。
4.1 datas 与资源路径的运行时解析
PyInstaller 只负责收集.py和它识别到的二进制依赖，config.json、模板文件、图标、字体这些不会自动带进去。要带就得在 spec 的datas里显式声明。
# datas 的每一项是 (源路径, 目标目录)，目标目录是产物内的相对目录 datas=[ ('assets/config.json', 'assets'), # 单文件放 assets/ 下 ('assets/icons', 'assets/icons'), # 目录会整个拷进去 ('assets/templates/report.html', 'assets/templates'), ],注意第二个元素是「目标目录」不是「目标文件名」。写('assets/config.json', 'assets/config.json')会在产物里生成一个叫config.json的目录，然后往里塞文件，运行时打开必然失败。这个错我见过不止一次。
光把文件塞进去还不够，代码里读文件的路径也得跟着改。开发时用__file__拼相对路径没问题，打包后__file__指向的是一个临时解压目录，逻辑就断了。统一封一个函数：
# resource_path.py —— 统一处理「开发态」与「打包态」的资源路径 import sys from pathlib import Path def resource_path(rel: str) -> Path: # 打包后 PyInstaller 把资源解到 sys._MEIPASS 指向的目录 # 开发态没有这个属性，回退到当前文件所在目录 base = Path(getattr(sys, "_MEIPASS", Path(__file__).resolve().parent)) return base / rel # 用法：读配置不再写死相对路径 # cfg = json.loads(resource_path("assets/config.json").read_text(encoding="utf-8"))sys._MEIPASS是 PyInstaller 注入的运行时属性，单文件和单目录模式下都存在，指向资源实际所在的目录。用getattr加默认值，一套代码在开发和打包两种状态下都能跑，不用维护两份路径逻辑。
还有一种情况要区分：只读资源用_MEIPASS没问题，但程序运行时生成的文件（日志、缓存、用户配置）绝不能往那儿写，那个目录在退出时可能被清掉。这类文件应该落在Path(sys.argv[0]).resolve().parent，也就是 exe 同目录，或者用户的 AppData 下。
4.2 hiddenimports 与 hook 机制
静态分析靠扫import语句建依赖图，凡是运行时才决定导入什么的代码，它都看不见。典型的有三种：importlib.import_module(name)动态导入、插件式加载（扫目录找模块）、以及某些库在__init__.py里延迟导入子模块。
现象很好认：源码跑得好好的，打包后报ModuleNotFoundError: No module named 'xxx'。解决办法是在 spec 里补：
# 写模块名，不是文件路径；多个用逗号分隔 hiddenimports=[ 'pkg_resources', # setuptools 运行时依赖，常被漏 'sqlalchemy.dialects.sqlite', # 方言模块按需加载，静态分析扫不到 'myapp.plugins.default', # 自己的插件模块 ],模块一多，全堆在 spec 里就难维护了。更规整的做法是写自定义 hook。PyInstaller 会在hookspath指定的目录里找hook-<模块名>.py，找到就执行里面定义的变量：
# hooks/hook-mymodule.py # 文件名必须是 hook-<模块名>.py，PyInstaller 按模块名匹配 hiddenimports = [ 'mymodule._native', # C 扩展，动态加载 'mymodule.plugins.default', ]然后在 spec 里把目录挂上：
a = Analysis( ['hello_tool.py'], hookspath=['hooks'], # 相对 spec 所在目录 # ... )hook 的好处是跟着代码走。项目里新增一个模块，只在 hook 文件里加一行，spec 不用动。团队协作时，spec 归构建脚本管，hook 归模块作者管，职责清楚。
排查「到底收了哪些模块」有个实用手段：用pyi-archive_viewer打开产物看内部结构。
# 查看单文件 exe 里打包了哪些模块和文件 pyi-archive_viewer dist/demo_tool.exe进去之后按O可以打开子项，按X提取文件。模块明明装了却没进去，在这里一看就知道，比反复打包试错快得多。
4.3 窗口模式、图标与版本信息
控制台和窗口模式的切换，在 spec 里就是console=True/False一行，但切换时机有讲究。排查阶段一律console=True，等所有功能验证完，最后一次构建再改成False。反过来做的话，程序一崩就是无声无息，你连从哪儿查都不知道。
图标和版本信息是交付的门面，配起来不复杂：
# 命令行给图标，同时生成 spec 里的 icon 字段 pyinstaller --noconfirm --clean --name demo_tool -w -i assets/app.ico demo_tool.spec-w等价于console=False，-i指定.ico文件。Windows 上图标必须是真正的 ico 格式，把 png 改后缀名是没用的，构建时不会报错，但产物图标是空白的——这种「不报错但不对」的问题最耗时间。
版本信息需要单独一个文件，在 spec 的EXE里用version=引进去：
# version_info.txt —— 写进 EXE 资源段，Windows 右键属性里能看到 VSVersionInfo( ffi=FixedFileInfo(filevers=(1, 0, 0, 0), prodvers=(1, 0, 0, 0)), kids=[StringFileInfo([StringTable('080404b0', [ StringStruct('CompanyName', '某公司'), StringStruct('FileDescription', '模拟项目X 桌面工具'), StringStruct('FileVersion', '1.0.0.0'), StringStruct('ProductName', '模拟项目X'), StringStruct('ProductVersion', '1.0.0.0'), ])])] )080404b0是简体中文加 Unicode 的语言代码页标识，写错了版本信息不会显示。文件编码必须是 UTF-8，带 BOM 的话构建会报解析错误。
最后提一句 UPX。spec 里upx=True会让 PyInstaller 调用 UPX 压缩产物里的二进制，体积能小两三成，但代价是被杀软误报的概率明显上升，而且部分带签名的 dll 压缩后加载会失败。我的默认是关掉，体积问题优先用excludes解决，那个更安全。
5. 避坑与排查：闪退、缺库、误报、体积爆炸的五条救火记录
这一章是从现场记录里挑出来的五条，每条都按「现象 → 原因 → 解决」写。顺序按踩到的频率排，前两条基本人人都会遇到。
5.1 现象：双击闪退，没有任何报错
原因：console=False的产物没有标准输出，Python 层的异常被打到空设备上，等于没有。加上引导程序本身在解压阶段失败时也不会弹窗，所以表现就是「闪一下没了」。
解决：先打一个带控制台的调试版，把异常逼出来。
# 调试版：保留控制台，名字加 _debug 后缀，避免覆盖正式产物 pyinstaller --noconfirm --clean --name demo_tool_debug -c hello_tool.py如果连调试版都看不到东西，就在入口脚本最前面装一个兜底钩子，把未捕获异常写进 exe 同目录的日志文件：
# 兜底日志：任何未捕获异常都写进 crash.log，无控制台也能查 import sys, traceback, pathlib def _log_uncaught(exc_type, exc, tb): log = pathlib.Path(sys.argv[0]).resolve().parent / "crash.log" with log.open("a", encoding="utf-8") as f: traceback.print_exception(exc_type, exc, tb, file=f) sys.excepthook = _log_uncaughtsys.excepthook只兜得住 Python 层异常，兜不住「C 扩展加载失败导致进程直接退出」这种情况。后者要看 Windows 事件查看器里的应用程序日志，里面有模块加载失败的记录。
5.2 现象：ModuleNotFoundError，源码能跑打包不能跑
原因：静态分析没扫到动态导入的模块，或者模块本身是数据驱动的（比如按名字拼字符串导入）。还有一种隐蔽情况：模块装在全局环境里，虚拟环境里其实没装，源码能跑是因为你当时用的是全局解释器。
解决：先确认虚拟环境里真的有这个模块：
python -c "import xxx; print(xxx.__file__)"路径在.venv下，说明是打包漏收，往 spec 的hiddenimports里补；路径在全局site-packages下，说明是环境装错了，回到 2.2 重新装依赖。补完之后一定带--clean重新打包，否则缓存的旧分析结果会让改动看起来没生效。
5.3 现象：FileNotFoundError，配置文件读不到
原因：代码里用了open("assets/config.json")这种相对路径。开发时工作目录是项目根，能找到；单文件模式下工作目录是启动目录，_MEIPASS里那堆东西根本不在这个相对路径上。
解决：按 4.1 的resource_path()改读取逻辑，同时确认 spec 的datas里确实声明了这个文件。验证方法是把-D产物打开，看_internal/assets/config.json（新版本）或assets/config.json（旧版本）在不在。目录结构在哪个位置，取决于 PyInstaller 大版本，6.x 之后统一挪进了_internal目录，这个变化让不少老脚本的路径判断失效。
5.4 现象：体积从十几兆涨到两百兆
原因：环境里装了用不到的大包，被分析器顺带收进去。最常见的是matplotlib带了一堆测试数据和字体、pandas带了一堆可选后端、以及tkinter在某些环境下被拖进来。
解决：先用排除法瘦身，再考虑压缩。
# spec 里做减法，排掉确定用不到的大包 excludes=[ 'tkinter', # 没有 GUI 就别带 'matplotlib.tests', # 测试数据不参与运行 'numpy.tests', 'pytest', # 开发期依赖，绝不能进产物 ],改完重新打包，对比dist目录大小。一般能砍掉一半。剩下的还有优化空间，但优先级就不高了。要不要开 UPX 自己权衡，前面说过误报的代价。
5.5 现象：杀软直接隔离，同事根本打不开
原因：PyInstaller 的引导程序是自解压结构，行为特征和某些打包器高度重合，加上没有代码签名，启发式引擎很容易判成可疑。单文件模式比单目录模式更容易中招，UPX 压缩之后中招概率再翻一倍。
解决：能做的有三件事。一是关掉 UPX；二是给产物做代码签名，有证书的情况下这是最有效的办法；三是改成-D单目录模式分发，用压缩包整体下发，双击的是目录里的 exe。这三条都不保证百分百解决，因为判定规则在服务端，但在实际交付里能把大部分情况压下去。真要给外部客户，签名这一步绕不过去。
6. 装完怎么验证：三台机器、四个检查项的交付前确认
打包这件事，最贵的错误不是打不出来，而是打出来了、没验证、直接发出去。我见过最典型的一次：产物在开发机上跑得好好的，发到客户那儿发现缺一个 dll，那个 dll 只在开发机上有。从那以后我固定了一套交付前检查，四步走完才算完。
第一步，构建机自检。打完包先别急着拷走，在构建机上用-D产物跑一遍完整业务流程，不是只看窗口有没有出来。配置读写、文件导出、外部命令调用，全走一遍。
第二步，干净环境验证。找一台没装过 Python、没装过项目依赖的机器，把dist目录拷过去双击。这一步能暴露九成的「隐性依赖」——开发机上因为环境齐全，很多缺失根本表现不出来。
第三步，路径验证。把产物放到一个带中文和空格的路径下，比如D:\测试 目录\demo_tool.exe，再放一个 U 盘根目录下跑一遍。路径处理写得不严谨的代码，在这一步会露馅。
第四步，产物结构核对。用pyi-archive_viewer打开产物，确认关键模块和数据文件都在里面：
# 核对产物：模块名和资源名应该都能在列表里找到 pyi-archive_viewer dist/demo_tool.exe # 单目录模式下更直观，直接看收集了哪些文件 dir /s /b dist\demo_tool四个检查项整理成一张表，贴在构建脚本旁边：
| 检查项 | 执行位置 | 通过标准 |
|---|---|---|
| 业务流程 | 构建机 | 主流程完整走通，无异常 |
| 干净环境 | 无 Python 的机器 | 双击即开，功能正常 |
| 特殊路径 | 中文/空格/U 盘 | 不报路径相关错误 |
| 产物结构 | 构建机 | 关键模块和资源齐全 |
再补一个习惯：给每个产物算一次哈希，和版本号一起记进交付文档。
# 记录产物指纹，方便追溯「客户手上那份到底是哪个版本」 certutil -hashfile dist\demo_tool.exe SHA256真出问题时，客户报的那份是不是你构建的那份，一眼就能对出来。这一步听起来多余，但凡是发出去三五个版本之后，就一定会遇到「我这儿跑不了」但版本对不上的扯皮。
从那以后我每次打完包，都强制在一台没装过 Python 的干净机器上双击跑一遍，再算一次哈希，两件事只要有一件没做，这个包就不发。希望帮到你。
本文还有配套的精品资源，点击获取
