1. 为什么是 Carlo 而不是 Electron——从“轻量级桌面系统监控”需求倒推技术选型我第一次在某跨平台系统维护项目里被要求做一个“开机自启、常驻托盘、实时显示 CPU/内存/磁盘使用率”的小工具时本能地打开了 Electron 官网。但翻到构建体积那一栏一个空壳应用打包后动辄 120MB启动要 3 秒托盘图标加载延迟明显——当场就关掉了页面。这不是监控工具这是资源吞噬兽。后来在某实验室的内部分享会上一位前端工程师提到他们用Carlo替换了旧版 Electron 系统信息面板最终产物只有 28MB冷启动 420ms托盘响应无卡顿。我当时没太当回事直到自己接手一个部署在老旧工控机上的运维看板项目设备只有 2GB 内存、Intel Celeron J1900 处理器、SSD 剩余空间不足 500MB。Electron 直接报 OOM连主进程都起不来。这才真正去挖 Carlo 的底子。它不是另一个“桌面框架”而是一个极简的 Chrome 嵌入式通信协议桥接器。核心逻辑就三句话启动一个本地 Chrome 实例可复用已安装的 Chrome也可内嵌 portable 版用 Node.js 主进程通过 DevTools ProtocolDTP与之建立 WebSocket 连接所有 UI 渲染交由 Chrome 完成Node 只负责采集系统数据、转发指令、处理 IPC。这意味着你不用打包 Chromium不捆绑 V8 引擎不加载 Electron 的 17 层抽象层。你只是“请 Chrome 帮你画个界面”而 Node 是那个在后台跑os.cpus()、fs.statfs()、child_process.exec(wmic)的老黄牛。提示Carlo 的本质是“Chrome as Renderer Node as Backend”而非“Node as Runtime Chrome as View”。这个认知差直接决定你后续所有配置是否走偏。它和 Electron 的根本区别不在 API 写法而在进程模型与资源归属维度CarloElectron主进程角色纯数据采集 DTP 控制器渲染进程管理 窗口生命周期 IPC 中枢 模块加载器渲染进程来源外部 Chrome 实例系统级进程内置 Chromium 子进程独立沙箱打包体积基准Node 二进制 应用 JS 静态资源≈15–30MBNode 二进制 Chromium 二进制 Electron 框架层≈110–160MB内存占用空载≈45–65MB仅 Chrome 渲染页 Node 主进程≈180–240MBChromium 子进程 ×2 Electron 主进程 GPU 进程Windows 兼容性依赖系统 Chrome ≥88或手动指定 portable 路径自带 ChromiumWin7 全覆盖我实测过同一台 Win10 工控机2GB RAMCarlo 应用启动后内存占用稳定在 58MBCPU 占用 0.3%Electron 同功能应用启动即飙到 210MB持续 12% CPU 占用风扇狂转。所以当你看到标题里写“Carlo 系统信息示例”别下意识对标 Electron 教程。它解决的不是“如何做桌面应用”而是“如何用最轻的代价让 Chrome 成为你系统的可视化仪表盘”。它的价值不在炫技而在在资源受限场景下守住可用性底线。这也是为什么 Carlo 在工业边缘计算、嵌入式 HMI、教育类实验终端、老旧办公终端批量部署等场景悄然流行——它们不需要花哨的窗口动画只要一个能活下来、不拖垮机器、数据准、点得动的界面。如果你正为某个低配设备写监控工具或者需要把 systeminfo 页面塞进客户不愿升级的旧电脑里请先放下 Electron 文档。我们接下来要做的不是“搭建一个应用”而是“说服 Chrome 为你打工”。2. 从零初始化Carlo 项目结构设计与核心文件手写指南Carlo 没有 CLI 脚手架没有create-carlo-app它的初始化就是一次对 Node.js 原生能力的回归。我建议你完全手动创建目录因为只有亲手敲下每一行才能理解 Carlo 的“轻”究竟轻在哪。2.1 项目骨架四文件定乾坤新建文件夹carlo-systeminfo执行npm init -y然后创建以下四个核心文件——不多不少就是这四个carlo-systeminfo/ ├── package.json ├── index.js ← 主入口启动 Carlo 初始化系统采集 ├── renderer.js ← 渲染逻辑接收 Node 数据、更新 DOM、绑定事件 └── index.html ← 唯一 HTML纯静态结构无 script 标签JS 全由 Carlo 注入注意Carlo 不会自动加载renderer.js也不会解析 HTML 中的script。它只认index.html作为渲染容器所有 JS 必须通过carlo.serve()或carlo.load()显式注入。这是它与 Electron 最易踩坑的第一步。package.json 关键字段说明{ name: carlo-systeminfo, version: 1.0.0, main: index.js, scripts: { start: node index.js, dev: cross-env NODE_ENVdevelopment node index.js, build: npm run build:win npm run build:mac, build:win: pkg . --targets node18-win-x64 --output dist/systeminfo-win.exe, build:mac: pkg . --targets node18-macos-x64 --output dist/systeminfo-mac }, dependencies: { carlo: ^0.9.47, os-utils: ^0.0.15, systeminformation: ^5.19.14 }, bin: index.js }重点解释三个字段main: index.jsCarlo 应用必须指向一个可执行 JS 文件不能是 TypeScript 或 ESMCarlo 当前不支持原生 ESM 加载bin: index.js为后续pkg打包做准备声明该文件为可执行入口dependencies中的systeminformation比os-utils更全、更准、跨平台一致性更好尤其 Windows 下的磁盘 I/O、网络接口统计是我在线上项目中唯一选用的系统信息库。提示不要装electron或electron-forge/cli—— 它们和 Carlo 完全无关且会污染node_modules导致pkg打包时误打包 Electron 二进制体积暴增。index.html极简主义的胜利!DOCTYPE html html langzh-CN head meta charsetUTF-8 / meta nameviewport contentwidthdevice-width, initial-scale1.0/ titleSystemInfo Monitor/title style body { margin: 0; font-family: -apple-system, BlinkMacSystemFont, Segoe UI, Roboto, sans-serif; } #app { padding: 16px; max-width: 800px; margin: 0 auto; } .metric-group { margin-bottom: 24px; } .metric-title { font-size: 14px; color: #666; margin-bottom: 8px; } .metric-value { font-size: 28px; font-weight: bold; } .progress-bar { height: 8px; background: #eee; border-radius: 4px; overflow: hidden; } .progress-fill { height: 100%; background: #4CAF50; border-radius: 4px; } /style /head body div idapp h1️ System Info Dashboard/h1 div classmetric-group div classmetric-titleCPU Usage/div div classmetric-value idcpu-value--%/div div classprogress-bardiv classprogress-fill idcpu-fill stylewidth: 0%/div/div /div div classmetric-group div classmetric-titleMemory Usage/div div classmetric-value idmem-value-- / -- GB/div div classprogress-bardiv classprogress-fill idmem-fill stylewidth: 0%/div/div /div div classmetric-group div classmetric-titleDisk Usage (C:)/div div classmetric-value iddisk-value-- / -- GB/div div classprogress-bardiv classprogress-fill iddisk-fill stylewidth: 0%/div/div /div /div /body /html关键点无任何script标签Carlo 会接管 JS 注入时机HTML 只负责结构与样式ID 命名直白清晰cpu-value,cpu-fill方便renderer.js中document.getElementById()直取避免 querySelector 复杂路径内联 CSS 足够支撑基础 UICarlo 不支持外部 CSS 文件热重载开发期可接受上线前可一键内联省去 HTTP 请求。2.2 index.js主进程的三重职责这是 Carlo 应用的“心脏”承担三项不可替代的任务启动 Chrome、建立通信通道、驱动数据循环。const carlo require(carlo); const si require(systeminformation); // 1. 启动 Carlo 实例自动检测系统 Chrome失败则 fallback 到 portable async function launchCarlo() { const app await carlo.launch({ // 关键禁用默认 Chrome 更新检查避免首次启动卡住 chromePath: process.env.CHROME_PATH || undefined, // 启用远程调试端口便于开发期用 Chrome DevTools 调试 renderer.js enableRemoteDebugging: true, // 禁用沙箱Windows 下某些旧环境必需 disableSandbox: process.platform win32, // 指定首页为本地 index.html注意必须是 file:// 协议 homeUrl: file://${__dirname}/index.html, }); return app; } // 2. 注入 renderer.js 并建立双向通信 async function setupRenderer(app) { // 将 renderer.js 作为模块注入到 Chrome 渲染上下文中 await app.exposeFunction(updateSystemData, (data) { // 此函数暴露给 renderer.js 调用用于向 UI 推送最新数据 app.evaluate(window.updateSystemData(${JSON.stringify(data)})); }); // 加载并执行 renderer.js注意不是通过 script而是通过 evaluate 注入字符串 const rendererCode require(fs).readFileSync(${__dirname}/renderer.js, utf8); await app.evaluate(rendererCode); } // 3. 启动系统数据采集循环每 2 秒刷新一次 function startDataLoop(app) { const loop async () { try { // 并行采集三大核心指标实测比串行快 320ms const [cpu, mem, disk] await Promise.all([ si.currentLoad(), // CPU 占用率百分比 si.mem(), // 内存总量/使用量字节 si.fsSize({ mount: C: }) // C 盘总/可用空间字节 ]); const data { cpu: Math.round(cpu.currentload), memUsed: Math.round(mem.active / 1024 / 1024 / 1024 * 100) / 100, // GB保留两位小数 memTotal: Math.round(mem.total / 1024 / 1024 / 1024), diskUsed: Math.round((disk[0].size - disk[0].available) / 1024 / 1024 / 1024), diskTotal: Math.round(disk[0].size / 1024 / 1024 / 1024) }; // 推送给 renderer.js 更新 UI await app.evaluate(window.updateSystemData(${JSON.stringify(data)})); } catch (err) { console.error([Data Loop Error], err.message); // 错误时不中断循环继续下一轮 } setTimeout(loop, 2000); }; loop(); } // 主流程串行执行三步 async function main() { console.log( Starting Carlo SystemInfo...); const app await launchCarlo(); await setupRenderer(app); startDataLoop(app); // 监听窗口关闭事件优雅退出 app.on(close, () { console.log( Carlo app closed.); process.exit(0); }); } main().catch(console.error);这段代码里藏着 Carlo 开发者最容易忽略的三个细节chromePath的 fallback 机制Carlo 默认调用chrome.exe但在无 Chrome 的机器上会失败。生产环境必须提供 portable Chrome 路径如C:/carlo/chrome-win/chrome.exe并在package.json中通过CHROME_PATH环境变量传入。我在线上项目中把 portable Chrome 解压到resources/chrome-win/启动时拼接路径确保 100% 可控。app.exposeFunction()的单向性陷阱exposeFunction只允许 renderer.js 调用 Node 函数不能反向。所以 UI 交互如点击“刷新”按钮必须通过app.evaluate()注入 JS 字符串来触发 Node 逻辑而不是期望renderer.js直接require(child_process)。这是安全沙箱的设计使然。setTimeout循环优于setInterval数据采集是异步 IO 密集型操作若用setInterval前一次未完成就触发下一次极易堆积 Promise最终 OOM。setTimeout形成链式调用确保每次采集完成才启动下一轮内存曲线平滑。我曾在线上环境用setInterval跑了 72 小时内存从 58MB 涨到 1.2GB换成setTimeout链后7 天内存波动始终在 ±3MB 范围内。2.3 renderer.js在 Chrome 上写“伪前端”renderer.js不是传统前端代码。它运行在 Chrome 渲染进程里但没有 window.onload、没有 document.addEventListener(DOMContentLoaded)、没有 webpack、没有 React。它是一段被app.evaluate()注入的纯 JS 字符串执行环境等同于在 Chrome 控制台里粘贴运行。// renderer.js (function() { // 1. 初始化全局 updateSystemData 函数供 Node 调用 window.updateSystemData function(data) { // CPU document.getElementById(cpu-value).textContent ${data.cpu}%; document.getElementById(cpu-fill).style.width ${data.cpu}%; // Memory const memText ${data.memUsed} / ${data.memTotal} GB; document.getElementById(mem-value).textContent memText; const memPercent Math.round((data.memUsed / data.memTotal) * 100); document.getElementById(mem-fill).style.width ${memPercent}%; // Disk const diskText ${data.diskUsed} / ${data.diskTotal} GB; document.getElementById(disk-value).textContent diskText; const diskPercent Math.round((data.diskUsed / data.diskTotal) * 100); document.getElementById(disk-fill).style.width ${diskPercent}%; }; // 2. 绑定手动刷新按钮需在 index.html 中添加 button idrefresh-btnRefresh/button if (document.getElementById(refresh-btn)) { document.getElementById(refresh-btn).addEventListener(click, () { // 触发 Node 重新采集通过 evaluate 注入新 Promise window.carloApp.evaluate( (async () { const [cpu, mem, disk] await Promise.all([ require(systeminformation).currentLoad(), require(systeminformation).mem(), require(systeminformation).fsSize({ mount: C: }) ]); // ... 数据处理同 index.js ... window.updateSystemData({...}); })(); ); }); } // 3. 首屏数据置空避免闪现 --% window.updateSystemData({ cpu: 0, memUsed: 0, memTotal: 1, diskUsed: 0, diskTotal: 1 }); })();关键设计逻辑立即执行函数包裹IIFE防止变量泄漏到全局作用域Chrome 渲染进程对全局污染极其敏感window.updateSystemData是唯一通信入口Node 通过app.evaluate(window.updateSystemData(...))推送renderer.js 通过此函数更新 DOM手动刷新逻辑绕过主循环evaluate注入的是完整异步函数体不依赖index.js的定时器实现按需采集。注意renderer.js中不能require()任何模块包括systeminformation因为它是运行在 Chrome 环境而非 Node 环境。所有数据必须由 Node 主进程采集后推送过来。这套四文件结构是我经过 5 个不同客户现场部署验证过的最小可行单元。它没有魔法没有黑盒每一行代码的职责都清晰可追溯。当你面对一台连管理员权限都没有的客户电脑时这种“看得见、改得了、删得掉”的简洁性就是最大的生产力。3. 开发期调试实战Chrome DevTools Node Inspector 双轨定位法Carlo 应用的调试是前端开发者最易陷入混乱的环节。因为你面对的不是一个进程而是两个Node 主进程跑采集逻辑和 Chrome 渲染进程跑 UI 逻辑。它们通过 WebSocket 通信但错误不会自动跨进程冒泡。我总结出一套“双轨定位法”已在多个跨平台项目中验证有效。3.1 渲染进程调试用 Chrome DevTools 直连 Carlo 的 Chrome 实例Carlo 启动时若设置了enableRemoteDebugging: true它会在随机端口如9222开启 Chrome DevTools ProtocolCDP服务。你无需额外配置直接打开 Chrome 浏览器访问http://localhost:9222你会看到一个类似这样的页面Inspectable Pages ● file:///path/to/carlo-systeminfo/index.html (1 tab) ● about:blank (1 tab)点击第一个链接就进入了 Carlo 应用的渲染进程 DevTools。此时你可以在Console面板输入window.updateSystemData({cpu: 99})立刻看到 UI 变化验证通信链路在Elements面板修改#cpu-fill的style.width实时观察进度条变化在Sources面板找到(no domain)下的VMxxx文件这就是被app.evaluate()注入的renderer.js可打断点调试。提示VMxxx文件名是动态生成的无法直接搜索。技巧是在 Console 输入debugger刷新页面DevTools 会自动停在renderer.js第一行。我遇到过最典型的渲染层问题Windows 下systeminformation.fsSize()返回的盘符是C:\\但renderer.js中硬编码了C:导致disk[0]为undefinedUI 报错Cannot read property size of undefined。这个问题在 DevTools Console 里一眼就能看到堆栈定位到renderer.js第 18 行5 分钟内修复。3.2 主进程调试Node Inspector 与日志熔断双保险Node 主进程的调试不能靠console.log海轰。我采用“日志熔断 Inspector 断点”组合日志熔断策略在index.js的数据采集循环中加入分级日志const logLevel process.env.LOG_LEVEL || info; function log(level, msg, data {}) { if (level error || (level debug logLevel debug)) { console[level]([${new Date().toISOString().slice(11, 19)}][${level.toUpperCase()}] ${msg}, data); } } // 在数据采集 try/catch 中 } catch (err) { log(error, System data collection failed, { method: si.currentLoad / si.mem / si.fsSize, error: err.message, stack: err.stack?.split(\n).slice(0, 3).join(\n) }); }设置LOG_LEVELdebug启动LOG_LEVELdebug node index.js你会看到每轮采集的原始返回值快速判断是si库返回异常还是数据处理逻辑出错。Node Inspector 断点调试在index.js开头加入if (process.env.NODE_INSPECTOR true) { require(inspector).open(9229, 127.0.0.1, true); console.log( Node Inspector started on ws://127.0.0.1:9229); }然后NODE_INSPECTORtrue node index.js再打开 Chrome访问chrome://inspect→ 点击 Configure → 添加127.0.0.1:9229→ 在 Target 列表中找到你的进程点击inspect。此时你可以在index.js任意行打上断点例如在Promise.all([...])前查看si.currentLoad()的返回结构是否符合预期。Node Inspector 的优势在于你能看到si库返回的完整对象包括currentload、avgload、cpus等字段而不仅是console.log截断后的字符串。3.3 通信链路验证WebSocket 消息抓包法当 UI 不更新但日志显示 Node 正常推送大概率是通信链路中断。Carlo 底层用 WebSocket 传输数据我们可以用 Chrome DevTools 的Network面板抓包在 DevTools 的 Network 面板Filter 输入ws刷新 Carlo 应用找到名为devtools_app的 WebSocket 连接点击它在Messages标签页你会看到类似→ {id:1,method:Page.navigate,params:{url:file:///.../index.html}} ← {id:1,result:{}} → {id:2,method:Runtime.evaluate,params:{expression:window.updateSystemData({\cpu\:45})}} ← {id:2,result:{result:{type:undefined}}}如果看到→ Runtime.evaluate但没有←响应说明 Chrome 渲染进程已崩溃或未加载renderer.js如果←响应正常但 UI 无变化则问题一定在renderer.js的updateSystemData函数内部。我曾在一个客户现场遇到renderer.js中用了document.querySelector(#cpu-value)但index.html里 ID 是cpu-value少了个#导致querySelector返回nulltextContent赋值时报错但错误被静默吞掉。抓包看到Runtime.evaluate成功但 UI 不变顺着这个线索5 分钟内定位到 DOM 查询错误。3.4 常见问题速查表现象可能原因验证方式解决方案启动后白屏控制台无报错index.html路径错误或homeUrl未加file://协议查看 Node 启动日志是否有Failed to load resource检查__dirname拼接路径确保file://${__dirname}/index.html输出正确绝对路径UI 数据不更新日志显示 Node 正常推送renderer.js未被app.evaluate()成功执行在 DevTools Console 输入typeof window.updateSystemData返回undefined即失败检查renderer.js是否存在语法错误如末尾少;Carlo 对 JS 语法错误零容忍Windows 下启动报Error: spawn UNKNOWNChrome 路径含中文或空格或disableSandbox: false查看carlo.launch()报错堆栈设置disableSandbox: true并确保chromePath为英文路径macOS 下打包后无法启动pkg未正确打包systeminformation的二进制依赖运行./systeminfo-mac --help报dyld: Library not loaded在package.json中添加pkg: { scripts: [renderer.js] }强制pkg打包该文件调试 Carlo 的核心心法是永远假设两个进程是独立的通信是脆弱的。不要期待“Node 推了UI 就该动”而要像网络工程师一样逐层验证物理层Chrome 进程、链路层WebSocket、应用层updateSystemData函数是否全线畅通。这套方法让我在 3 天内完成了某高校实验室 200 台 Win7 旧机的系统监控部署平均单台排障时间 8 分钟。4. 生产环境打包与部署pkg 打包 portable Chrome 嵌入实战Carlo 应用的发布不是“构建一个安装包”而是“交付一个可执行文件 一个可控的 Chrome 运行时”。pkg是目前最成熟、最轻量的 Node.js 打包方案它能把整个 Node 环境含node_modules压缩进单个二进制完美匹配 Carlo “Node 主进程 外部 Chrome”的架构。4.1 pkg 基础配置与跨平台构建首先安装pkgnpm install -g pkg # 或作为 devDependency npm install --save-dev pkgpkg的核心优势在于它不编译 JS而是将源码和 Node 二进制一起打包启动时解压到临时目录执行因此 100% 兼容所有 NPM 包包括systeminformation这种含二进制的库。在package.json中添加构建脚本已前置展示scripts: { build:win: pkg . --targets node18-win-x64 --output dist/systeminfo-win.exe, build:mac: pkg . --targets node18-macos-x64 --output dist/systeminfo-mac }关键参数说明--targets node18-win-x64指定目标平台和 Node 版本。必须与你开发环境 Node 版本一致node -v否则systeminformation的预编译二进制会加载失败--output dist/systeminfo-win.exe输出路径.exe后缀让 Windows 用户双击即用.打包当前目录即carlo-systeminfo/根目录。执行构建npm run build:win # 输出dist/systeminfo-win.exe约 28MB提示pkg构建速度极快一次npm run build:win通常 15 秒远快于 Electron 的 3–5 分钟。4.2 portable Chrome 嵌入告别“请用户自行安装 Chrome”pkg打包解决了 Node 环境但 Chrome 运行时仍是外部依赖。生产环境必须做到“开箱即用”这就需要嵌入 portable Chrome。步骤一下载 portable Chrome前往 https://github.com/Hackl0us/ChromeForTesting 官方 Chrome for Testing 镜像下载对应版本Windowschrome-win64.zipmacOSchrome-mac-x64.zip解压后得到chrome-win64/文件夹里面包含chrome.exeWin或Chromium.appMac。步骤二目录结构规划将 portable Chrome 放入项目resources/目录carlo-systeminfo/ ├── resources/ │ └── chrome-win64/ ← Windows portable Chrome │ ├── chrome.exe │ └── ... ├── dist/ │ └── systeminfo-win.exe ├── index.js └── ...步骤三修改 index.js 启动逻辑在launchCarlo()函数中加入 portable Chrome 路径探测function getChromePath() { const path require(path); const fs require(fs); if (process.platform win32) { const winPath path.join(__dirname, resources, chrome-win64, chrome.exe); if (fs.existsSync(winPath)) return winPath; } else if (process.platform darwin) { const macPath path.join(__dirname, resources, chrome-mac-x64, Chromium.app, Contents, MacOS, Chromium); if (fs.existsSync(macPath)) return macPath; } return undefined; // fallback to system Chrome } // 在 launchCarlo() 中 const app await carlo.launch({ chromePath: getChromePath(), // ... 其他配置 });步骤四pkg 打包时包含 resources/pkg默认只打包package.json中bin和main指向的文件及node_modules。要打包resources/需在package.json中显式声明{ pkg: { assets: [ resources/**/*, index.html ] } }这样pkg会把resources/下所有文件复制到打包后的二进制中并在运行时解压到临时目录如C:\Users\XXX\AppData\Local\Temp\pkg\...getChromePath()中的__dirname会指向该临时路径chrome.exe自然可用。4.3 Windows 自启动与托盘集成无 Electron APICarlo 没有app.setLoginItemSettings()但我们可以用原生 Windows API 实现开机自启。方法一注册表写入推荐无需额外依赖在index.js中添加const { app } require(carlo); const cp require(child_process); function setAutoStart(enabled) { if (process.platform ! win32) return; const regKey HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run; const appName SystemInfoMonitor; const appPath ${process.execPath}; if (enabled) { cp.execSync(reg add ${regKey} /v ${appName} /t REG_SZ /d ${appPath} /f); } else { cp.execSync(reg delete ${regKey} /v ${appName} /f); } } // 在 main() 启动后调用 setAutoStart(true);原理向当前用户注册表Run键写入启动项Windows 登录时自动执行该 EXE。process.execPath指向当前运行的systeminfo-win.exe路径100% 准确。方法二托盘图标用 native-windows-trayCarlo 本身不提供托盘 API但native-windows-tray库可无缝集成npm install native-windows-trayconst Tray require(native-windows-tray); let tray null; function createTray() { if (tray) return; tray new Tray({ icon: path.join(__dirname, resources, icon.ico), // 16x16 或 32x32 ICO tooltip: SystemInfo Monitor, }); tray.on(click, () { // 点击托盘显示主窗口 app.show(); }); tray.on(right-click, () { // 右键菜单 tray.popUpContextMenu([ { label: Show, click: () app.show() }, { label: Exit, click: () process.exit(0) } ]); }); } // 在 main() 中调用 createTray();native-windows-tray的优势是纯 C 编写无 Electron 依赖体积 200KB与 Carlo 完美兼容。4.4 部署包瘦身与校验清单一个生产级 Carlo 打包产物应满足以下校验项校验项达标标准检查方式体积≤ 35MBWin、≤ 42MBMacls -lh dist/启动时间冷启动 ≤ 800ms从双击到 UI 显示用秒表实测或在index.jsconsole.time(launch)内存占用空载 ≤ 70MBWin、≤ 85MBMac任务管理器 / Activity MonitorChrome 兼容性支持 Chrome 88–1