Carlo 技术博客中的前端实战与性能优化经验分享

为什么我还在纠结 Carlo 这个东西？

最近一个 Electron 项目跑得有点卡，用户反馈“启动慢得像在加载整个宇宙”，我琢磨着是不是该换轻量方案。正好看到 Carlo——Google 出的基于 Chrome 的桌面应用运行时，号称“用 Chrome 浏览器当壳，前端代码直接跑”。听起来挺香，但实际用下来，发现它和主流方案（比如 Electron、Tauri）比起来，坑不少，也有些意外的爽点。

这篇文章不是科普，就是我折腾完 Carlo 后的真实感受。如果你也在选型，希望这篇能帮你少走点弯路。

Carlo 是个啥？先看两行代码

Carlo 的核心思想很简单：不打包 Chromium，而是调用你本地已安装的 Chrome/Edge 来渲染界面。启动时，它会找系统里有没有 Chrome，有的话就用它开一个无头窗口，然后把你的 HTML 渲染进去。

最简单的例子：

const carlo = require('carlo');

(async () => {
  const app = await carlo.launch();
  await app.serveFolder(__dirname);
  await app.load('index.html');
})();

对比一下 Electron 的写法：

const { app, BrowserWindow } = require('electron');

app.whenReady().then(() => {
  const win = new BrowserWindow({ width: 800, height: 600 });
  win.loadFile('index.html');
});

看起来 Carlo 代码更短，但别被迷惑了——这背后隐藏了很多限制。

谁更灵活？谁更省事？

我比较喜欢用 Tauri 写新项目，因为 Rust + Web 前端的组合够轻、启动快。但公司老项目是 Electron，迁移成本高。Carlo 看似是中间选项，但实际用起来很拧巴。

灵活性方面，Electron 完胜。 你想控制菜单、托盘、系统通知、文件读写？Electron 全都有现成 API。Carlo 呢？基本没有。它只提供一个 exposeFunction 让你从前端调 Node.js，但系统级交互几乎为零。想做个右键菜单？自己想办法吧。

举个例子，我想从前端调个原生弹窗：

// Electron
const { dialog } = require('electron').remote;
dialog.showMessageBox({ message: 'Hello' });

// Carlo - 得自己暴露
await app.exposeFunction('showMessage', (msg) => {
  // 这里其实还是得依赖 Electron-like 的模块，但 Carlo 本身不提供
  console.log(msg); // 实际做不到系统弹窗
});

看到没？Carlo 把锅甩给你了。你得自己搭桥，而且很多功能根本搭不起来。

省事？那得看场景。 如果你只是想快速跑个网页当桌面应用，且用户肯定装了 Chrome，那 Carlo 启动确实快——因为它不用带 Chromium。但一旦用户没装 Chrome（比如某些精简版 Windows），直接崩。Electron 虽然包大，但自包含，开箱即用。

性能对比：差距比我想象的大

我拿一个 React 后台管理页面测了下冷启动时间（从点击图标到页面可交互）：

• Electron：约 2.1 秒（打包后 120MB）
• Tauri：约 0.8 秒（打包后 5MB）
• Carlo：约 0.6 秒（但前提是 Chrome 已在后台运行）

乍看 Carlo 最快，但这是理想情况。如果 Chrome 没开，第一次启动要等 Chrome 启动，反而更慢。而且 Carlo 无法控制 Chrome 的版本，万一用户用的是三年前的老 Chrome，你的新语法直接报错。

这里注意我踩过好几次坑：本地开发用最新 Chrome 没问题，一到测试机（Windows 10 默认 Edge Legacy）就白屏。后来才发现 Carlo 只认 Chrome 和新版 Edge（Chromium 内核），其他浏览器一律无视。

我的选型逻辑

折腾了半天发现，Carlo 适合非常特定的场景：

• 内部工具，且 IT 部门强制所有机器装了最新 Chrome
• 临时 demo，不想打包，快速分享给同事
• 你就是 Google 员工，能确保环境一致

除此之外，我一般选 Tauri。虽然要学点 Rust，但换来的是小体积、快启动、安全沙箱。Electron 呢？老项目维护继续用，新项目除非有复杂原生需求（比如要深度集成 Windows Shell），否则我不碰。

Carlo？说实话，自从 Google 自己都不更新了（GitHub 最后 commit 是 2019 年），我就知道它凉了。现在连文档链接都 404，社区问题没人答。这种“半成品”框架，除非你有特殊理由，否则别碰。

踩坑提醒：这三点一定注意

如果你非要用 Carlo，记住这三条血泪教训：

1. 不要假设用户有 Chrome。启动前得检测，没装就弹个提示，别让用户一脸懵。
2. Node.js 版本兼容性。Carlo 依赖 Puppeteer，而 Puppeteer 对 Node 版本有要求。我在 Node 18 上跑，结果 Carlo 内部用的旧版 Puppeteer 直接报错。降级到 Node 16 才行。
3. 跨域和本地文件。Carlo 用 serveFolder 时，默认允许跨域，但如果你自己启 HTTP 服务（比如用 Express），就得手动加 CORS 头，否则 fetch 会失败。我在这卡了整整一天，最后发现是 Carlo 的 serve 机制和常规 HTTP 服务器行为不一致。

补充个代码片段，正确处理本地 API 调用：

const carlo = require('carlo');
const express = require('express');
const cors = require('cors');

const api = express();
api.use(cors()); // 关键！否则前端 fetch 被拦
api.get('/data', (req, res) => {
  res.json({ time: Date.now() });
});
api.listen(3001);

(async () => {
  const app = await carlo.launch();
  await app.serveFolder(__dirname);
  // 前端用 fetch('http://localhost:3001/data')
  await app.load('index.html');
})();

总结：Carlo 不是未来，只是过渡

Carlo 的想法不错——利用现有浏览器减少重复打包。但现实是，桌面应用需要的不只是渲染，还有系统集成、稳定性、离线能力。这些 Carlo 都没解决，反而把复杂度转嫁给开发者。

我现在的结论很明确：新项目别用 Carlo。要么上 Tauri（轻量现代），要么继续用 Electron（生态成熟）。Carlo 就让它留在 2019 年吧。

以上是我踩坑后的总结，希望对你有帮助。如果你有不同看法，或者在特殊场景下成功用 Carlo 跑起来了，欢迎评论区交流——说不定你能说服我再给它一次机会。