★ FEATURED ARTICLE 1. 先把sb3转exe这件事想清楚需求拆解与方案选型我这些年被问得最多的一类问题就是我孩子/我自己用积木编程做了个作品怎么发给别人发给同学、发给亲戚、发给老师对方电脑上没有装对应环境双击一个 .sb3 文件图标是白的打不开或者打开了是一堆看不懂的东西。这时候sb3转exe这四个字就会冒出来——把工程文件变成 Windows 上双击就能跑的 .exe插到 U 盘里送人都行。但这里有个认知偏差必须先掰正sb3 转 exe 不是编译而是打包。它不像 C 语言那样把你的逻辑翻译成机器码而是把运行时 你的工程捆成一个可执行文件——本质上是给一个浏览器内核穿上 exe 的外壳再把工程塞进去让它自动加载。这个认知决定了后面所有的技术选型、体积预估和踩坑方向。你要是按编译的思路去期待它就会在为什么生成的 exe 有 80MB这种问题上反复困惑。这篇文章适合三类人看第一类是做了作品想分发的创作者需要一条能走通的完整路径第二类是帮孩子处理作品的家长需要知道哪些环节容易出岔子第三类是想自己写打包脚本、做批量处理的开发者需要了解底层结构和可控点。我下面会把三条主流路线摊开对比然后手把手走一遍完整流程最后把那些文档里不会写的坑一条条列出来。1.1 sb3 文件的真实结构它其实是个压缩包很多人不知道sb3 后缀的文件本质上就是一个 ZIP 压缩包。你可以直接把扩展名改成 .zip用解压软件打开里面通常是这样的结构project.sb3 (改名为 .zip 后解压) ├── project.json # 工程描述文件所有角色、积木、变量、广播都在这里 ├── b3a7f2c1d4e5...svg # 角色造型文件名通常是一串哈希 ├── 9c8e1f3a2b6d...png # 位图造型 ├── 4f2a8c9e1b3d...wav # 声音文件 └── ...project.json是整个工程的大脑它用 JSON 结构描述了舞台尺寸、每个角色的坐标、造型和声音列表、积木脚本的嵌套关系、变量初值、消息广播的名字。而所有素材文件都被重命名成了一串哈希值靠project.json里的assetId、md5ext字段去对应。这个结构带来两个直接影响。第一打包工具做的事其实是解开 zip → 读取 project.json → 用运行时把积木重新翻译成 JS → 把素材路径改成相对路径 → 再塞进壳里。第二素材的哈希命名是很多素材丢失问题的根源如果打包工具在处理素材时没有正确维护名字映射运行时按assetId去请求文件就会 404表现出来就是角色没了声音不响。所以你在动手之前先做一件事把 sb3 复制一份改后缀解压用文本编辑器打开project.json看两样东西——stage里的tempo、videoTransparency等配置项以及有没有extensions字段。如果extensions里出现了非原生的扩展名说明这个工程依赖了额外加载的扩展打包后极有可能失效必须先处理。1.2 三条路线横向对比别一上来就选最重的我见过太多人一上手就奔着 Electron 去结果环境配了两小时打包出来 120MB最后发现其实只要一个 html 就能解决问题。路线选择应该从分发场景倒推。路线产物形态典型体积上手难度可控性适用场景在线打包服务转 HTML.html 单文件或文件夹1~5MB极低低发给有浏览器的同学、传到班级群、嵌到网页桌面壳封装Electron / NW.js.exe 单文件或安装包60~150MB中高比赛提交、离线展示、需要全屏锁定自建运行时 自定义启动器.exe 资源目录40~100MB高最高需要加授权、加菜单、加数据统计第一列那条路最省事在线打包服务把 sb3 直接编译成 HTML JS 素材输出一个文件夹或一个自包含的 html。双击用浏览器打开就能玩甚至可以传到任意静态托管上做成链接。它的缺点是必须依赖浏览器全屏体验一般而且用户能看到地址栏、能按 F12对于想让孩子专注玩的场景不太友好。第二条路就是标题里说的转 exe。用 Electron 或 NW.js 起一个空壳主进程只做一件事创建一个窗口加载你打包好的 index.html禁用菜单、禁用右键、按 Esc 不退出全屏。这条路的好处是你能控制窗口标题、图标、尺寸、是否可缩放、是否允许快捷键做出来的东西看起来就是个正经软件。代价是体积——Electron 的运行时本身就有几十兆这是省不掉的。第三条路是给有特殊需求的人准备的。比如你想在启动时读一个配置文件决定加载哪个作品或者想在退出时把成绩写进本地文件那就得自己写主进程逻辑把打包器生成的 web 产物当资源塞进去。这条路我一般不建议新手碰但如果你打算做一系列作品分发一次性把脚手架搭好后面每个作品换资源就行反而一劳永逸。1.3 什么情况下转 exe纯属折腾说句实话不是所有作品都值得打包成 exe。我总结了几条判断标准你可以对照一下作品体量很小、交互简单比如就是个会走路的猫、点一下换个造型。这种直接用 HTML 发链接更合适为它背 80MB 的壳没有意义。必须在手机上玩exe 是 Windows 的东西打包再漂亮也上不了手机。有移动端需求就老老实实走 HTML 路线。依赖在线服务作品里用了在线变量、在线排行榜、需要联网加载的扩展。打包成 exe 后这些能力大概率失效得先做本地化改写。需要频繁更新exe 发出去就是死的改一版就得重新发一遍用户还得重新下载。如果作品还在迭代期先发 HTML 链接等定稿了再打包。要提交到需要审核的场合某些比赛或展示场合对可执行文件有明确限制动手前先确认规则。反过来这几种情况打包成 exe 就很值要在没有网络的展台上循环播放、要交给完全不懂电脑的人双击就能看、要防止玩家中途切出去干别的、要把多个作品合成一个合集发出去。2. 打包前的准备工作素材、依赖与体积账我踩过最亏的一次坑是花了四十分钟打包、又花了二十分钟上传结果对方打开是白屏。回头一查工程里有个造型引用了本地硬盘上一个早就被删掉的图片路径。打包之前不做体检等于把问题封装进 exe 里而且更难排查——因为你面对的不再是一个能看到控制台的项目而是一个黑盒。所以这一章我把它单独拎出来讲因为它的价值比点哪个按钮高得多。2.1 素材体检路径、命名与格式三件事第一件事是清掉所有指向本地的绝对路径。图形化编程里有几种情况会引入本地路径导入造型时选择的本地文件、录音功能生成的临时文件、某些扩展里填的路径参数。这些在你自己电脑上跑得好好的因为文件还在一旦打包分发对方电脑上没有那个路径资源加载就会失败。检查办法是把工程另存一份副本把所有角色和造型在资源面板里逐个点开看一眼发现来源不明的就重新导入一次。第二件事是素材命名别用中文和特殊字符。哈希命名的素材本身没问题但如果你在打包过程中手动替换过素材、或者用了某些转换工具中间产物可能会带上原始文件名。带中文、带空格、带括号的文件名在经过压缩、解压、路径拼接之后很容易出问题尤其是路径里有空格时某些命令行工具会把路径截断。我的习惯是全部改成英文小写加下划线虽然麻烦但省下的是后面几小时的排查时间。第三件事是音频格式要转。这是体积账里最大的一笔。原始录音往往是 WAV我算一下你就明白差距有多大WAV 未压缩44100 Hz × 2 字节/采样 × 2 声道 × 60 秒 10.58 MB / 分钟 MP3 128kbps128 kbps ÷ 8 16 KB/s × 60 秒 ≈ 0.96 MB / 分钟 压缩比 ≈ 11 : 1一个作品里塞三段各一分钟的背景音乐WAV 就是 32MB转成 MP3 只剩 3MB。如果作品本身才 2MB你等于把 90% 的体积花在了音频上而打包出来的 exe 又要在此基础上再加几十兆的运行时用户下载体验会非常糟糕。转格式的时候注意采样率别降太狠22050 Hz 对于大部分音效够用背景音乐保留 44100 Hz比特率 96~128kbps 是性价比区间。提醒转格式要在打包之前做。有些打包工具会帮你做一次音频转码但转码是批量的、参数固定的效果不一定符合你的预期而且出问题了你无从判断是转码环节还是打包环节。2.2 环境依赖清单别在开发机上测完就发打包出来的 exe 要在干净的机器上跑这句话我要重复三遍。你在自己电脑上测通过只能证明你的电脑能跑因为你的电脑上装了运行时、装了各种系统组件、装了字体库。真正的验证环境是一台刚装完系统、什么都没装的虚拟机。需要确认的依赖项我列一下系统架构32 位还是 64 位。现在大部分机器是 64 位但如果目标用户里还有老设备要么打 32 位包64 位系统也能跑要么打两个包。注意 32 位包在某些新系统上会有兼容提示。运行库某些壳依赖特定的系统运行库缺了会报无法启动此程序因为计算机中丢失 xxx.dll。用安装包形式分发可以自动带上用绿色版就得到目标机上补。显卡与渲染如果你的作品用了大量图形特效个别老显卡在硬件加速下会花屏或黑屏。解决办法是打包时关闭硬件加速走软件渲染代价是帧率下降。显示缩放现在很多笔记本默认 125% 或 150% 缩放如果壳没有正确处理 DPI窗口里的画面会糊成一片。这个必须在 125% 缩放的机器上实际看一眼光看代码判断不出来。我的做法是准备一个检查清单每次打包完按顺序过一遍干净虚拟机启动、125% 缩放启动、断网启动、最小窗口拖动、全屏切换、连续运行十分钟看内存。六项全过才算可以发。2.3 体积预算先算清楚再加功能打包之前先做个预算能避免最后发现太大又回头砍素材的返工。我给一个我常用的估算模型总体积 壳运行时基线 工程素材 额外资源 安全余量 壳运行时基线 Electron 打包后asar 压缩 ≈ 55 ~ 90 MB NW.js 打包后 ≈ 70 ~ 110 MB 纯 HTML 化不自带壳 ≈ 0.5 ~ 2 MB 工程素材 图片 音频 其他文件 图片按 PNG 实际大小累加SVG 通常只有几 KB 音频按转码后的 MP3 大小累加 安全余量取 10%举个例子一个中等复杂度的作品造型 40 个SVG 为主约 300KB音频 3 段共 3 分钟转 MP3 后约 3MB工程逻辑本身 JSON 约 200KB。那么纯 HTML 化产物约 3.5MB套 Electron 壳后约 60~95MB。看到这个数字你就明白壳的体积是主导项素材优化的收益在套壳路线里被稀释了。所以如果你走 exe 路线素材优化主要是为了加载速度和内存占用而不是为了最终体积如果你走 HTML 路线素材优化就直接决定体积。再补一个启动时间的经验值Electron 壳冷启动到画面出现普通办公本上大约 1.5~3 秒机械硬盘的老机器可能到 5 秒。这个空窗期用户会以为程序没反应所以要加一个启动画面哪怕就是一张静态图把这段时间盖住体验差别非常大。3. 实操把一个 sb3 工程打成可分发 exe铺垫完了进入正题。我把流程分成网页化和套壳两个阶段因为绝大多数打包方案的底层都是这个顺序先把 sb3 变成能在浏览器里跑的网页产物再用桌面壳把它包起来。理解了这个分层你在任何一个环节出问题都能定位到是哪一层。3.1 第一阶段把 sb3 转成可独立运行的网页产物这一步的核心诉求是产出一个index.html双击打开就能玩不依赖任何在线服务所有素材走相对路径。我推荐的操作顺序是这样的。先建一个干净的工作目录比如D:\build\myproject把 sb3 复制进去路径里不要有中文和空格——这一点我在第 2 章强调过但在这里尤其重要因为后面很多命令行操作都在这个目录里跑。然后选择转换方式。如果你只是要个能跑的结果用社区里的在线打包服务最省事上传 sb3勾选包含所有素材不使用在线资源生成单文件点转换等几十秒下载一个压缩包。解压后你会看到类似这样的结构dist/ ├── index.html # 入口页面 ├── js/ │ ├── runtime.js # 运行时把积木翻译成 JS 的核心 │ └── ... ├── assets/ # 素材通常是哈希命名 │ ├── b3a7f2c1.svg │ └── 4f2a8c9e.wav └── project.json # 或者被内联进 js第一次转换完别急着往下走先做三件事验证。第一直接双击 index.html看能不能正常跑角色在不在、声音响不响。第二按 F12 打开控制台看 Network 面板里有没有红色的 404。有 404 就说明素材映射出问题了必须在这一步修掉不能带进壳里。第三断网再跑一次确认没有任何在线依赖。如果 404 集中在某些素材上多半是project.json里记录的assetId和实际文件名对不上。处理办法是把 sb3 解压比对project.json里的素材列表和文件夹里的实际文件缺哪个就从原工程重新导入一次再打包。这类问题在工程被多次另存、素材被反复替换的作品里特别常见。如果你需要更细的控制比如自定义加载页、禁用某些功能、注入一段自己的脚本那就得用命令行方式的转换工具自己跑构建。以 Node 环境为例大致流程是# 建工作目录并进入 mkdir myproject cd myproject # 初始化安装转换工具具体包名以你选用的工具文档为准 npm init -y npm install packager-package --save-dev # 执行转换输入 sb3输出到 dist npx packager-cli ./project.sb3 --out ./dist --no-cloud --inline-assets # 起个本地服务看看效果不要用 file:// 直接开 npx serve ./dist--no-cloud这类参数的意思是剥离所有在线能力--inline-assets是把素材内联进 js换来的是单文件、零依赖代价是首次加载要解析一个大 js冷启动会慢一点。这两个参数怎么取舍取决于你的分发方式发给别人用单文件更省心自己部署到网页上分离资源更利于缓存。3.2 第二阶段用桌面壳把网页产物包成 exe网页产物能跑了套壳就是个体力活。我用 Electron 举例因为它生态最成熟、文档最全、遇到问题最好搜。先建壳工程目录结构和网页产物分开myproject/ ├── shell/ # 壳工程 │ ├── main.js # 主进程 │ ├── package.json │ └── build/ │ └── icon.ico # 图标必须是 .ico多尺寸内嵌 └── dist/ # 上一阶段产出的网页产物 ├── index.html └── ...main.js里要做的事情其实就几行但每一行都有讲究const { app, BrowserWindow, Menu } require(electron); const path require(path); function createWindow() { const win new BrowserWindow({ width: 960, height: 720, resizable: false, // 作品是固定画布禁止拉伸避免变形 fullscreenable: true, autoHideMenuBar: true, // 隐藏菜单栏 backgroundColor: #000000, // 先铺黑底避免白屏闪烁 webPreferences: { contextIsolation: true, // 安全默认值别关 nodeIntegration: false, // 页面里不需要 Node 能力 backgroundThrottling: false // 失焦时别降帧否则切回来会卡一下 }, icon: path.join(__dirname, build, icon.ico) }); Menu.setApplicationMenu(null); // 彻底去掉菜单 win.loadFile(path.join(__dirname, .., dist, index.html)); } app.whenReady().then(createWindow); app.on(window-all-closed, () app.quit());几个参数我要单独解释因为它们直接决定体验resizable: false是因为图形化作品的舞台是固定逻辑分辨率常见 480×360 或 640×360窗口可拉伸会导致画面被非等比拉伸圆变成椭圆字变胖。如果你确实想支持大屏正确做法是在页面里做等比缩放而不是放开窗口拉伸。backgroundColor: #000000是为了解决白屏闪烁。默认背景是白的页面加载完成前会闪一下白黑底或者和作品主色调一致的底色能让这个过渡自然很多。backgroundThrottling: false这个参数很多人不知道。默认情况下窗口失焦后渲染会被降频用户切出去再切回来动画会卡顿一下甚至跳帧。如果你的作品有音乐或动画这个必须关掉。Menu.setApplicationMenu(null)去掉默认菜单后像 CtrlR 刷新、F11 全屏这些快捷键也没了。如果你希望保留全屏切换得自己注册快捷键或者在页面里加一个按钮。壳跑通之后就是打包成 exe。用构建工具生成安装包或绿色版cd shell npm install --save-dev electron-builder # 生成免安装的绿色版单文件 exe npx electron-builder --win portable # 生成带安装向导的安装包 npx electron-builder --win nsisportable模式产出的是一个自解压的单文件 exe用户双击后它会先解压到临时目录再启动所以启动会比安装版慢一点这是正常的。nsis模式产出的是安装程序装完启动快但用户得多点几步。我的经验是比赛提交、展台展示用 portable日常分发给不熟悉电脑的人用 nsis。3.3 图标、版本信息与那些看起来像正经软件的细节一个 exe 给别人的第一印象八成来自图标和属性面板。这两件事做不做专业度差得很远。图标必须是.ico格式而且要内嵌多个尺寸16×16、32×32、48×48、256×256。只放一个 256 的任务栏和资源管理器里会显示成模糊的一团。制作方法不用装专业软件用任意图片工具把一张 1024×1024 的 PNG 导出成多尺寸 ico 就行注意背景要透明。版本信息在package.json里配置构建时会写进 exe 的属性面板{ name: my-project, version: 1.0.0, description: 一个用积木编程做的互动小作品, author: 某创作者, build: { appId: com.example.myproject, productName: 我的作品, win: { icon: build/icon.ico, target: [portable] }, portable: { artifactName: 我的作品_v${version}.exe } } }productName决定窗口标题和安装后的文件夹名artifactName决定产物文件名。我习惯在文件名里带上版本号这样用户手里同时有几份的时候一眼能看出哪个是新版省掉大量我下载的是不是最新的这类沟通。3.4 体积与启动速度的最后调优前面算过壳的体积是大头。有几个办法能压一压第一用 asar 打包并把资源都放进去。asar 是一种归档格式把成千上万个小文件合成一个大文件减少文件系统开销也避免用户误删素材。构建工具默认会开确认一下就行。第二剔除用不到的本地化语言包。Electron 自带几十种语言资源每个几百 KB加起来能有十几兆。如果你的作品只有中文界面可以在构建配置里排除掉其他语言包体积能省 10~20MB。第三剥离 source map 和调试文件。开发阶段的.map文件、未压缩的源码在正式产物里全都不需要。第四压缩图片。SVG 做一次精简去掉编辑器留下的元数据PNG 用有损压缩工具过一遍通常能再省 20%~40%。这一步在套壳路线里收益不大但能明显加快页面加载。启动速度方面最有效的办法是先显示窗口再加载内容。Electron 创建窗口是瞬间的慢的是页面加载和运行时初始化。所以先把窗口 create 出来用一个本地的简单 HTML 当启动页一张 logo 图 一行正在加载等主页面did-finish-load之后再切换过去。用户在 1~3 秒里看到的是启动页而不是白屏或黑屏主观感受完全不同。4. 常见问题与排查实录这一章是我这些年攒下来的问题库按出现频率排序。每个问题我都写了现象—原因—处理你可以当速查表用。4.1 白屏、闪退、命令行黑框白屏且窗口正常出现是最常见的。八成是loadFile的路径不对或者页面里的资源路径用了绝对路径。排查步骤在main.js里把win.loadFile(...)换成win.loadURL(...)加载一个在线页面如果在线页面能显示说明壳没问题是本地路径错了如果在线也白屏那是壳的渲染出问题了大概率是显卡兼容。双击闪退、什么提示都没有这种最难查因为你看不到报错。处理办法是在命令行里启动 exe你的作品.exe --enable-logging或者在main.js里加一段全局异常捕获把错误写进本地日志文件process.on(uncaughtException, (err) { require(fs).appendFileSync( require(path).join(require(os).tmpdir(), app-error.log), new Date().toISOString() err.stack \n ); });日志会写到系统临时目录跑一次之后去翻基本都能定位。启动时闪一个黑色命令行窗口这个在 Windows 上很常见。解决方法是构建时把目标设为 GUI 子系统而不是控制台子系统构建工具一般有--win --console的反向选项默认不开就没问题。如果你是自己手搓启动脚本注意别用.bat去拉起 exe那必定带黑框。页面能显示但画面花屏、撕裂优先怀疑硬件加速。在main.js里加app.disableHardwareAcceleration()试试如果好了就说明是显卡驱动的问题。代价是渲染走 CPU复杂特效会掉帧但对 2D 积木作品来说通常够用。4.2 素材丢失、声音不响、音频不同步角色造型变成空白方块说明素材加载失败。按 F12 看 Network 里的 404 路径如果路径里出现了file:///C:/Users/...这种绝对路径说明转换阶段没把路径改成相对路径回去重新转换。如果路径是相对的但仍然 404那就是文件名映射错了解压 sb3 比对project.json的素材列表。声音完全没反应先排除浏览器自动播放限制。现代浏览器内核要求用户有交互之后才允许播放音频程序一启动就自动播放会被静默拦截。解决办法很简单页面加载完先显示一个点击开始的遮罩用户点一下再进入这一下点击就解锁了音频权限。这个遮罩还能顺便解决启动页的问题一举两得。音频和画面不同步、越跑越偏这是性能问题。可能是音频解码占用了主线程也可能是帧率不稳定。处理方向把音频从高采样率 WAV 转成 MP3 减少解码压力检查有没有backgroundThrottling被打开如果作品里有大量同时播放的音效考虑合并成一条音轨。导出后中文变成方块或问号字体问题。壳里用的是系统字体如果你的作品用了某个特殊字体而目标机没装就会替换成默认字体。解决办法是把字体文件一起打包在页面里用font-face引用。注意字体授权商用要谨慎。4.3 杀软误报、数字签名与分发阻力未签名的 exe 被安全软件拦截几乎是必然的尤其是自解压的 portable 版本。表现是下载后被直接删掉或者双击提示此应用已被阻止。处理这件事有几个层次。最轻的做法是换 nsis 安装包形式安装包被误报的概率低于自解压单文件。进一步是给 exe 做数字签名签名证书需要成本个人项目不一定划算但如果是要正式分发的作品这笔钱花得值用户看到已验证的发布者信任度完全不一样。再进一步是主动提交白名单主流安全厂商都有误报申诉入口提交你的产物让他们加白通常几天内有结果。还有个土办法但很有效在分发时附一段说明告诉用户如果提示风险点更多信息→仍要运行。别小看这句话它能挡掉一半的售后咨询。注意不要在文件名或说明里用破解绿色版免安装无毒这类词反而会提高被拦概率。老老实实写作品名和版本号。4.4 问题速查表现象最可能原因快速验证处理双击无反应缺少运行库 / 被杀软拦截命令行启动看报错补运行库 / 换安装包形式窗口出来但白屏资源路径错 / 渲染失败换在线页面测试改相对路径 / 关硬件加速角色空白素材 404F12 看 Network重新转换 / 修映射声音不响自动播放被拦手动点一下页面再测加点击开始遮罩画面拉伸变形窗口可缩放拖动窗口边缘设resizable: false高分屏下模糊DPI 未适配125% 缩放下看开 DPI 感知 / 调缩放切出去再回来卡顿后台降频切窗再切回关backgroundThrottling中文显示成方块缺字体换台机器测打包字体文件产物 100MB壳基线 未压缩素材看目录构成剔语言包 / 转音频格式启动要等五六秒冷启动 大资源计时加启动页遮罩5. 分发与维护别让 exe 变成一次性产物打包出来只是开始真正的麻烦在后面用户拿到手怎么用、你改了作品怎么更新、多个作品怎么管理。这些问题不提前想做到第三个作品的时候就会乱成一团。5.1 版本管理与产物命名我给自己定了一套命名规则用了好几年没出过乱子作品名_v主版本.次版本.exe。主版本号用在玩法变了的时候次版本号用在修 bug、换素材的时候。产物旁边永远配一个更新说明.txt写清楚这版改了什么、修了哪个问题。用户手里的旧版不用删新版文件名不同不会覆盖也不会搞混。工程本身也要管起来。我的习惯是每个作品一个文件夹里面分src原始 sb3、build转换中间产物、dist最终 exe、docs截图和说明。每次定稿就把整个文件夹压一份存档标上日期。听起来笨但等你三个月后想改一个细节、却发现原始工程已经被覆盖了的时候就知道这个习惯有多值。5.2 更新策略小步快跑还是憋大招exe 分发的最大痛点是更新成本——你改了一行用户就得重新下载 80MB。所以我现在的做法是分两条线并行一条是 exe 线只在定稿时打一次用于比赛、送礼、展台另一条是网页线每次改动都更新链接固定不变发给平时玩的人。这样既保证了正式场合的稳定性又保证了日常迭代的效率。如果确实需要频繁更新 exe可以考虑壳与内容分离的结构exe 只做启动器真正的作品内容放在同目录的一个子文件夹或者一个数据文件里。更新时只替换那个文件体积能压到几兆。这个结构稍微复杂一点但对长期维护的项目很值得。最后说一个我踩过的最大的坑跟技术无关永远留一份能跑通的完整产物存档。我有一次清理硬盘把某个作品的node_modules和构建缓存删了想着随时能重装。结果半年后要重新打包发现当初用的工具版本已经升级接口变了重新装出来的环境跑不通原来的工程折腾了一整天才找回来。从那以后我每个定稿的产物都留一份完整目录不依赖任何外部环境插上硬盘就能复现。这件事没有任何技术含量但它救过我两次。
阅读完成 · 觉得有帮助？
` 这一行漏掉了一个临时变量)
