1. 项目与需求拆解1.1 瞄准的痛点阅读中的上下文断裂做这个插件的念头来得特别实际。我每天要啃大量外文资料英文论文、技术博客、产品文档偶尔还有日文和韩文的开源项目说明。原来那种“选中一段文字复制切到在线翻译粘进去看结果再切回原文”的流程一天重复几十次之后人基本就麻了。最让人崩溃的不是翻译慢而是上下文断裂——当你切走再看回来时很难精准回忆起刚才读到哪一句逻辑线也断了。尤其一篇上万字的论文每看几段就要切一次读完一整篇可能要多花半小时还容易读得囫囵吞枣。后来我认真想了想自己真正需要的东西其实是一个能内嵌到阅读场景里的辅助翻译工具。它的核心诉求有三个第一触发要快最好选中文本后一键就能出译文第二译文要跟原文待在一起不要跳窗不要切走原文在上、译文在下或者左右对照一眼扫过去就能建立对应关系第三最好能有点 AI 的“聪明劲”遇到长句别傻乎乎逐字硬翻能把术语、语境、语气尽量保住。这三个诉求整合到一起就是标题里说的“实时双语对照的 AI 辅助翻译插件”。我管这个项目叫“LinguaPair”一个完全虚构的练手代号。它最终做成了一款 Chromium 内核浏览器的扩展插件选中文案后译文以内联卡片的形式出现在页面里支持实时刷新、缓存复用和多种对照样式。这个项目适合这么几类人参考一是经常读外语资料但不想频繁切窗口的人二是想系统了解浏览器扩展怎么读写页面选中内容的前端开发者三是对翻译服务的封装、缓存和并发控制感兴趣、想看看工程上怎么做得更稳的人。1.2 为什么插件形态最合适在动手之前我其实先脑爆过一轮是不是应该做一个独立桌面应用或者做一个 IDE 插件又或者干脆做成网页工具复制粘贴就完事把候选方案摊开对比之后答案很明确浏览器扩展是现阶段性价比最高的形态。桌面应用的好处是运行环境稳定不依赖浏览器差异但它有个致命问题拿不到用户正在阅读的网页内容。如果走“全局划词翻译”的路线等于要在操作系统层面捕获鼠标选中的文本Windows 和 macOS 的实现机制完全不同光是适配就够喝一壶。再说桌面应用的安装成本高用户得先下载安装包再配置各种权限对于“我想赶紧翻译一下这篇文档”的场景来说太重了。IDE 插件只适合程序员群体覆盖面太窄而且 IDE 的渲染机制和普通网页差别很大做“双语对照”的展现效果很受限。网页工具虽然是零安装但使用路径仍然逃不开“复制-粘贴-切走”的宿命并没有真的解决上下文断裂的问题。浏览器扩展的优势是天然的“就在现场”。它运行在浏览器内部有权限读取当前页面的 DOM 和选区状态可以把翻译结果直接渲染到正在阅读的位置附近。Chrome 的扩展生态又比较成熟Manifest V3 提供了标准化的权限模型和后台服务机制开发成本不算高。对我这种单手就能写点 JavaScript 的开发者来说从零到出第一个能用的版本一个周末就能搞定。再加上 Chromium 内核的浏览器举几个常见的比如 Chrome、Edge、Opera以及各种国产双核浏览器市场占有率足够高一个扩展几乎就等于覆盖了绝大多数桌面阅读场景。1.3 实时与对照两个“非这样不可”的设计决策这个项目名字里有两个修饰词我特意在早期设计阶段就咬死不放一个是“实时”一个是“双语对照”。为什么它们非做不可我来解释一下。先说“实时”。我观察过自己的阅读习惯碰到生词或者复杂长句我希望译文能在几百毫秒内出现如果 3 秒还没出结果我的注意力就会开始晃动甚至会怀疑是不是插件挂了。实时性不是“锦上添花”而是保证“划词翻译”这个交互成立的前提。翻译本质上是打断阅读节奏的副操作如果副操作本身还要漫长等待那它带来的负担就超过了收益。要做到“实时”不能光靠网速还得靠工程手段请求要防抖避免高频触发造成请求风暴结果要缓存相同内容第二次出现就直接命中超时要有兜底别让一个慢请求卡住后续所有翻译。再说“双语对照”。很多人做划词翻译喜欢用 tooltip 气泡鼠标指上去弹一个小框里面只有译文。气泡方案的问题在于译文跟原文的对应关系是瞬时的气泡消失后你只记得“大概翻译了”却没法回头对照某个词到底是什么。而双语对照把“原文”和“译文”都留在页面上相当于给你提供一个平行的阅读轴。读英文句子没看懂时视线斜向下扫一眼中文中文翻译得不对劲时又能立刻对比英文原文发现问题。这种“对照”不只是让读者读懂更是让读者校验译文的准确性对学术阅读和严谨的技术文档场景尤其重要。我甚至觉得这个设计决策的重要性比翻译引擎本身还高因为它是信息组织方式的创新而不只是 API 调用的堆叠。2. 架构设计与翻译引擎选型2.1 整体工作流程LinguaPair 的整体架构可以浓缩成这么一条链路用户在页面上选中一段文本通过右键菜单或浮动按钮触发翻译内容脚本Content Script拿到选区文本后不直接发请求而是先经过调度器做归一化和缓存查询如果缓存命中就把译文化妆成对照卡片渲染出来如果没命中则根据配置选择一个翻译适配器本地模型或在线接口发起请求拿到响应后一边写缓存一边渲染渲染完自动调整卡片位置避免遮挡后续内容。这条链路上有三个角色协同工作背景脚本Background Service Worker负责创建右键菜单、管理扩展级状态内容脚本负责和页面 DOM 打交道包括选区捕获、卡片渲染、样式隔离弹窗页Popup负责展示配置项让用户选目标语言、切引擎、调样式。三者之间通过 chrome.runtime.sendMessage 传递消息消息体里只放轻量的 JSON不传大段原文避免标签页被拖慢。这个流程看起来简单但真正实现起来有几个容易翻车的点选区文本在用户点开右键菜单的瞬间可能失效需要提前捕获渲染进页面的节点必须能被完整追踪否则关掉卡片时会留下残留 DOM在线请求如果和本地请求同时发出可能出现“先发后至”渲染时需要用请求序号过滤过期响应。这些问题我在后面会单独展开讲。2.2 三种翻译方案对比翻译引擎的选型我花的时间最多。市面上可选的方案大概能分成三类纯在线接口、纯本地模型、本地加在线的混合模式。我先列个表把我实际对比时的关注点展示出来。方案延迟表现隐私安全运行成本翻译质量断网可用纯在线接口通常 300-1000ms受网络波动影响大原文会发送到第三方服务器敏感文档慎用按量付费或有免费额度量大了要花钱大厂开放平台的效果普遍不错长句流畅不可以纯本地模型单机 CPU 推理几百 ms 到几秒看机器配置文本不出设备隐私最好硬件投入模型文件占用几个 GB小尺寸模型对专业术语和复杂长句的把握弱一些可以本地在线混合短句本地秒出长难句切在线默认本地只有需时才上云兼顾成本和隐私但实现复杂度更高综合效果取决于调度策略大部分场景可用如果只是做一个自用的小工具选“纯在线接口”是最省事的注册一个开放平台的账号拿个密钥三个接口调用就接完了。但我最终选了混合模式最主要的原因是隐私。我读的资料里有一部分是未公开的技术方案和产品文档让这些内容在本地网络里待着比较踏实所以我希望默认路径走本地模型只有遇到复杂长句或者用户主动切换时再走在线接口。说句实话混合模式的开发量比纯在线翻了大概一倍但使用体验和安全感也是实打实的。另外补充一点本地模型并不意味着要自己从零训练。现在有很多开源的小型翻译模型量化之后在普通 CPU 上也能跑起来配合像 ONNX Runtime 这样的推理框架集成成本远低于想象。我最后选用的是一个大约 2GB 的量化翻译模型在 M 系列芯片的笔记本上翻译一句 30 词的英文长句耗时大概 400ms 到 800ms完全在可接受范围内。2.3 混合调度的细节什么时候用本地什么时候用在线混合模式听上去很美好但真正难写的是“调度策略”。定调度策略之前我先回顾了自己翻译时最常遇到的痛点短句和常见句本地模型完全能应付质量也不错长难句、带有复杂从句的论文摘要、中英混排的代码注释本地模型经常翻得前言不搭后语。于是我的调度规则就设计成了三档第一低风险快速通道。待翻译文本去掉空格后少于 80 个字符直接走本地模型不经过任何犹豫。这个体量的句子翻译耗时通常在 300ms 以内用户几乎感觉不到等待而且就算翻译得不够完美句子短用户一眼就能看明白。第二智能切换通道。文本长度在 80 到 300 个字符之间先尝试本地模型同时启动一个 500ms 的计时器。如果本地模型在 500ms 内完成就直接用如果没完成就把同一个请求取消转投在线接口。这个策略的核心是“本地优质快速”和“在线兜底”的赛跑机制实际体验下来效果不错。第三复杂文本通道。文本超过 300 个字符或者包含明显的分号、多重复句、专业术语密度很高时默认直接走在线接口因为本地小模型在这种输入上基本可以预判会翻得很烂没必要浪费算力。这里有一个非常重要的细节在线接口的调用频率和密钥安全。浏览器扩展的代码是公开可见的绝对不能把密钥硬编码到前端代码里。我采用的做法是密钥只存在扩展的后台服务中内容脚本发起的翻译请求先到后台由后台附加鉴权头再转发给接口平台。这样至少能防住普通用户一眼看穿的问题对于高强度逆向的情况反正是自用工具做到这个程度就够了。3. 核心模块实现与代码解析3.1 项目骨架Manifest V3 与权限设计LinguaPair 的技术栈没有用什么奇技淫巧就是最朴素的 HTML/CSS/JavaScript构建工具用的是 Vite 加一个扩展插件模板。之所以不用 React 之类的大型框架是因为内容脚本要操作的是宿主页面的 DOM框架的虚拟 DOM 在跨文档渲染场景下反而碍手碍脚不如直接用原生 DOM API 来得干脆。第一步是写 manifest.json这是扩展的身份证也是浏览器安全模型的入口。我的关键配置长这样{ manifest_version: 3, name: LinguaPair - Bilingual Reader, description: Select text on any page and get inline bilingual translations instantly., version: 1.0.0, background: { service_worker: background.js, type: module }, content_scripts: [ { matches: [all_urls], js: [content.js], css: [content.css], run_at: document_idle } ], permissions: [contextMenus, storage, activeTab], action: { default_popup: popup.html, default_icon: icons/icon.png } }这个配置里最核心的是权限声明。我只申请了contextMenus创建右键菜单、storage保存用户配置和缓存索引、activeTab与当前标签页临时交互。注意我没有申请all_urls的host_permissions。为什么因为内容脚本在 manifest 里声明matches: [all_urls]已经可以注入所有页面如果再加 host 权限Chrome 商店审核时会要求你说明为什么需要跨域读取能力而且用户看到那么多权限警告安装意愿会降低。作为自用项目权限上“够用就好”是正确的选择。内容脚本注入的时机选了document_idle这意味着 DOM 已经可用页面主体元素基本加载完。翻译卡片渲染依赖 DOM 结构太早注入会找不到插卡的位置太晚又会让人感觉插件响应慢。document_idle是最不打扰页面加载的选择。3.2 文本捕获三种触发方式与选区丢失问题文本捕获是整个插件的第一步也是最容易踩坑的模块。我做了三种触发方式右键菜单、选中后浮动按钮、快捷键。右键菜单是最传统的触发方式它由后台脚本在插件安装时创建// background.js chrome.runtime.onInstalled.addListener(() { chrome.contextMenus.create({ id: translate-selection, title: 翻译选中文本到中文, contexts: [selection] }); }); chrome.contextMenus.onClicked.addListener((info, tab) { if (info.menuItemId translate-selection) { chrome.tabs.sendMessage(tab.id, { type: TRANSLATE_SELECTION }); } });这里有个大多数人第一次都会被坑到的地方用户在页面上选中文本后点击鼠标右键弹出菜单此时如果内容脚本去读window.getSelection()大概率读到的是空字符串。原因是浏览器在弹出右键菜单时会把当前的选区高亮保留但当你把鼠标移向菜单项点击的瞬间原选区可能已经因为其他原因被清除了。稳妥的做法是在mousedown阶段就把选区文本存起来// content.js let savedSelection null; document.addEventListener(mousedown, (event) { // 只在主键按下时保存一次 if (event.button 0) { const sel window.getSelection(); if (sel sel.rangeCount 0 !sel.isCollapsed) { savedSelection sel.toString(); } else { savedSelection null; } } }, true);这样当后台脚本转发“翻译选中文本”的消息过来时内容脚本直接用savedSelection作为输入而不是临时去读选区。这种方式牺牲了一点点内存但换来了极高的可靠性。选中后浮动按钮的方案更接近“实时”的体感。我监听的是selectionchange事件但这个事件在鼠标光标每次轻微移动、选区范围变化的瞬间都会触发如果每次都创建浮动按钮页面会疯狂闪烁。我的处理是加一个防抖选区变化 250ms 后才判断是否要显示按钮同时用一个阈值判断“选中文本长度不能小于两个字符、也不能超过 5000 个字符”太短是因为单个字母不需要翻译太长是因为超大段落翻译容易超时不如引导用户分段。3.3 翻译调度器防抖、缓存和并发控制翻译调度器是插件的“大脑”。没有调度器的时候我遇到的现象是一次划词翻译如果用户连续在几个句子上来回划动页面上会同时飞着七八个翻译请求返回顺序乱成一团后来返回的结果可能覆盖先来的结果。调度器要解决的三件事分别是防抖、缓存、序号控制。防抖的核心思路是“事件合并”。用户在页面上快速划几个词只会触发最后一次真正的翻译请求。我用的是经典的 setTimeout 实现// content.js let debounceTimer null; function onTextSelected(text) { clearTimeout(debounceTimer); debounceTimer setTimeout(() { TranslationScheduler.schedule(text); }, 300); }300ms 是一个很微妙的阈值。小于 200ms用户在稍微停顿一下时就会误触发请求大于 400ms又会让操作显得迟钝翻译迟迟不出。我调了几轮300ms 体感最均衡。缓存模块我直接使用了 localStoragekey 是原文的 MD5 哈希value 是一个包含译文、时间戳的 JSON。这里有个细节缓存命中不代表永远有效翻译平台模型升级后同一个句子可能有更好的译法所以我设定 7 天过期。在内容脚本首次加载时会扫描全部缓存把过期的记录清理掉避免 localStorage 被撑爆。并发控制的核心是序号机制。每次发起新翻译请求时调度器的requestSeq加一并把这个序号传给异步回调。只有“当前最新序号”的响应才有资格渲染其他响应即使比最新响应晚到达也直接丢弃。这个策略处理“用户先划了 A 句又马上划了 B 句但 A 句的翻译结果比 B 句先到”的场景非常有效。// scheduler.js let requestSeq 0; async function translateWithToken(text, token) { const result await translateAdapter(text); if (token ! requestSeq) return null; return result; } function schedule(text) { const token requestSeq; const cached cacheGet(text); if (cached) { renderBilingualBlock(text, cached.translation, cache); return; } const promise chooseEngine(text); promise.then((result) { const valid result token requestSeq; if (valid) { cacheSet(text, result); renderBilingualBlock(text, result, ai); } }); }这个调度器还负责超时控制。在线接口偶尔会因为网络波动卡住我给它套上了 AbortController超过 8 秒未返回就直接中断请求并渲染一条“翻译超时请稍后重试”的提示。总不能让用户为了一个翻译请求干等 20 秒。3.4 双语对照渲染Shadow DOM 隔离与两种展示模式渲染模块是用户看得见摸得着的部分直接决定这个工具的“长相”。我用 Shadow DOM 实现了样式隔离原因很简单宿主页面的 CSS 不可控有些网站会写* { box-sizing: border-box; }有些网站会全局设置p { line-height: 1.8 }如果不隔离翻译卡片的字体大小、间距、边框全都会被冲散甚至整个卡片形同虚设。Shadow DOM 的用法是给一个宿主元素挂载 shadowRoot然后在 shadowRoot 里创建内部节点。这样写的好处是页面主文档的 CSS 选择器选不中 shadowRoot 内部的元素样式彻底隔离我在里面想怎么写就怎么写。代价是宿主元素本身不能隐藏我一般把一个div.lingua-pair-hostappend 到页面上这个 div 初始化为position: fixed; width: 0; height: 0; overflow: hidden;只有真正渲染卡片时才把尺寸撑开。渲染上有两种展示模式我在设置页里让用户自己切。“浮动气泡”模式适合快速查词译文卡片浮在选区附近鼠标移开或按下 Esc 就消失。“段落内联”模式适合沉浸式阅读译文以“原文在上、译文在下”的对照块形式插入到选区行后面所有对照块会攒成一个阅读队列用户滚动页面时可以一目了然对照着读。内联模式的实现思路是这样// content.js function renderBilingualBlock(sourceText, translatedText, source) { const host document.createElement(div); host.className lingua-pair-host; const shadow host.attachShadow({ mode: open }); const card document.createElement(div); card.className lp-card; card.innerHTML div classlp-meta${source}/div div classlp-source${escapeHtml(sourceText)}/div div classlp-translation${escapeHtml(translatedText)}/div ; shadow.appendChild(card); const range savedRange.cloneRange(); range.collapse(false); // 选中区域末尾 range.insertNode(host); }range.collapse(false)表示把选区折叠到末尾然后把宿主节点插到那里。这样新卡片不会覆盖原文本而是出现在这段文字的结尾阅读顺序上不会打乱原文结构。渲染完成后我还要监听滚动事件如果卡片位置超出了视口就把整个对接卡片从 DOM 中移除保持页面干净也避免滚动时被遮挡。3.5 配置持久化与消息通信配置项我用 chrome.storage 来存这比 localStorage 多一个好处它可以跨扩展版本保留还能用 Chrome 账号同步到其他设备。设置项包括目标语言目前支持中文简体和中文繁体、默认引擎本地/在线/混合、对照模式浮动/内联、字号大小、是否显示原文。逻辑非常简单// popup.js const defaultSettings { targetLang: zh-Hans, engine: auto, mode: inline, fontSize: 14, showSource: true }; chrome.storage.sync.get(defaultSettings, (settings) { // 渲染设置界面 }); function saveSettings(next) { chrome.storage.sync.set(next, () { // 通知所有标签页的内容脚本更新配置 chrome.tabs.query({}, (tabs) { tabs.forEach((tab) { chrome.tabs.sendMessage(tab.id, { type: SETTINGS_UPDATED, payload: next }); }); }); }); }这里还有个小细节内容脚本在文档加载时读取一次配置并缓存在内存里。如果用户在设置页改了配置我除了存 storage 之外还要主动发消息给现有标签页让它们实时更新内存中的配置而不是等下次刷新页面才生效。消息通信我在后期统一封装成了一个小工具函数底层就是chrome.runtime.sendMessage加一个 Promise 包装返回结果统一解析。3.6 完整调用链路串联当所有模块都就绪之后一次典型请求的链路是这样的用户选中一段英文点击右键菜单里的“翻译选中文本到中文”。后台脚本接收菜单事件向当前标签页发送TRANSLATE_SELECTION消息。内容脚本从启动时保存的savedSelection中读取原文交给调度器。调度器先生成请求序号查缓存未命中后根据文本长度选择本地或在线引擎。本地引擎直接输出译文在线引擎由后台附加鉴权头后发起请求。响应回来后调度器检查序号写缓存调用渲染模块在选区末尾插入 Shadow DOM 隔离的对照卡片。用户读完按 Esc 或者点击关闭按钮卡片完整移除不留下任何 DOM 残留。整条链路走下来正常网络环境下从触发到首屏译文出现大约在 400ms 到 900ms 之间本地球命中场景可以压缩到 200ms 以内。4. 实测场景与效果评估4.1 测试场景设计为了不让自评流于主观我设计了一组覆盖不同场景的测试集每个场景都有明确的评价侧重。记录下来的对照表如下测试场景内容特征切换的引擎主观评分主要问题英文技术博客代码名词多句式较短本地4/5偶尔把 “race condition” 翻成“竞赛条件”英文论文摘要长难句密度高从句套从句混合本地超时切在线4.5/5在线接口能保住大体逻辑但术语仍有偏差日文漫画对话站口语省略多语气词密集本地3/5省略主语导致译文语义跳跃中英混排代码注释中英文混写有代码片段在线4/5代码块偶尔被误翻需要靠上下文过滤离线缓存的英文小说口语化叙事句子长本地4/5长句拆成短句后语序有时不够自然4.2 实测结果及反馈先说技术博客场景。整体感受是流畅度远超预期因为文本里大量“术语短句”的结构恰好是本地模型的舒适区。我重点观察了缓存命中率同一篇博客里会出现大量重复短语比如 “virtual DOM”、“dependency injection”第一次翻译后后续相同短语基本都是缓存直出体感接近零延迟。唯一让我不满意的点是术语翻译不够统一同一篇里 “race condition” 可能出现“竞态条件”和“竞赛条件”两种译法这在技术文档里是很致命的会让人误以为是在说两个不同的概念。论文摘要场景是对线器的考验。我特意挑了一段从句套从句的段子本地模型果然在 500ms 内没有返回调度器把它切到了在线接口。在线接口翻出的句子虽然也存在直译痕迹但至少逻辑主干没错能让我快速理解作者想表达什么。这个场景给了我一个重要启示混合模式下500ms 计时器的阈值非常关键定短了会导致很多本可以本地完成的句子白白浪费在线额度定长了又会让用户对“实时”失去信心。中英混排代码注释的场景是最让人头疼的。代码里的函数名、变量名、字符串字面量一旦被当作普通文本翻译轻则贴切错误重则让人完全看不懂。比如一行注释写着// TODO: use builder to create config理想译法是“使用 builder 创建配置”但如果模型不认识builder是个代码名词可能真的会把“builder”理解成建筑工人。针对这种问题我在后期加了一个“代码片段保护”规则在发给翻译引擎之前正则匹配出看起来像代码标识符的内容用占位符替换等译文返回后再替换回来。这套保护机制实测下来能把术语误翻率降低不少。4.3 网络环境与模型差异的影响测试过程中我还做了个实验把浏览器切到弱网模式模拟地铁里看文档的环境。纯本地模式几乎不受影响所有翻译请求都能在本地完成只是推理耗时比强网时略高。混合模式下如果本地模型没能在 500ms 内完成并发起在线请求而在线请求又迟迟不返回就会出现“先显示 loading10 秒后超时提示”的糟糕体验。为了解决这个问题我在超时提示里加了一行字“本地模型可直接返回建议切换引擎或检查网络”算是给用户一个可执行的下一步建议。机型差异方面本地模型在高性能笔记本和低配办公机上差别非常明显。低配机器上本地推理动辄超过 1.5 秒这时候混合调度会频繁切到在线接口流量和费用都会上升。我因此加了一个“管理员设置”用户可以手动设置本地模型的推理速度档位档位越高调度器越激进地使用本地模型档位越低越优先使用在线接口。这个设置项虽然技术含量不高但实际使用中非常管用。5. 踩坑记录与排查技巧速查5.1 选区丢失mousedown/mouseup 顺序坑在前面提到过右键菜单点击时直接读选区是读不到的。这个坑我花了很长时间才定位因为它在常规调试里并不容易暴露。平时我测试时都是先用鼠标选中文本然后立刻右键菜单弹出后点击菜单项一切正常。但真实用户的操作路径往往慢很多他们选中文本后会停顿、阅读一下再右键或者在选中后不小心点了页面空白处选区直接消失然后右键菜单点翻译插件拿到空字符串什么反应都没有。最终方案是双保险mousedown时保存选区文本这个是通用路径如果保存的选区为空再尝试在收到消息时重新调用window.getSelection()有些场景比如 iframe 内的文本前者捕获不到后者能补救。同时我把选区保存的逻辑从mouseup移到了mousedown因为mouseup后选区可能已经被页面自身的脚本清空了而mousedown时选区还处于完整状态。5.2 CSS 全局污染Shadow DOM 的边界Shadow DOM 确实解决了我自己的样式被页面影响的问题但反过来我也遇到了 Shadow DOM 内部的样式跟页面交互不协调的情况。第一版浮动卡片里有一个“复制译文”按钮点击按钮时我用的是navigator.clipboard.writeText。在 Shadow DOM 里clipboard 权限跟顶层文档是隔离的直接调用会报权限错误。更诡异的是如果页面自己绑定了一个全局点击监听器用户点击卡片按钮时事件会冒泡到页面文档顶层的监听器上触发一些不该出现的业务逻辑甚至把卡片外的内容也注册到手性。解决方案有两个一是将浮层卡片注册为一个“web component”监听事件时用composedPath()判断事件是否源自组件内部二是按钮的交互尽量走扩展内部消息在内容脚本的逻辑里完成剪贴板操作后再更新 DOM而不是让页面脚本介入。两套方案我都用了代码更稳了一些但这条经验也提醒我浏览器扩展与页面之间的边界不是绝对隔离的任何交互都要考虑“宿主页面会不会也在这件事上插手”。5.3 长段落实时翻译太慢分块渐进填充长段落翻译慢的问题在实践中非常好遇到。用户可能一次划了 3000 字符的文本在线接口处理完需要 4 到 5 秒如果这期间界面上只有一个转菊花用户很容易认为插件坏了。更好的交互是“渐进式结果”把长文本按句子边界拆成多个小块每个小块独立请求第一个小块返回后立刻渲染后续小块依次追加到卡片里。拆句的正则我换过好几版。最初用[.!?;]直接切分后来发现英文缩写词会被误切比如 “Dr.” 和 “e.g.” 被拆成了两个句子。最终我维护了一个常见缩写词列表在拆句时先对这些特殊 token 做保护再用正则切分。拆句算法大概是这样的// splitter.js function splitSentences(text) { const abbreviations new Set([Dr, Mr, Ms, Prof, e.g, i.e, etc, vs]); const protected new Map(); let counter 0; let s text.replace(/\b(Dr|Mr|Ms|Prof|e\.g|i\.e|etc|vs)\./g, (match) { const token __ABBR_${counter}__; protected.set(token, match.replace(., )); return token; }); const parts s.split(/(?[.!?;])\s/); return parts.map((part) { return part.replace(/__ABBR_(\d)__/g, (full, idx) protected.get(full) .); }); }渐进式渲染的卡片我还在标题栏加了一个“已加载 2/5 段”的进度提示让用户对剩余等待时间心里有数。5.4 请求风暴高频触发的降频策略另一个典型问题就是高频触发。有一类用户习惯是“选中一段看译文不满意再往前多选两个字重翻”一秒钟内可能触发三次翻译请求。如果不做降频翻译平台很快会返回限流错误。我做了两层降频一是按时间维度防抖300ms 内的重复请求只保留最后一个二是按距离维度过滤如果新选区的文本和上一个翻译文本的字符重合度超过 80%直接沿用上一个结果不重新请求。重合度判断用了一个非常简单的算法取两次文本的公共前缀长度除以较长文本的长度如果超过 80% 就判定为微调。这个算法没有 Levenshtein 距离那么精确但胜在计算开销极小在浏览器主线程里跑几千次也不会卡顿。我在实践中还有一条心得不要试图在内容脚本里处理所有边缘情况很多问题根本原因是页面自身的实现太诡异比如某些网站会对选中事件做 preventDefault导致插件完全感知不到选区。遇到这种情况最务实的做法是提供一条备选路径插件会在浏览器的右键菜单里增加第二个功能“翻译本页剩余文本”整页翻译虽然不符合“实时”的初衷但至少能让用户不至于完全无法使用。6. 后续扩展方向与个人实操体会6.1 可以继续做的几个方向LinguaPair 目前能覆盖的场景主要是网页阅读但“跨语言阅读”需求远远不止于此。后续我打算做这几个方向的扩展。第一是 PDF 阅读器内的适配。很多论文阅读是在 PDF 查看器里完成的Chromium 自带 PDF Viewer 也是网页形态理论上内容脚本能注入但那是一个比较特殊的 shadow 环境选区行为和普通网页不一致需要单独设计适配方案。我尝试了一版目前卡在选区坐标系换算上后续会继续做。第二是视频字幕的双语对照。现在看外语公开课、技术会议视频字幕要么只有中文要么只有英文能提供双语对照的平台很少。如果能把字幕文本从视频页面里读出来然后复用现有的翻译调度器和渲染机制做一个“字幕版双语对照卡”技术上完全可行而且会很实用。第三是术语表的导入。译者的经验告诉我们同一个词在不同领域有不同译法。我希望能支持用户导入自定义术语表比如 “DB”数据库默认译成“实例”还是“数据库管理系统”可以由用户自己定义。翻译引擎输出结果后再根据术语表做一次替换这样对专业阅读体验的提升会非常明显。6.2 实操中的几点主观体会项目做到后期我对“工具实用性”的理解发生了不小的变化。插件类工具最容易犯的错误是“功能堆叠”觉得自己做了一个很炫的划词翻译就一定要支持二十种语言、十种引擎、五种渲染模式。但真实使用中绝大多数人高频使用的路径只有一条对你这个工具来说就是“选中-出译文-对照阅读-关闭”。所有和这条主路径无关的功能都应该尽量藏起来或者默认关闭而不是摆在界面上抢占注意力。第二个体会是缓存是提升实时感最便宜的捷径。很多人一看到“实时翻译”就以为必须优化网络请求、升级模型但实际大部分缓存命中场景用户根本感知不到等待。LinguaPair 的缓存命中率在常规技术文章阅读场景里能到 30% 到 40%意味着三分之一的操作是瞬时响应的这种“快”是不用花钱买硬件、不用调模型就能拿到的优先级应该排在所有优化项前面。第三个体会是关于本地模型的。本地小模型虽然有时翻译质量不如在线大模型但它有一个在线模型无法替代的优点——完全离线可用。在高铁、地铁以及一切网络不稳的环境里能继续工作本身就是一种很强的实用价值。所以我的观点是混合架构的翻译插件可能是未来很长一段时间里最稳妥的形态两边互补而不是二选一。最后说一个小技巧。如果你也想做一个类似的划词翻译工具我强烈建议在最初版本里就加入“选区内容缓存到变量”这个动作哪怕前期用不到。很多浏览器扩展的选区处理坑在用户操作路径复杂起来之后才会暴露早点把选区快照、请求序号、缓存表这三个地基打牢后续加功能会顺滑很多。这个项目做到现在我最大的收获不是“终于能流畅读外文了”而是对浏览器页面上“看似简单的文本操作”背后到底有多少不可控因素有了非常具体的概念。希望这篇记录能帮你少走我走过的弯路。