给业务侧的同事发了一版 OCR 标注工具，压缩包里连同一份两千多字的部署文档一起附上，对方回过来的第一句话是“这个是不是还得装 Python”。那一刻我才意识到，PPOCRLabel 这种工具真正的门槛从来不在算法，而在“双击能不能跑起来”。把 PPOCRLabel 打包成 exe，说穿了就是把一整套 Python 运行时、一套 Qt 界面框架、一份 OCR 推理引擎，再加上几百兆模型权重，全部塞进一个能被鼠标双击的入口里，同时还要保证它在这种“脱离源码目录”的环境下依然找得到自己的资源、插件和模型。这件事听起来像条一行命令就能解决的问题，实际动手你会发现 PyInstaller 默认抓不到的东西比抓得到的还多。下面这份内容适合两类人看：一是要把标注工具交付给非技术用户、不想每次都远程装环境的开发者；二是已经被“闪退但没有任何提示”折磨过一轮、想搞清楚到底卡在哪一环的人。我会按我自己的打包顺序，从依赖摸查、路径改造、spec 编写，一直写到体积裁剪和干净机器验收，中间踩过的坑尽量讲透。

1. 交付形态先定死：为什么最后走到 exe 这条路

动手之前必须先把一个前置问题想清楚：交付物到底是“一个能双击的文件”，还是“一套能被复现的环境”。这两个答案对应完全不同的技术路线，选错了后面所有工作都要推倒重来。我自己在这上面交过学费，第一版交付的是 conda 环境导出文件加一个 bat 脚本，技术上完全可行，结果对方团队的安全策略不允许在办公机上执行脚本，整个方案原地作废。

1.1 同一个问题反复出现三次，说明它不是偶发

第一次是给试用方做演示，现场网络受限，pip 装到一半卡住，演示时间全耗在等下载上；第二次是换了一台机器，系统里已经存在另一套 Python 环境，依赖版本冲突导致界面能起来但识别直接报错；第三次最典型，标注规范培训做完了，参与标注的同事打开文档第一步就卡在“命令提示符在哪”。这三次事故表面上分别是网络、版本、使用习惯问题，往下追一层其实是同一个根因：我把一个需要工程环境支撑的工具，交付给了一个没有工程环境的使用场景。

想明白这点之后，方案的评估维度就变了。不再问“哪种方式最优雅”，而是问“对方拿到手之后需要做几步操作才能开始标注”。答案如果是零步，也就是双击即可，那么剩下的所有技术取舍都得为这个目标让路。这也意味着我要接受一些不优雅的代价，比如最终产物几百兆、启动要等十几秒、某些功能在打包后行为略有差异。这些都是可以谈的，闪退才是不能谈的。

还有一点容易被忽略：标注工具的使用者往往不是最终的算法使用者。他们可能在离线内网、可能在临时借用的机器上、可能一周只打开两次。这类场景对“安装”这个动作的容忍度极低，而对你来说，一次打包做好，后面几十个人分发只是拷贝一个压缩包的事。投入产出比其实相当划算。

1.2 四条路线的取舍，以及我为什么选了 PyInstaller

把 Python 桌面程序变成 Windows 可执行文件，市面上能走的路不止一条。我把当时评估的几条列出来，方便你对照自己的场景做选择。

PPOCRLabel 的依赖结构里，OCR 推理引擎带着大量原生动态库，图形界面框架带着一批平台插件，这两类东西都属于“运行时按需加载”，静态分析很难全部捕获。Nuitka 在这种场景下编译时间长、兼容性排查成本高；conda-pack 产物最完整但启动还是绕不开脚本。PyInstaller 虽然要手工补依赖清单，但它对“把一堆动态库原样搬过去”这件事支持得最直接，出问题时的错因也相对好定位。这就是我最终选它的理由，不是什么最佳实践，而是当时最省心的那个。

1.3 使用者不会打开命令行，这一条决定了所有设计

这句话听起来像废话，但它会反向约束很多技术细节。比如打包时如果把控制台窗口关掉，程序崩溃你就什么都看不到，因为标准错误输出没有地方可去；可如果保留控制台窗口，用户每次打开都会看到一个黑框，体验很差，还可能被误认为程序出错。我的处理是准备两套构建：一套隐藏控制台用于正式分发，一套保留控制台并打开调试输出用于自己排错。两套共用同一份 spec，只改一个布尔值，成本几乎为零，但排错效率天差地别。

再比如“程序自己找模型”这件事。源码运行时，引擎会去用户目录下的缓存路径找模型，找不到就联网下载。打包之后如果目标机器完全离线，程序会安静地卡在下载环节，用户看到的就是“打开之后一直转圈”。所以正式分发版本必须把模型内置进去，并且在启动时显式指定模型目录，不能让程序走默认的下载逻辑。同理，预设标签文件、界面图标、字体资源，这些都得内置，否则界面能起来但功能残缺，用户依然会觉得“这东西坏了”。

把这三条串起来看，交付形态的选择其实在做减法：减少用户的操作步骤，代价是把复杂度全部前置到打包环节。接受这个前提，后面的工作才有明确的目标。

2. 摸清 PPOCRLabel 的启动链条，再决定往 spec 里塞什么

直接照着网上随便一份 spec 抄了就跑，大概率能打包成功但一运行就挂。原因很简单，PPOCRLabel 不是一个纯 Python 脚本，它是一个“界面 + 引擎 + 资源”三件套组合起来的桌面程序，每一件的加载方式都不一样。我的做法是先把它在源码状态下跑起来，用进程监视看一眼它到底加载了哪些动态库、读了哪些目录，再反推打包清单。这一步看起来费时间，实际上能省掉后面反复试错的几个小时。

2.1 三条加载线：入口脚本、Qt 主循环、推理引擎

第一条件是入口。PPOCRLabel 的源码目录下有一个主程序文件，里面定义了窗口类和一个入口函数，命令行python PPOCRLabel.py执行的就是它。打包时我会另外写一个极简的启动脚本，把参数解析、环境变量设置、资源路径修正都放进去，最后再调用主程序的入口函数。这么做的原因是：我不想去改源码里的任何一行，任何一个上游更新都可能让我的修改冲突，而独立的启动脚本是隔离的，上游再怎么变，我这层壳子基本不用动。

第二条线是 Qt 主循环。界面框架在启动时会去加载“平台插件”，Windows 上就是那个负责把窗口画出来的动态库。这个插件不在你的代码目录里，而在框架安装目录下的一个子文件夹中。PyInstaller 通常能把它带进来，但带进来之后放在哪个相对位置，程序运行时能不能找到，是另一回事。这一块是打包后报错率最高的地方，后面单独讲。

第三条线是推理引擎。它体积最大、动态库最多，而且加载方式是“运行时按名字找”。有些模块在代码里是通过字符串动态导入的，静态分析看不见，打包时就被漏掉了。漏掉的后果是程序启动到一半抛出一个 ImportError，而如果此时控制台是隐藏的，用户只会看到一个闪一下就消失的窗口。我的处理方式是把引擎的核心子模块整体纳入隐式导入清单，宁可多带一些，也不要漏。

2.2 静态分析抓不到的四类东西

在实际打包里，被漏掉的依赖基本集中在下面四类。我把它们和对应的表现、解法整理成表，这个表我几乎是当成检查清单在用。

第三类需要多说一句。有些库的动态库并不是放在包根目录，而是散在几个子目录里，随便漏一个就会出现“程序能启动但一调用就崩”的情况，而且崩的位置离真正的原因很远，排查起来非常痛苦。稳妥的做法是按包名整包收集动态库，再用排除清单做减法，而不是反过来一个个手工添加。

第四类也很隐蔽。源码运行时，程序的工作目录就是源码目录，写配置文件、写临时文件都没问题。打包成单文件模式后，程序解压到一个临时目录运行，这个目录在程序退出后会被清理，你在里面写的任何东西都会丢。如果程序有“记住上次打开的目录”这类功能，表现就是每次打开都回到默认状态。解决办法是把所有需要持久化的路径统一重定向到用户目录下的一个固定文件夹，这一点必须在启动脚本里做掉。

2.3 版本组合比版本新旧重要得多

我见过太多人在这上面翻车：把所有依赖都升到最新，打包成功了，运行起来识别精度莫名其妙下降，或者某个后处理模块直接报错。OCR 这类工具链里，推理引擎、模型文件、上层工具包三者之间有隐式的版本对应关系，模型是跟着某个引擎版本训练和导出的，跨版本使用不一定报错，但结果可能不对，这种问题比崩溃更难查。

我的做法是先在源码状态下确定一组“能跑通完整标注流程”的版本组合，把这组版本号写进依赖文件，然后打包时严格按这组来。判断标准不是版本号高低，而是三个动作能不能顺利完成：打开一张图、自动标注出框、导出识别结果。这三个动作跑通，说明整条链路是通的，可以进入打包环节。至于 Python 解释器版本，我的经验是跟着推理引擎的官方支持范围走，不要用太新的小版本，因为预编译的原生库往往滞后。

另外提醒一句，打包环境一定要干净。如果你的开发环境里装了几十个不相关的包，PyInstaller 的静态分析有可能把它们误判进来，产物会莫名其妙变大，甚至引入冲突。用全新的虚拟环境从零装依赖，是控制产物体积最有效的手段之一，比后面做任何裁剪都管用。

3. 从干净环境到可双击的产物：完整实操过程

这一节是具体的动手部分。我会按我实际的顺序写：建环境、改路径、写 spec、跑构建、验收产物。每一步我都会说明为什么这么做，因为同样的步骤换个项目可能就不适用，理解意图比照抄命令更有价值。

3.1 建一个只装必要东西的虚拟环境

第一步是创建虚拟环境，我习惯把它放在项目目录外面，避免被打包工具扫进去。创建之后先装推理引擎，再装标注工具所在的工具包，最后装打包工具。安装顺序有讲究：先装底层的，让它自己决定依赖版本；后装上层的，如果出现版本冲突能第一时间发现。反过来装的话，冲突可能被静默覆盖，等到运行时才炸。

装完之后做一件事：把当前环境的包列表导出，人工过一遍。凡是跟界面、识别、图像处理无关的包，比如各种 notebook、可视化、测试框架，如果被顺带装进来了，就在打包时排除掉。这一步能省下不少体积，我实测过一个环境里光某可视化库及其依赖就占了接近一百兆，而这个工具根本用不到它。

提示：不要在全局 Python 环境里打包。全局环境里的包数量不可控，静态分析的结果会非常不稳定，同一个 spec 在不同机器上打出来的产物大小可能差出一倍。

环境准备好之后，先用源码方式把三个核心动作跑一遍，确认环境本身没问题。这一步不能省，因为如果源码状态就跑不通，你根本分不清后面打包出的问题是环境问题还是打包问题。

3.2 资源路径改造：让同一份代码同时认两种目录

这是整个打包过程中最关键的一处改动，也是最容易被跳过的一处。源码运行时，资源文件的路径是相对于当前文件所在目录的；打包之后，资源被搬到了一个临时解压目录，两者的基准点不一样。如果代码里到处写死了相对路径，打包后必然找不到文件。

我的做法是在启动脚本里定义统一的路径解析函数，把“基准目录”这个概念抽出来：

import os import sys def app_base(): # 打包后 PyInstaller 会把资源解压到 _MEIPASS 指向的目录 bundled = getattr(sys, "_MEIPASS", None) if bundled: return bundled return os.path.dirname(os.path.abspath(__file__)) def res_path(*parts): return os.path.join(app_base(), *parts)

然后在启动脚本里，把程序启动前需要设置的几个目录全部指向解析后的路径：界面资源目录、预设标签目录、模型目录。如果工具本身支持通过参数指定这些路径，那就更简单，直接从启动脚本传参进去，完全不用碰源码。

这里有一个细节值得单独说：可写目录必须和资源目录分开。资源目录在单文件模式下位于临时目录，退出即清理；用户的操作记录、最近打开列表、自定义标签，这些要持久化，就得写到用户目录下，比如系统提供的应用数据目录。我会在启动时检查这个目录是否存在，不存在就创建。这一步做不好，用户会觉得“这软件记不住东西”，虽然不影响核心功能，但体验会打折扣。

3.3 spec 文件逐段写法与每一行的理由

打包工具有两种用法：命令行参数和 spec 文件。前者适合一次性试验，后者适合长期维护。我强烈建议直接用 spec，因为参数一多命令行就没法看了，而且 spec 是可以进版本库、可以复现的。

下面是我用的结构，注释里写清楚每段的意图：

# ppocrlabel.spec from PyInstaller.utils.hooks import collect_data_files, collect_dynamic_libs, collect_submodules # 1) 隐式导入：静态分析看不见的动态导入模块 hidden = [] hidden += collect_submodules("paddle") # 推理引擎核心 hidden += collect_submodules("paddleocr") # 上层工具包 hidden += [ "PyQt5.sip", "shapely", "pyclipper", "cv2", ] # 2) 数据文件：非代码资源，按 (源目录, 目标目录) 映射 datas = [] datas += collect_data_files("paddle") datas += [("libs/resources", "libs/resources")] # 图标、字体 datas += [("data", "data")] # 预设标签 datas += [("models", "models")] # 内置模型 # 3) 原生动态库：整包搬运，再靠 excludes 做减法 binaries = [] binaries += collect_dynamic_libs("paddle") binaries += collect_dynamic_libs("cv2") a = Analysis( ["run_ppocrlabel.py"], # 我们自己写的启动壳 pathex=[], binaries=binaries, datas=datas, hiddenimports=hidden, hookspath=[], runtime_hooks=[], excludes=[ "matplotlib", "pandas", "IPython", "notebook", "tkinter", "pytest", ], noarchive=False, ) pyz = PYZ(a.pure) exe = EXE( pyz, a.scripts, [], exclude_binaries=True, name="PPOCRLabel", debug=False, strip=False, upx=False, console=False, # 正式版关控制台；排错版改 True icon="libs/resources/app.ico", ) coll = COLLECT( exe, a.binaries, a.datas, strip=False, upx=False, name="PPOCRLabel", )

几个地方值得展开。第一，console=False和debug=False是一对，关掉控制台之后所有输出都没地方去，所以我在排错阶段一定会单独构建一个console=True的版本，两者共用其余配置。第二，我选了目录模式（COLLECT）而不是单文件模式，原因是单文件模式每次启动都要把几百兆内容解压到临时目录，冷启动要等十几秒，用户会以为程序卡死了；目录模式虽然是一堆文件，但把整个目录压缩成一个包分发，用户解压后双击里面的 exe 即可，体验差别不大而启动快得多。第三，压缩选项我关掉了，某些原生库被压缩后加载会出问题，而且压缩收益在这个体量下并不明显，稳定性优先。

至于upx=False，这是有意为之。用可执行文件压缩工具处理原生库，有一定概率导致加载失败，尤其是有数字签名的库，压缩后签名失效还可能触发安全软件的额外检查。省下的那点体积不值得冒这个风险。

3.4 首次构建与产物验收的三个动作

构建命令很简单，指定 spec 文件即可：

pyinstaller --clean --noconfirm ppocrlabel.spec

--clean会清掉缓存，避免上一次的中间产物干扰；--noconfirm避免覆盖确认卡住自动化流程。第一次构建通常要跑几分钟，取决于依赖规模。

产物出来之后不要急着分发，先在打包机上一个全新的目录里验收。注意是全新目录，不是原来那个目录，因为原目录里有源码在，程序很可能悄悄用到了源码路径下的资源，让你误以为打包成功了。验收就做三个动作：双击启动看界面是否完整、打开一张图片试自动标注、导出一份标注结果确认文件内容正常。三个动作都过，才算初版可用。

这一步我踩过的坑是：界面起来了，图标也正常，自动标注也能跑，但导出的结果文件是空的。查了半天发现是导出模板文件没被打进去，程序静默地跳过了写入。所以验收一定要覆盖“输出”环节，不能只看界面。

4. 打包后那些让人抓狂的报错，按链路一条条排

打包成功率高，运行成功率高才是真的难。这一节我按“症状 → 定位手段 → 根因 → 修法”的顺序写，你可以直接照着症状对号入座。需要强调的是，排查这类问题的第一原则永远是让错误可见，先构建一个带控制台的版本，把输出留下来，再看日志。这一步不做，后面全是盲猜。

4.1 双击之后窗口一闪就没了，什么提示都没有

这是最典型也最让人抓狂的症状。本质原因是程序在界面初始化完成之前就异常退出了，而错误信息写到了标准错误，你配置的是无控制台模式，输出直接丢弃。

定位手段：把 spec 里的console改成True，重新构建，然后从命令行运行一次产物，让错误打印在终端里。如果连终端里都看不到，就加一个顶层异常捕获，把完整调用栈写进日志文件：

import traceback, datetime, os, sys def main(): try: run_app() except Exception: log_dir = os.path.join(os.path.expanduser("~"), "PPOCRLabel_logs") os.makedirs(log_dir, exist_ok=True) stamp = datetime.datetime.now().strftime("%Y%m%d_%H%M%S") path = os.path.join(log_dir, f"crash_{stamp}.log") with open(path, "w", encoding="utf-8") as f: f.write(traceback.format_exc()) raise if __name__ == "__main__": main()

这个日志出口在正式版里也建议保留，只是不弹窗提示。用户遇到问题时，让他们把日志文件发过来，比问“你点了什么”有效一百倍。

常见根因有三个：一是动态导入的模块缺失，报 ImportError；二是资源路径找不到，抛 FileNotFoundError；三是原生库加载失败，抛 OSError 或直接进程级崩溃。前两个从日志里一眼能看出，第三个往往日志里只有一行，需要结合下面几节排查。

4.2 界面起不来，提示找不到平台插件

症状是弹一个对话框，内容大致是“could not find or load the Qt platform plugin windows”，或者干脆静默退出。这是打包后发生率最高的一类问题，根因是框架在运行时按相对路径去找插件目录，而打包后的目录结构和它预期的不一致。

定位手段：先确认插件文件到底有没有被打进产物。去产物目录下找那个放平台插件的子文件夹，看里面有没有对应 Windows 的动态库。如果没有，说明收集环节漏了；如果有但依然报错，说明是路径没对上。

修法分两种。第一种是在 spec 里显式声明插件目录的数据映射，确保它在产物里的相对位置符合框架预期。第二种是在启动脚本里，程序初始化界面之前设置环境变量，把插件路径直接指过去：

import os, sys from pathlib import Path base = Path(getattr(sys, "_MEIPASS", Path(__file__).parent)) plugin_dir = base / "PyQt5" / "Qt5" / "plugins" / "platforms" if plugin_dir.exists(): os.environ["QT_QPA_PLATFORM_PLUGIN_PATH"] = str(plugin_dir)

我个人更倾向第二种，因为它不依赖打包工具对目录结构的默认安排，可预期性更强。注意这段代码必须在任何界面相关模块被导入之前执行，顺序错了不生效。这也是我坚持用独立启动壳的原因之一：我需要一个明确的“所有环境变量设置完成之前不导入界面库”的位置。

还有一种变体：界面能起来但字体全变成方块，或者中文显示成乱码。这通常不是插件问题，而是字体资源没带过去，或者系统的字体缓存路径在打包环境下不可用。处理方式是把需要的字体文件作为数据文件带上，并在启动时注册字体。

4.3 自动标注一点就报错，提示模型文件不存在

源码运行时没有这个问题，因为引擎会自己去缓存目录找模型，找不到就下载。打包之后，缓存目录里可能是空的，而目标机器又没网，于是程序卡住或者报错。

定位手段：看日志里的路径。如果报错信息里出现的是一个用户目录下的隐藏文件夹，那基本可以确定它还在走默认查找逻辑。

修法是把模型内置并显式指定。在启动脚本里把模型路径作为参数传进去，同时把模型目录配置成数据文件打进产物：

import argparse, sys def build_args(): parser = argparse.ArgumentParser() parser.add_argument("--det_model_dir", default=res_path("models", "det")) parser.add_argument("--rec_model_dir", default=res_path("models", "rec")) parser.add_argument("--cls_model_dir", default=res_path("models", "cls")) parser.add_argument("--use_gpu", default="false") return parser.parse_args()

use_gpu这个参数单独提一下。打包分发的机器五花八门，很多没有独立显卡，甚至没有对应的运行库。默认关掉 GPU 推理是最稳的选择，虽然速度慢一些，但不会因为找不到设备而崩溃。如果确实有性能要求，可以做成启动时检测，检测到可用设备再开启，检测逻辑本身也要包在异常捕获里。

另一个隐蔽的坑是模型目录里文件的完整性。内置模型时容易漏掉配置文件或者字典文件，表现是模型能加载但识别结果全是乱码或者空字符串。我的检查方式是：把模型目录完整拷出来，在一个全新目录里做一次独立验证，确认这套文件自洽，再打进产物。

4.4 加载原生库失败，报错信息里带 dll 字样

症状是提示某个 dll 找不到，或者加载失败。这类问题排查起来最费时间，因为它可能是三种原因之一：文件没被打进去、文件打进去了但依赖的其他库缺失、文件都在但位数或版本不匹配。

定位手段：用依赖查看工具打开报错的那个 dll，看它的依赖树里有没有标红的项。这一步能快速区分是“缺文件”还是“缺依赖”。同时确认产物里的 Python 解释器位数和目标机器一致，32 位和 64 位的库混用是经典事故。

修法：缺文件就用二进制收集函数按包名补全；缺依赖就顺着依赖树继续补，有时候需要把系统级的运行库一起带上；位数不匹配只能换环境重打。还有一种情况是路径里有中文或空格导致加载失败，这个在打包环境下反而更常见，因为临时目录的路径可能很长且包含用户名字。解决办法是尽量让程序在启动时使用短路径，或者把工作目录切到一个简单路径下。

注意：不要在打包机上装完就断言“在我的机器上是好的”。打包机往往装了完整的开发工具链和运行库，很多依赖是系统级的，产物在你这里能跑不代表在别人那里能跑。真正的验收必须在干净机器上做。

5. 体积、误报与最终分发：最后一公里的活

产物能跑通之后，剩下的是工程性的收尾工作。这部分没有太多智力含量，但直接决定用户第一次打开时的观感。一个接近一个 G 的压缩包发过去，对方大概率会先问“这里面装了什么”，信任成本比技术成本更高。

5.1 体积到底被谁吃掉了，先量化再动手

盲目删文件是最容易把程序删坏的做法。我习惯先按目录统计体积，看清楚占比再决定砍哪里。

量化之后你会发现，真正的大头是原生库和模型，界面框架反而不是重点，很多人花大量时间去删界面资源，收益微乎其微。方向错了，努力就白费。

5.2 模型裁剪与加载策略，比删库更划算

模型通常是体积里最容易优化的一块。方向分类模型如果实际业务用不上，完全可以不带；识别模型如果有轻量版本，精度损失在可接受范围内的前提下换轻量版，体积能降不少。我一般的做法是先跟使用方确认标注场景，如果主要是横排文字、方向基本一致，方向分类这一环可以直接省掉。

另一个思路是拆包。把主程序和模型分开，主程序保持小体积，模型按需加载。这样多个使用方共用同一个主程序，只是模型不同，分发时也更灵活。代价是用户需要把模型放到指定目录，多了一步操作，跟“零步骤”的目标有点冲突，所以我会把这个做成可选项而不是默认。

加载策略上还有一个细节：不要在程序启动时就把所有模型都初始化。启动阶段只加载界面，等用户第一次点自动标注时再懒加载模型。这样冷启动会快很多，用户感知到的“打开就出来了”，体验提升明显。这个改动在源码里可能只需要挪几行初始化代码，但对打包后的观感影响很大。

5.3 安全软件误报和签名的现实处理

打包出来的可执行文件被安全软件拦一下，几乎是必然会遇到的事。原因通常是这类工具的特征：未签名、体积大、运行时释放文件、加载大量原生库。这些特征本身没有恶意，但和某些启发式规则重合。

能做的事情有三件。第一，尽量不用可执行文件压缩，压缩后的文件特征更容易触发误报。第二，给产物加上完整的版本信息，包括产品名称、版本号、描述，这些可以通过 spec 里的版本文件配置，让文件看起来“有出处”。第三，如果分发范围较大，考虑做代码签名，这是最彻底的解法，但需要证书成本，小范围内部分发不一定值得。

实际应对上，我会在分发说明里提前写清楚：如果被拦截，如何添加信任、如何校验文件的完整性（比如附上校验值）。把这件事提前说清楚，比让用户自己摸索要好得多，也避免了“这软件是不是有毒”的疑虑。

5.4 干净机器验收清单，这一步不能省

最后一轮验收我固定在一台没装过任何开发环境的机器上做，按清单逐项过。这份清单我用了很多次，帮我在分发前拦下过好几类问题。

第八项特别容易被忽略。如果程序把配置写在了临时目录，第二次打开就会“失忆”。这个问题的根因就是前面说的可写目录没重定向，验收时能一次性发现。

最后再分享一个我在实际操作中的体会：打包这件事的成本大头不在第一次成功，而在后续的可维护性。上游工具更新一次，依赖版本变动一次，你都要重新走一遍构建和验收。所以从第一天起就把 spec 文件、依赖版本文件、启动壳脚本、验收清单全部纳入版本管理，每次构建前先提交一次基线。等半年后你需要重新打一个版本，会庆幸当初多做了这一步。我现在还习惯在产物目录里放一个文本文件，记录构建日期、依赖版本组合和 Python 版本，出问题时对着这行字就能定位到具体哪次构建，比翻聊天记录靠谱得多。