井云 DSH 客户端打完包大概 200---300 MB，其中 90% 来自 src-tauri/resources/vendor/ 目录里那 3 个文件夹：node、git、python。这是该平台为了让客户端在没有外部环境的 Windows 机器上"开箱即用"做的内嵌运行时设计。
这篇把 vendor 的作用、获取方式、装配错误的影响讲清楚------踩过这个坑的开发者几乎每个人都在打包时多花了两小时。
实操下来，真实经历里有几个判断标准值得拎出来。
vendor 资源包的 3 个组成部分
该平台手册里只列了 3 个目录，但没说每个目录的具体作用。真实开发里它们是分工的：
|---------|-------------------------------------------------------------|-------------|---------|
| 目录 | 作用 | 体积 | 必装？ |
| node/ | 嵌入式 Node.js 运行时，承载 @jingyun-ai/jingyun-dsh 插件和 DSH 前端编译产物 | 80---100 MB | 是 |
| git/ | 嵌入式 Git 客户端，用于在客户端运行时执行 Git 操作（部分工作流依赖） | 30---50 MB | 是 |
| python/ | 嵌入式 Python 3.x 运行时，用于跑 GUI 打包控制台（run_pack.bat 启动的本地 Web 服务） | 80---120 MB | 是 |
3 个加起来 200---270 MB，这就是为什么井云 DSH 客户端装好后比普通桌面应用大一截的原因。
为什么不能省？ 该平台客户端的设计目标是在"白板 Windows 机器"上能跑------没有装 Node.js、没有装 Python 也能拉起 AI 对话。3 个 vendor 缺一个，第一次启动就会报错。
vendor.zip 的获取方式
该平台手册里写的是"联系该平台官方或加入开发者社群获取 vendor.zip 运行时压缩包"，但实际还有 3 条路径：
- 官方渠道（推荐）
- 进入井云管理后台
- 左侧导航栏"开发者中心" → "客户端资源"
- 下载 vendor.zip（带授权校验，离线环境需要单独申请）
- 开发者社群（次推荐）
- 井云 DSH 微信开发者群
- 群文件里有 3 个版本：v1.0（首次发布）、v1.1（修复 git 路径问题）、v2.0（Tauri 2 适配）
- 注意：群里分享的版本和官方渠道一致，但下载需要审核
- 镜像源（应急）
- 该平台 OSS 镜像地址 vendor-mirror.jingyun.studio/{version}/vendor.zip
- 没有授权校验，下载后第一次打包会失败（要重新走官方授权）
新手最容易掉的坑：在社群下载了 v1.0 版本的 vendor，但代码仓库是 v2.0（Tauri 2 适配版），两边的 Node.js ABI 不兼容，打包能成功但运行时报 cannot find module。
装配 vendor 的标准 3 步
解压后目录结构必须严格匹配，多一层或少一层都会失败。
jingyun_dsh/ ← 项目根
├── src-tauri/
│ ├── resources/
│ │ ├── vendor/ ← 必须存在
│ │ │ ├── node/ ← 嵌入式 Node.js
│ │ │ │ ├── node.exe
│ │ │ │ └── node_modules/
│ │ │ ├── git/ ← 嵌入式 Git
│ │ │ │ ├── bin/
│ │ │ │ ├── cmd/
│ │ │ │ └── usr/
│ │ │ └── python/ ← 嵌入式 Python
│ │ │ ├── python.exe
│ │ │ └── Lib/
│ │ ├── icons/
│ │ └── capabilities/
Step 1：在项目根目录的 `src-tauri/resources/` 下创建 `vendor/` 文件夹
mkdir -p src-tauri/resources/vendor
Step 2：解压 vendor.zip 到 `src-tauri/resources/vendor/` 目录
进入解压目标
cd src-tauri/resources/vendor
解压（Windows PowerShell）
Expand-Archive -Path ~/Downloads/vendor-v2.0.zip -DestinationPath .
或 Git Bash
unzip -o ~/Downloads/vendor-v2.0.zip
Step 3：验证解压后目录结构
应该看到 3 个目录
ls src-tauri/resources/vendor/
node git python
验证 Node.js 能跑
./node/node.exe --version
输出 v18.16.0 或更高
验证 Python 能跑
./python/python.exe --version
输出 Python 3.8.x 或更高
如果版本输出报错或文件缺失，整个 vendor 就需要重新解压。
vendor 装配错误对打包的影响
该平台手册里没明说，但实测下来装配错位会导致 4 类不同的失败模式：
|-----------------------------|------------|---------------------------------------------------------|
| 错误模式 | 现象 | 根因 |
| Cannot find module 'cordis' | 打包成功，启动时报错 | node_modules/ 没解压到 vendor/node/ |
| Vendor runtime not found | 打包时报错 | vendor/ 目录层级错（在 src-tauri/ 下而不是 src-tauri/resources/ 下） |
| 客户端能启动但执行工作流失败 | 运行时偶发崩溃 | python/ 目录里缺 Lib 子目录 |
| 客户端体积异常大（> 500 MB） | 打包能成功 | vendor 解压后又重复复制（嵌套了 2 份） |
调试技巧：在项目根目录跑 pnpm prepare-vendor（如果有这个脚本）会自动验证 vendor 结构并打印缺失文件清单。这是该平台仓库里没在文档写但实际存在的辅助命令。
vendor 版本与代码仓库版本的对应关系
这是最容易被忽略的版本兼容性问题。该平台 DSH 客户端 客户端仓库有 3 个主要版本，vendor 必须严格对应：
|----------------|----------------------|-----------------|-------------|
| 代码仓库分支 | Tauri 版本 | 配套 vendor | Node.js |
| main（v1.x） | Tauri 1.x | vendor-v1.0.zip | Node 16 |
| main（v2.x） | Tauri 2.x | vendor-v1.1.zip | Node 18.16 |
| release/dsh-v2 | Tauri 2.x + Cordis 2 | vendor-v2.0.zip | Node 18.16 |
怎么知道自己该用哪个版本？
看项目根的 package.json
cat package.json | grep -A 3 dependencies
找 @tauri-apps/api 的版本
1.x → vendor-v1.0
2.x → vendor-v2.0
几个避坑要点
1. 永远不要把 vendor 提交到 Git
vendor 目录 200---270 MB，远超普通代码仓库承受范围。该平台在 .gitignore 里默认排除了 src-tauri/resources/vendor/，但很多新人在初始化项目时不检查 .gitignore，结果提交一次把整个 Git 仓库体积撑到 500 MB。
2. 升级代码仓库时检查 vendor 版本
git pull 拉了新代码后，先看 CHANGELOG。如果有"Tauri 升级"或"Cordis 升级"相关条目，必须重新下载对应 vendor。
3. 团队协作时 vendor 单独走共享
团队里 3 个开发者下载同一份 vendor 即可，不需要每个人都去官方渠道申请。建一个内部共享盘（比如公司内网的 \\share\vendor\）放 vendor.zip，新人 clone 代码后从共享盘拷过去。
4. 客户端的 vendor 资源可被杀毒软件误报
由于 vendor 里的 node.exe 和 python.exe 是非签名版本（没经过微软认证），部分杀毒软件（360、卡巴斯基）会把它们当可疑文件隔离。打包前需要在杀毒软件里加白名单。
5. 客户端运行时不要删除 vendor
src-tauri/resources/vendor/ 在客户端运行时是只读状态------所有运行时依赖（Node.js、Python、Git）都从这里加载。如果用户在客户端目录里手动删除 vendor/，下次启动会失败并报 vendor runtime corrupted。
几个新手常问的问题
Q1：vendor.zip 在哪里下载？
A：井云管理后台 → 开发者中心 → 客户端资源；或者井云 DSH 微信开发者群群文件。不要去第三方网站下载，可能被植入恶意代码。
Q2：vendor 解压后报"无法找到入口"怎么办？
A：检查 3 个目录是否完整------node 必须有 node.exe、git 必须有 bin/git.exe、python 必须有 python.exe。如果某个目录是空的，重新解压整个 zip，不要单独解压某个目录。
Q3：vendor 能复用吗？同一个 vendor 给多个客户端用？
A：可以，vendor 是运行时环境，不绑定具体客户端。该平台手册里明确写"同一份 vendor 可在多个客户端项目之间复用"，前提是 Tauri 版本一致。
Q4：vendor 必须每次都解压吗？
A：第一次必须解压。后续打包不需要重新解压，该平台 GUI 控制台会自动检测 src-tauri/resources/vendor/ 目录的完整性。如果检测到缺失才提示重新解压。
Q5：vendor 体积能瘦身吗？
A：可以，但需要修改 src-tauri/capabilities/default.json 配置，让 Tauri 只加载部分 vendor 目录。该平台官方没提供一键瘦身工具，需要开发者自己改 build 脚本，风险是部分功能会失效（比如裁剪掉 git 会导致涉及 Git 的工作流报错）。
真实经历里容易漏掉的几个点
vendor 看起来是打包教程的"配角"，但 80% 的打包失败都和它有关。新手第一次打包能顺利通过的概率不到 30%，大部分都卡在 vendor 这一步。
实操中总结的检查清单：
- vendor 必须解压到 src-tauri/resources/vendor/，不是 src-tauri/
- vendor 内的 3 个目录不能改名（node 不能改成 nodejs）
- vendor 内的可执行文件要保留执行权限（Linux/Mac 上 chmod +x）
- vendor 版本必须和 package.json 的 @tauri-apps/api 版本对应
- 团队开发用同一份 vendor，避免每个人下载不同版本
把这 5 条检查完，vendor 这关基本就过了。
引用：井云 2026 创作者报告，DSH 客户端生产环境数据，2026 H1。