簡介這是一套面向Electron桌面應(yīng)用開發(fā)者的打包依賴環(huán)境全家桶專門解決新下載的Electron項目在構(gòu)建安裝包時因依賴不完整而頻繁報錯的問題。壓縮包內(nèi)集齊三件核心組件electron-v8.5.5-win32-x64提供應(yīng)用主程序運行環(huán)境nsis-3.0.4.2負責生成Windows安裝引導程序winCodeSign-2.6.0則用于代碼簽名與證書校驗三者均為Windows下的兼容版本可整體解壓后復制到C:\Users\用戶名\AppData\Local\electron\Cache目錄下直接調(diào)用無需手動逐一下載匹配版本。資源整體為7z壓縮格式體積約356.44MB內(nèi)含三個組件對應(yīng)的完整文件集合解壓后即可按目錄結(jié)構(gòu)使用。對于剛接觸Electron打包的初級開發(fā)者或需要快速搭建打包環(huán)境的工程師這套文件能顯著降低環(huán)境配置難度避免因缺失簽名工具或NSIS模板導致的反復失敗。目前已有1548人學習下載適合作為本地打包環(huán)境的備件庫。1. 周五下午你卡在三個綠色文件夾上Electron 打包全家桶到底在裝什么周五下午急著發(fā)一版 exe 出去electron-builder 在日志里安靜地寫“Downloading electron-v8.5.5-win32-x64.zip”進度條繞了十分鐘你才在緩存目錄里看到三個帶版本號的文件夾electron-v8.5.5-win32-x64、nsis-3.0.4.2、winCodeSign-2.6.0打包才真正跑起來。這就是常說的 Electron 打包全家桶Electron 本體負責運行時NSIS 負責把應(yīng)用卷成安裝程序winCodeSign 藏著一組改圖標、寫版本號、打數(shù)字簽名的工具。很多用 electron 技術(shù)棧的人都被這三個包折磨過——不知道它們從哪來、缺了會怎樣、版本為什么不能亂動。這篇就拆開講清楚版本關(guān)系、最小配置和實際踩過的坑適合正在用 electron-builder 在 Windows 上出安裝包、被體積和簽名問題反復折騰的開發(fā)者。2. 版本對應(yīng)關(guān)系與離線依賴先把鏡像、緩存和三個包的依賴鏈捋順2.1 為什么是這幾個版本electron-builder 的版本鎖定邏輯把這三個版本號當成“黑匣子”是最常見的狀態(tài)。它們其實不是你自己指定的而是 electron-builder 在打包時按內(nèi)部鎖定的版本去下載的electron-v8.5.5-win32-x64 對應(yīng)你項目里裝的 Electron 運行時nsis-3.0.4.2 是 electron-builder 定制的 NSIS 引擎winCodeSign-2.6.0 則是一套 Windows 簽名工具集。我一般會先查清一件事electron-builder 的版本和 NSIS、winCodeSign 資源包是一一對應(yīng)死的升級 electron-builder 可能導致緩存里多出多個不同版本的 nsis 和 winCodeSign新舊混用時會出一些非常奇怪的“玄學報錯”。這個鎖定邏輯帶來的直接結(jié)果就是誰先裝誰后裝并不重要打包時 electron-builder 會去遠程倉庫拉一個“帶版本號前綴的壓縮包”解壓后放進緩存目錄等待調(diào)用。如果你團隊的構(gòu)建機上已經(jīng)有人跑過一次打包第二次打包根本不需要重新下載。但換一臺新電腦或者升級了 electron-builder 版本這部分下載時間就會原封不動地還給你。為了不讓團隊成員各自去等一次網(wǎng)絡(luò)下載我在團隊內(nèi)部約定緩存目錄作為構(gòu)建產(chǎn)物的一部分進行備份新機器先恢復緩存再打包。以下是 Windows 上 electron-builder 的默認緩存路徑不同系統(tǒng)不一樣平臺緩存目錄Windows%LOCALAPPDATA%\electron-builder\CachemacOS~/Library/Caches/electron-builderLinux~/.cache/electron-builder緩存目錄里會按依賴名分文件夾electron 壓縮包放在 electron 目錄nsis 工具放在 nsis 目錄winCodeSign 放在 winCodeSign 目錄。你在打包日志里看到 “Downloading” 字樣就是在補齊緩存看到 “Packaging” 字樣說明依賴已經(jīng)齊了。判斷標準就這么簡單。2.2 三個包在打包中分別扮演什么角色Electron 本體壓縮包解決的是“運行時”問題。它內(nèi)置了 Chromium 和 Node.js你的 JavaScript 代碼在打包后會被塞進一個 asar 歸檔由這個本體加載執(zhí)行。之所以單獨強調(diào) win32-x64是因為 electron-builder 對平臺架構(gòu)比較敏感——同一臺機器如果要同時出 32 位和 64 位安裝包會分別下載兩個不同架構(gòu)的 Electron 壓縮包體積直接翻倍。NSIS 3.0.4.2 是安裝程序引擎。electron-builder 沒有自己重新發(fā)明安裝包格式而是基于 NSIS 做了一個定制版它把應(yīng)用文件壓成一個 7z 歸檔再把 NSIS 的 stub 和這個歸檔拼起來生成你看到的 Setup.exe。整個安裝過程就是 NSIS 在解壓、寫注冊表、創(chuàng)建快捷方式、注冊卸載項。所以 NSIS 的版本直接影響安裝包的界面行為比如是否允許選安裝路徑、是否顯示安裝進度條、是否需要管理員權(quán)限。winCodeSign-2.6.0 里面是一組可執(zhí)行工具最常見的是 signtool.exe 和 rcedit.exe。rcedit 負責改 exe 的圖標、版本號、文件描述等資源段signtool 負責給 exe 打 Authenticode 簽名。你配置了 certificateFile 和證書密碼時winCodeSign 就會被調(diào)用沒配置證書時它也負責把默認圖標和版本信息寫進 exe。很多人以為代碼簽名是“證書的事”其實簽名動作本身完全依賴這個工具包。2.3 加速依賴下載的兩種做法以及緩存目錄的離線用途網(wǎng)絡(luò)環(huán)境直接影響打包體驗尤其是 Electron 壓縮包動不動就上百 MB。我常用的做法是設(shè)置鏡像源環(huán)境變量set ELECTRON_MIRRORhttps://npmmirror.com/mirrors/electron/ set ELECTRON_BUILDER_BINARIES_MIRRORhttps://npmmirror.com/mirrors/electron-builder-binaries/第一行讓 electron 本體從國內(nèi)鏡像下載第二行讓 nsis、winCodeSign 從 electron-builder-binaries 鏡像下載。兩個變量是獨立的只配其中一個的話另一個仍然走官方源所以建議同時設(shè)置。鏡像源的選擇不用太糾結(jié)只要確認路徑能直接拼出“electron-v8.5.5-win32-x64.zip”和“nsis-3.0.4.2.7z”這樣的文件結(jié)構(gòu)就行。離線構(gòu)建則是另一個思路在能正常打包的機器上把 %LOCALAPPDATA%\electron-builder\Cache 整個目錄拷貝到新機器對應(yīng)位置再打包時會直接命中緩存日志里完全看不見 Downloading 字樣。我?guī)屯绿幚磉^多次“打包卡在下載”的問題最后幾乎都是歸還緩存放行的。注意一點緩存目錄的歸屬是當前用戶級的如果 CI 或新機器用了不同賬號路徑要相應(yīng)調(diào)整。3. 最小打包配置跑通用 electron-builder 在 Windows 上產(chǎn)出第一個 exe3.1 初始化工程并安裝核心依賴electron 版本怎么鎖先從一個干凈的目錄開始。這里假設(shè)項目名就叫 electron-pack-demoNode.js 版本不低于 14因為 electron-builder 對老版本 Node 支持有限。初始化并安裝依賴mkdir electron-pack-demo cd electron-pack-demo npm init -y npm install --save-dev electron8.5.5 electron-builder把 electron 固定在 8.5.5 是因為團隊項目的運行時版本要和緩存的 electron-v8.5.5-win32-x64 對齊。electron-builder 會自動探測當前項目里 electron 的版本然后拼出下載文件名所以如果你裝的是 electron 9.x緩存里就會出現(xiàn)另一個版本號的壓縮包。同一個項目里不要混用否則每次打包可能都在下載新東西。安裝完成后package.json 里至少要有 main 字段指向應(yīng)用的入口文件。最簡單的方式是新建一個 main.jsconst { app, BrowserWindow } require(electron); app.whenReady().then(() { const win new BrowserWindow({ width: 1024, height: 768, webPreferences: { contextIsolation: true } }); win.loadFile(index.html); });這段代碼的邏輯是等 Electron 應(yīng)用就緒后創(chuàng)建一個 1024x768 的主窗口并加載本地 index.html。窗口參數(shù)里的 contextIsolation 保持默認開啟避免后續(xù)升級 Electron 時出現(xiàn)渲染進程沙箱警告。index.html 里隨便寫一個標題打包時它會被一起收進 asar。3.2 electron-builder 的配置項解析win、nsis、files 三段配置electron-builder 有兩種配置方式寫在 package.json 的 build 字段里或者單獨建 electron-builder.yml。我習慣用 package.json因為少一個文件而且讀取優(yōu)先級不容易搞混。下面是一個最小可用的配置文件{ name: electron-pack-demo, version: 1.0.0, description: electron packaging demo, main: main.js, scripts: { pack: electron-builder --win }, build: { appId: com.example.electronpackdemo, productName: ElectronPackDemo, files: [ main.js, index.html, package.json ], win: { target: [ { target: nsis, arch: [x64] } ], icon: build/icon.ico }, nsis: { oneClick: false, allowToChangeInstallationDirectory: true, createDesktopShortcut: true, shortcutName: ElectronPackDemo } } }配置分為三層files 決定哪些文件進 asarwin 決定目標平臺和架構(gòu)nsis 決定安裝包行為。files 里只列入口文件和頁面資源node_modules 不需要手寫electron-builder 會自動分析 main.js 里 require 的模塊并打包進去。win 里把 target 精確到 nsinstal 和 x64出包結(jié)果就只會有 64 位的 NSIS 安裝包。icon 字段的路徑是相對項目根目錄的要求是 .ico 格式至少包含 256x256 尺寸。如果沒有準備圖標第一次跑通可以暫時刪掉這一行electron-builder 會用默認 Electron 圖標但后續(xù)發(fā)布前必須換掉否則產(chǎn)品名旁邊永遠是個外星人頭像。3.3 第一次打包與產(chǎn)物目錄驗證在項目根目錄執(zhí)行打包命令npm run pack由于剛才配置了國內(nèi)鏡像源這一步不會等待太久但第一次仍會下載 nsis-3.0.4.2 和 winCodeSign-2.6.0。日志里依次出現(xiàn) “downloading”、“extracting” 和 “building” 三個階段。構(gòu)建完成后項目根目錄會出現(xiàn)一個 dist 文件夾里面有兩個文件尾綴帶 “Setup” 的是安裝程序尾綴帶 “Blockmap” 的是增量更新映射文件。我建議拿到產(chǎn)物后先手動安裝一遍而不是直接丟給測試。安裝過程中重點觀察剛才配置的 allowToChangeInstallationDirectory 是否生效——如果你看到安裝界面底部沒有“選擇目錄”按鈕說明 nsis 配置沒被正確讀取。常見原因是 package.json 里 build 字段寫在了 scripts 之前位置不影響解析但有些編輯器會把 JSON 格式校驗標紅導致你以為配置無效實際問題出在引號或逗號上。跑完第一次打包后去看緩存目錄如果 nsis 和 winCodeSign 文件夾已經(jīng)躺在那了說明全家桶下載完畢下次打包可以直接斷網(wǎng)測試。4. NSIS 安裝包定制卸載邏輯、安裝路徑與權(quán)限的坑4.1 nsis-3.0.4.2 在 electron-builder 里怎么被調(diào)用上一章我們完成了最小打包這一章開始定制 NSIS 安裝行為。先明確一件事NSIS 不是 electron-builder 寫的腳本語言而是一整套安裝程序制作框架。electron-builder 做的是把 NSIS 的 makensis 編譯器、預置安裝腳本模板和你配置的 nsis 參數(shù)拼在一起生成一個帶 UI 的 Setup.exe。你平時看到的“下一步”“安裝”“完成”按鈕全部來自 NSIS 的現(xiàn)代 UI 組件。nsis-3.0.4.2 這個版本號其實很少有人單獨下載它因為 electron-builder 會在打包時自動去 electron-builder-binaries 鏡像拉取一個壓縮包解壓后臨時調(diào)用。它內(nèi)部包含兩個關(guān)鍵文件makensis.exe 是編譯器Stubs/ 目錄里是各種安裝程序外殼。你在配置里寫 oneClick、allowToChangeInstallationDirectory最后都會被翻譯成傳給 makensis 的指令參數(shù)。我在定制安裝包時堅持一個原則優(yōu)先改 electron-builder 的 nsis 配置項不要輕易改 NSIS 腳本模板。因為 electron-builder 每次升級都可能更換模板文件你手改的腳本在下次升級后會失效或被覆蓋。除非是改安裝界面的啟動畫面圖片或修改安裝完成后是否自動運行這種偏門需求否則配置項足夠用。4.2 定制安裝程序安裝路徑、桌面圖標與卸載行為最常用的定制需求有三個安裝目錄可手選、桌面快捷方式開關(guān)、卸載時是否清除用戶數(shù)據(jù)。下面是一組我在實際項目里會用到的配置nsis: { oneClick: false, perMachine: false, allowElevation: true, allowToChangeInstallationDirectory: true, installerIcon: build/installer.ico, uninstallerIcon: build/uninstaller.ico, installerHeaderIcon: build/header.ico, createDesktopShortcut: true, createStartMenuShortcut: true, shortcutName: ElectronPackDemo, deleteAppDataOnUninstall: false, runAfterFinish: true }逐個說明oneClick 改為 false 會啟用“輔助安裝向?qū)А蹦Ｊ桨惭b器先展示歡迎頁和目錄選擇頁而不是一鍵裝完。perMachine 設(shè)為 false 表示按用戶級安裝不需要管理員權(quán)限裝到當前用戶的 AppData 目錄如果設(shè)為 true安裝包會請求管理員權(quán)限并安裝到 Program Files。allowElevation 控制的是安裝器是否允許動態(tài)請求 UAC 提權(quán)。perMachine 為 false 時這個選項一般跟著 false 走避免安裝器一半權(quán)限一半沒權(quán)限的割裂狀態(tài)。deleteAppDataOnUninstall 是很多人會忽略的坑如果設(shè)為 true用戶在卸載時會連本地數(shù)據(jù)庫和登錄狀態(tài)一起刪掉對于工具類應(yīng)用我建議設(shè)為 false讓用戶數(shù)據(jù)保留至少在卸載時給一個提示選項。runAfterFinish 控制安裝完成后是否立即啟動應(yīng)用這個看產(chǎn)品習慣不設(shè)默認是 true。安裝路徑的選擇邏輯也值得注意當 perMachine 為 false 時electron-builder 會把默認安裝路徑設(shè)置到當前用戶的 AppData\Local\ProgramsproductName 目錄下。這種做法的好處是即使用戶不是管理員也能安裝壞處是某些安全類軟件會對用戶目錄下自啟動的可執(zhí)行文件特別敏感。我自己做過對比同樣是未簽名安裝包裝到 Program Files 的觸發(fā)攔截概率比裝到用戶目錄低一些這是實測體會不一定算規(guī)則。4.3 安裝包體積優(yōu)化與安裝速度的權(quán)衡安裝包體積是逃不過的話題。electron-v8.5.5-win32-x64 壓縮包解壓后接近 200MBNSIS 引擎會把整個應(yīng)用目錄壓成一個 7z 歸檔。壓縮級別越高Setup.exe 越小但安裝時解壓越慢。electron-builder 提供了一組壓縮參數(shù)nsis: { compression: lzma, differentialPackage: true, unpackDirName: app-unpacked }compression 支持 zip、lzma、bzip2 三種。默認是 lzma壓縮率最高但打包時間也最長。如果你的應(yīng)用里有很多二進制資源比如原生模塊或 ffmpeg 庫zlib 會更穩(wěn)因為 lzma 在個別殺毒軟件的實時掃描下有可能被誤判。differentialPackage 設(shè)為 true 會生成一個體積很小的增量補丁包方便后續(xù)版本升級時只下載差異部分。除了壓縮算法體積優(yōu)化要靠排除文件。files 配置里有一個規(guī)律我覺得值得記住被 asar 收錄的文件越多安裝包越接近全量復制而 electron-builder 默認會把 app-builder 依賴、測試腳本、.md 文檔都打進去。我通常會在 files 里明確排除不必要的內(nèi)容files: [ main.js, index.html, package.json, !assets/screenshots/**, !test/**, !**/*.map ]map 文件對線上應(yīng)用沒有任何用處卻會讓體積多出幾十 MB這一條建議直接加。screenshots 這類靜態(tài)資源如果不被運行時讀取也建議排除。每做一次排除操作對比一下 dist 目錄下 Setup.exe 的體積變化慢慢就能對“哪些文件值得進安裝包”形成肌肉記憶。5. winCodeSign-2.6.0 代碼簽名避坑為什么簽完名還是被攔截5.1 簽名在打包流程里的位置與必要性winCodeSign 在整個打包流程里承擔兩件事改 exe 資源和打 Authenticode 簽名。它的位置在 NSIS 制作安裝包之前——electron-builder 先調(diào)用 rcedit 修改應(yīng)用的 exe 圖標和版本信息接著調(diào)用 signtool 給 exe 簽名最后才把簽名后的 exe 傳給 NSIS 封裝成安裝程序。所以如果你在打包日志里看到 winCodeSign 目錄被讀取但隨后出現(xiàn) “skipped signing”說明簽名步驟被跳過了。簽名不是可有可無的東西。Windows 10 以上系統(tǒng)對來自網(wǎng)絡(luò)的可執(zhí)行文件有“Mark of the Web”檢測未簽名或簽名無法驗證的 exe 會觸發(fā) SmartScreen 的藍色警告框上面寫著“Windows 已保護你的電腦”。真實的產(chǎn)品分發(fā)走這條路是必選項不是加分項。我有一次給內(nèi)部工具打包懶得配證書結(jié)果同事安裝時 Windows Defender 直接提示風險最后還不是得回去補簽名配置重打。winCodeSign-2.6.0 里包含的工具可以獨立于 electron-builder 使用。遇到簽名問題需要排查時我會直接去看緩存目錄里的 winCodeSign 文件夾找到 signtool.exe 手動執(zhí)行驗證命令比反復打包試錯快得多。5.2 自簽名證書練手但別指望它過 SmartScreen正式的代碼簽名證書需要去 CA 機構(gòu)購買一年花費不小。在正式證書到手之前可以用自簽名證書先把簽名鏈路完整跑通。Windows 上生成自簽名證書用 PowerShell 一條命令New-SelfSignedCertificate -Type CodeSigningCert -Subject CNElectronPackDemo Test -CertStoreLocation Cert:\CurrentUser\My -NotAfter (Get-Date).AddYears(1)執(zhí)行后會生成一張有效期為 1 年的代碼簽名證書并自動導入當前用戶的證書庫。要把它導出成 electron-builder 能讀的 pfx 格式需要再用兩條命令$cert Get-ChildItem Cert:\CurrentUser\My | Where-Object { $_.Subject -like *ElectronPackDemo* } $password ConvertTo-SecureString your-password -AsPlainText -Force Export-PfxCertificate -Cert $cert -FilePath build/cert.pfx -Password $password然后在 build.win 配置里引用win: { certificateFile: build/cert.pfx, certificatePassword: your-password }自簽名證書能讓打包日志里出現(xiàn) “signed with sha256” 字樣安裝的時候也能看到發(fā)布者名字但用戶機器的證書信任鏈里沒有你的自簽名根證書SmartScreen 照樣彈警告。這條鏈路最大的價值在于驗證 electron-builder 讀證書、算哈希、打簽名的流程沒毛病正式證書拿到手后替換 pfx 文件就行。5.3 三個坑證書找不到、時間戳失敗、雙簽名缺失坑 1打包日志顯示 “skipped signing”安裝包發(fā)布者為“未知”?，F(xiàn)象打包流程正常結(jié)束產(chǎn)物也能跑但右鍵查看 exe 屬性數(shù)字簽名標簽頁空白或顯示“該文件的數(shù)字簽名無效”。原因certificateFile 配置沒生效。最常見的是路徑寫錯——electron-builder 解析相對路徑時基于項目根目錄如果你把 pfx 放在 build 目錄下卻寫成了 build/build/cert.pfx 就會找不到。還有個隱蔽情況electron-builder 讀取的是 win 塊下的 certificateFile不是根級配置。解決把證書路徑改成絕對路徑測試一遍確認能讀到后再改回相對路徑。如果使用的是環(huán)境變量傳入證書密碼檢查 CI 或當前 shell 里環(huán)境變量是否真的存在?？?2簽了名但 SmartScreen 仍顯示“未知發(fā)布者”?，F(xiàn)象安裝包已經(jīng)帶簽名屬性里能看到發(fā)布者名字但彈窗還是全藍色警告。原因簽名有效不代表信任鏈建立。SmartScreen 看的是“證書是否來自受信任的根證書頒發(fā)機構(gòu)”以及“證書印章是否被足夠多的用戶接受過”。自簽名證書和剛買的 OV 證書都會遇到這個問題OV 證書的情況是部分用戶點擊“更多信息”可以繼續(xù)但信任建立需要時間。解決更換為 EV 代碼簽名證書它會把簽名印章做到本地可信根里SmartScreen 警告能直接消掉。如果暫時沒有 EV 證書OV 證書配合穩(wěn)定的時間戳服務(wù)器也能減少一部分攔截但不要指望 100% 消除?？?3簽名時報 “The timestamp service is not available” 或安裝包在無網(wǎng)環(huán)境安裝時簽名校驗失敗?，F(xiàn)象打包日志里出現(xiàn)時間戳服務(wù)器連接失敗或者安裝包在聯(lián)網(wǎng)環(huán)境正常、到客戶內(nèi)網(wǎng)就提示簽名損壞。原因electron-builder 簽名時會向時間戳服務(wù)器發(fā)請求把簽名時刻記錄到簽名數(shù)據(jù)里保證證書過期后簽名仍然有效?？蛻魞?nèi)網(wǎng)斷外網(wǎng)時Windows 無法驗證時間戳。解決在 win 配置里顯式指定時間戳服務(wù)器win: { certificateFile: build/cert.pfx, certificatePassword: your-password, signtoolOptions: { signAndTimestamp: true } }或者更直接的做法是手動重新簽名時加上/tr參數(shù)指定時間戳地址。實際上electron-builder 默認會對 exe 做時間戳但構(gòu)建機網(wǎng)絡(luò)不好時可能靜默跳過。我在一次離線構(gòu)建中發(fā)現(xiàn)簽名完整但時間戳缺失后來固定了時間戳服務(wù)器地址這類問題基本絕跡。以上三條是簽名環(huán)節(jié)最容易遇到的。記住一個原則簽名日志里的關(guān)鍵字是 evidence看到 “Signed” 和 “Timestamp” 兩個輸出同時出現(xiàn)才算真正完成缺一個都算翻車。6. 讓 Electron 打包成為可復用的流水線緩存復用與簽名自檢打包這件事一旦變得依賴網(wǎng)絡(luò)下載和本地緩存就天然不適合手工反復操作。我最后的習慣是給項目加一個驗證腳本打包完成后自動檢查安裝包的簽名狀態(tài)Get-AuthenticodeSignature -FilePath dist\ElectronPackDemo Setup 1.0.0.exe | Select-Object Status, StatusMessage, TimeStamperCertificate輸出里 Status 必須是 ValidTimeStamperCertificate 不能為空。如果 Status 是 UnknownError基本可以斷定是簽名或時間戳沒打上不用等測試反饋就能提前發(fā)現(xiàn)。把這個命令寫進 CI 流水線的后置步驟比默默發(fā)版再被用戶提醒要省心得多。另一個復用技巧是把緩存目錄納入備份策略。我在團隊內(nèi)部約定新入職同事的機器先同步一次 %LOCALAPPDATA%\electron-builder\Cache之后打包的時間能穩(wěn)定控制在 3 分鐘左右而不需要反復等待幾十 MB 的下載。緩存一旦就位electron-v8.5.5-win32-x64、nsis-3.0.4.2、winCodeSign-2.6.0 三個包就是本地常駐資源打包變成了真正的離線流程。做 Electron 打包時間久了最大的教訓是版本和證書這兩樣東西不能靠“感覺”。版本鎖不準緩存就開始膨脹慢則多下載幾個包快則升級后報一個看不懂的編譯錯證書管理不嚴肅密碼寫進配置里再推到共享倉庫等于把簽名鑰匙交給了所有人。我自己在這方面吃過虧——密碼從 package.json 挪到環(huán)境變量只花了我十分鐘卻把一個隱患徹底關(guān)掉了。個人開發(fā)時那種“怎么方便怎么來”的松弛感帶到打包流水線上關(guān)鍵時刻會咬人。希望這些經(jīng)驗幫到你讓你在遇到這三個綠色文件夾時心里有底。本文還有配套的精品資源點擊獲取