# Day 1：外贸客服为什么要自己造 IM 聚合客户端？

逸铭
0 阅读5分钟

外贸客服的真实痛点：账号多到任务栏装不下。本篇讲清楚为什么要用 Electron 做 IM 聚合、三栏架构怎么定，以及浏览器多开为什么不够香——为后面 29 天的实战代码打个地基。

开场：任务栏勇士的周一

周一早上 9:07，运营小姐姐发来一条消息：

「今天帮忙盯一下，7 个 Telegram、3 个 WhatsApp、还有 2 个 Line。都在线，别漏回。」

我最小化 IDE，看向任务栏——好家伙，一排浏览器图标像地铁早高峰，每个窗口里还藏着不同的登录态。切错窗口回复「亲，这边已经发货了哦」给错客户，这种事发生过一次就够了，足够让你想连夜重写人生。

午饭时我在白板上画了个框：左边选账号，中间聊天，右边放翻译和话术。同事老王说：「这不就是 SCRM 吗？」我说：「对，但我们要先让它能跑起来，名字以后再说。」

于是 AnchorChat（锚聊）这个项目，在我们小团队一个普通的周一开始了。

系列连载的第 1 天，不写代码，先把「为什么要造轮子」讲明白。

说明：本系列是 Electron 桌面客户端开发实战。文中出现的 Telegram、WhatsApp、Line 等，均指在 已有合规外贸业务环境 下对接其官方 Web 版的技术方案。

浏览器多开：能用，但不太想一直用

先别急着上 Electron，很多人第一反应是：Chrome 多用户 / 独立 Profile / 插件套壳，不也能多开吗？

能。但我们踩过这些坑：

  • 登录态串味：同 Profile 下 Cookie 共享，运营同学手滑登错号，客户收到来自「另一个自己」的问候
  • 翻译和话术得每页注入一遍：Telegram Web 和 WhatsApp Web 的 DOM 完全不同，浏览器插件覆盖有限，升级一次改八遍
  • 没有「桌面级」能力：系统托盘、全局快捷键、截图翻译、本地 SQLite 缓存、离线队列重试——网页里要么做不了，要么做得很拧巴
  • 内存：15 个 Chrome 标签 + 15 个 IM 页，风扇声像起飞，笔记本直接变暖手宝

我们需要的是：一个原生壳 + 多个隔离会话 + 统一工具栏。Electron 正好：Chromium 内核嵌入 IM Web 版，Node 主进程干脏活累活，Vue 做左右两栏原生 UI。

AnchorChat 长什么样：三栏架构

定产品形态只花了一个下午，结构却用了很久——因为后面 29 天都是往这三个格子里填东西：

day-01-architecture.png

左侧 — 账号栏（Electron 原生 Vue）

  • 添加 / 删除 / 排序各平台账号
  • 同一平台可挂多个号（比如 3 个 WhatsApp 业务员号）
  • 休眠、激活，避免 N 个 webview 同时吃内存

中间 — 主区域（<webview>）

  • 嵌入 Telegram、WhatsApp、Line 等 官方 Web 版
  • 每个账号独立 partition，相当于「一账号一房间，钥匙别混」
  • 通过 preload 脚本 在页面里挂翻译条、采集消息

右侧 — 工具栏（Electron 原生 Vue）

  • 翻译设置、快捷回复、客户备注、AI 助手……[ps:不一定有哪些功能，看后续业务需要]
  • 和 webview 里的 preload 通过 IPC 对话，不污染 IM 页面本身

用一张简图概括：

flowchart LR
  subgraph Native[&#34;Electron 原生 UI&#34;]
    Left[&#34;左侧账号栏&#34;]
    Right[&#34;右侧工具栏&#34;]
  end
  subgraph Webview[&#34;中间 webview&#34;]
    Preload[&#34;preload 注入&#34;]
    WebIM[&#34;Telegram / WhatsApp / Line Web&#34;]
  end
  subgraph Main[&#34;主进程&#34;]
    IPC[&#34;IPC / SQLite / HTTP&#34;]
  end
  Left --> Webview
  Right --> IPC
  Preload --> IPC
  WebIM --> Preload

三个仓库，各干各的

项目拆成三个 repo，不是炫微服务，是 职责清晰、发版灵活：

  • 客户端：窗口、webview 容器、登录、翻译 IPC、本地数据库
  • Preload 脚本仓：每个 IM 平台一个注入脚本，DOM 变了只改对应平台，不必整包发版
  • 管理后台：工单、计费、聊天记录查看（客户端负责写，后台负责读）

PS：只是根据目前业务可能到的一些功能以及现在可预想的情况进行一个仓库都划分，后续根据实现和业务变化也可能有改动

技术选型

需求选型一句话理由
桌面壳Electron成熟、webview 现成、Node 主进程好写 IPC
前端 UIVue 3 + Element PlusSplit 布局开箱即用
构建Vite + vite-plugin-electron开发体验比 webpack 省心
本地缓存better-sqlite3翻译结果、消息去重放本地，别啥都打 API
IM 接入官方 Web 版 + preload不逆向协议，跟 DOM 升级赛跑（后面会哭）

Electron 的代价也要说清楚：包体大、内存占用高。但对外贸客服这种「一天 10 小时钉在聊天上」的场景，稳定和多账号隔离比「安装包少 50MB」重要——这是我们的 trade-off，不是银弹。

踩坑与思考

  • 别第一天就接 19 个平台。我们先 Telegram，再 WhatsApp，模板化了再复制到其他平台。贪多嚼不烂，DOM 会教做人。
  • 产品名可以后定，架构别反复横跳。三栏定下来后，左右 native、中间 webview 的边界很清晰，后面加 AI、加 CRM 都是往 RightPanel 塞 Tab。
  • 合规与隐私：聊天记录同步、客户标签要做，但截图发博客得打码——真实聊天内容别上网，懂的都懂。

明日预告

Day 2 我们动手：10 分钟搭 Electron + Vite + Vue 3 的空壳，让 npm start 能弹出一个像样窗口。界面丑没关系，能跑就是胜利——毕竟 Day 30 回头看，Day 2 的 Hello World 会可爱得像刚学走路的照片。

你们做多账号 IM 工作台，用的是浏览器多 Profile 还是 Electron？任务栏最多开过几个窗口？评论区聊聊你的方案——Day 2 见。

avatar
文章
阅读
粉丝