划词翻译扩展怎么选：别先接一堆 API，先确定阅读场景
英文文档读到一半，真正烦的通常不是看不懂，而是不断复制、切换页面、粘贴、再回去定位。划词翻译扩展解决的就是这个中断。
不过 “翻译扩展” 不是一个统一功能。双语网页、划词弹窗、PDF、截图 OCR、视频字幕，背后用到的权限和服务都不一样。把所有开关都打开、塞进五六个 API，往往只会让故障更难排查。
先按阅读场景选功能
| 你的主要场景 | 该优先看什么 |
|---|---|
| GitHub、技术文档、新闻网页 | 双语网页与划词翻译 |
| 只偶尔查一句 | 划词弹窗和复制快捷键 |
| PDF 论文、扫描文档 | 浏览器 PDF 支持、OCR 能力 |
| 截图、图片里的文字 | 截图识别权限与 OCR 质量 |
| YouTube / Bilibili | 字幕翻译；先确认原视频有可用字幕 |
例如 FluentRead 宣称支持双语网页、划词 / 悬停翻译、图像与文档翻译、双语视频字幕；translate-browser-extension 的定位则是网页、PDF 和选中文字翻译。功能表可以做初筛，但真正该优先检查的是：它是否持续维护、权限请求是否合理、自己最常读的网站是否能正常工作。
划词翻译的工作方式，决定了它的边界
浏览器扩展一般通过 content script 读取当前页面的选中文字，调用翻译服务，再把结果显示成浮层。它可以很好地处理普通网页 DOM 文本，但有些东西天生没那么顺：
- Canvas 渲染、图片文字和扫描 PDF 需要 OCR，不是普通划词。
- 高度动态的单页应用会反复重绘 DOM，浮窗可能失效或位置漂移。
- DRM 视频和受保护内容可能不允许扩展读取字幕或画面。
- 公司内部页面、银行站点等敏感域名，不应该默认授予 “读取和更改网页数据” 的权限。
安装时先看扩展请求的是 “所有网站” 还是 “点击时才允许”。能设为按站点授权，就不要长期给全站权限。翻译的文本也会被发送给你选择的服务提供商，涉及内部代码、客户数据或账号信息时更要谨慎。
先只配一个服务，确认链路通了再加
首次配置建议只开启一个不需要自带 API Key 的引擎，测试三个动作：网页划词、复制结果、快捷键呼出。都正常以后，再考虑添加第二个服务用于交叉对照。
需要自填 API Key 的服务，建议单独创建一个限额账号：
- 给它设置低额度或消费告警。
- 不把 Key 粘到笔记、截图或同步到 Git 的配置文件中。
- 扩展不再使用后，删除或轮换该 Key。
- 如果扩展支持自定义 API Endpoint，确认 HTTPS 和服务域名正确。
AI 翻译适合需要解释语境、润色或术语统一的段落。查一个按钮、一行报错、一个变量名时，普通翻译引擎反而更快。不要让所有划词都发到付费模型。
一套够用的日常配置
- 双语网页：只在 GitHub、文档站和外语新闻站启用。
- 划词弹窗：设置为按快捷键或选中后点击图标触发，避免看文章时误弹。
- PDF：先拿一份可复制文字的 PDF 测试；扫描件再尝试 OCR。
- 视频：只对真有字幕的视频打开，别期待它从 DRM 流里直接抓内容。
- 截图翻译：设一个不会和系统或开发工具冲突的快捷键。
扩展配置的原则和服务器服务一样：一个基础链路稳定后，再加冗余，而不是一开始就堆功能。
没反应时，按层排查
| 现象 | 先检查 |
|---|---|
| 划词没有弹窗 | 扩展是否启用、当前站点是否已授权、触发模式是否是快捷键 |
| 翻译报网络或额度错误 | 切换到已知可用的基础引擎，核对 API Key 和配额 |
| PDF 选不中或结果为空 | PDF 是否实际有文本层；扫描件需要 OCR |
| 截图识别很差 | 框选更清晰的文字区域，避免低分辨率和复杂背景 |
| 视频字幕不能翻 | 原视频是否有字幕，站点是否允许扩展读取 |
| 某个网站布局乱掉 | 对该站禁用扩展，或只保留 “点击时启用” 权限 |
不要急着卸载重装。先在一个普通英文网页上验证扩展本身是否能工作，再定位是网站限制、PDF 类型、网络服务还是扩展配置出了问题。
翻译扩展的作用是减少切换，不是把所有内容无差别发给第三方。权限收紧一点、API 少配一点，才更接近一个能长期用的工具。
