最近在备考雅思，用pc上网页端的扇贝单词来背单词。因为电脑屏幕大，比手机平板看起来都舒服。
遇到不会的单词，我喜欢在谷歌图片上搜索一下，将其带入真实的英语环境中去辅助记忆。如果看到一个单词，可以在脑海中直接联系到具体的事物——————建立这种联系，无论是在记忆效率，还是学习乐趣上，都会提升很多。
可是，频繁的切换标签页，输入单词，搜索，再切回来，再切回去，再删除，再输入，再搜索，十分低效繁琐。
因此，我做了这样一个插件。
正常进入界面（首次使用单击扩展栏小图标后出现使用指导）
按下热键后（此界面几乎不可见，因为速度很快）
正常显示
没有任何折叠
F12控制台提示：
竞品
逻辑：双击单词，调用剑桥词典，弹窗。
优势：使用环境广泛，可在任何网页使用
缺陷：遮挡视线，无法自动提取当前单词。图片老旧，缺乏实际生活气息
用户痛点
- 背单词时需要切换标签页搜索图片，学习流程被打断
- 纯文字记忆效率低，缺少视觉辅助
- 手动搜索图片耗时，影响学习节奏
产品目标
- 零干扰学习：在现有学习页面内直接查看图片，无需切换页面
- 极速响应：一键触发，毫秒级获取相关图片
- 精准匹配：自动识别当前学习的单词，无需手动输入帮助用户在扇贝单词背单词时快速查看单词对应的图片。---
技术架构设计
整体架构
┌─────────────────────────────────────────────┐
│ Chrome 扩展架构 │
├─────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Background │◄────►│ Content │ │
│ │ Service │ │ Script │ │
│ │ Worker │ │ │ │
│ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────────────────────────┐ │
│ │ Google Custom Search API │ │
│ │ (图片搜索服务) │ │
│ └─────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────┘
核心组件说明
1. Manifest V3 配置
- 为什么选择 V3：Google 官方推荐的最新标准，更好的性能和安全性
- 权限模型：采用最小权限原则，仅请求必要的域名访问权限
2. Background Service Worker
- 职责：处理热键命令、调用 Google API、管理扩展生命周期
- 为什么用 Service Worker：相比传统的 background page，资源占用更少，响应更快
3. Content Script
- 职责：注入到网页中，识别单词、渲染图片展示界面
- 运行时机：
document_idle，确保不干扰页面加载性能
🛠️ 技术栈详解
前端技术栈
| 技术 | 版本/标准 | 使用场景 | 选择理由 |
|---|---|---|---|
| Manifest V3 | 最新标准 | 扩展配置 | 官方推荐，更好的安全性和性能 |
| JavaScript ES6+ | ES2020 | 核心逻辑 | 原生支持，无需构建工具，降低复杂度 |
| Chrome Extension API | 官方 API | 扩展通信 | 官方支持，稳定可靠 |
| CSS3 | 现代标准 | UI 样式 | 原生支持，性能优秀 |
后端服务
| 服务 | 用途 | 为什么选择 |
|---|---|---|
| Google Custom Search API | 图片搜索 | 官方 API，搜索结果质量高，有免费额度 |
| Unsplash (备用) | 备用图片源 | 免费、高质量、API 友好 |
关键技术点
1. 热键监听机制
实现方式：
- 使用
chrome.commandsAPI 注册全局热键 - 热键：
Ctrl+Shift+I(Windows/Linux) /Cmd+Shift+I(Mac)
产品考量：
- 全局热键 vs 页面内热键：全局热键用户体验更好，无需聚焦到页面
- 快捷键选择：选择不常用的组合键，避免与浏览器默认快捷键冲突
2. 单词识别算法
挑战：
- 扇贝单词的 DOM 结构可能变化
- 页面中可能有多个英文单词，需要识别当前学习的单词
解决方案：
- 使用多重选择器策略（10+ 种常见选择器）
- 降级策略：如果选择器匹配失败，从页面文本中提取最明显的单词
- 正则过滤：确保提取的是有效的英文单词（3-20 个字符）
代码示例：
const selectors = [
'.word-text', // 常见选择器
'.word', // 通用类名
'.vocabulary-word',// 特定场景
// ... 更多降级策略
];
3. Google Custom Search API 集成
为什么不用直接抓取：
- Google 有反爬虫机制，直接抓取 HTML 不稳定
- 解析 HTML 容易因页面结构变化而失效
- API 方式更稳定，返回 JSON 数据更易处理
API 调用流程：
用户触发 → Background Script → Google API → 返回 JSON → 提取图片 URL → Content Script → 渲染
关键参数：
searchType=image：只搜索图片num=10：获取 10 张图片，选择最相关的 6 张展示safe=active：安全搜索，过滤不当内容
4. 跨域图片加载策略
挑战：
- 不同网站的图片可能有 CORS 限制
- 某些图片服务器需要特定的 Referer
- 图片加载失败会影响用户体验
解决方案：
- 不设置
crossOrigin属性，让浏览器默认方式加载 - 设置
referrerPolicy为no-referrer-when-downgrade - 实现优雅降级：加载失败时显示占位符，不影响其他图片
优化点：
- 移除
loading='lazy'：避免延迟加载导致的显示问题 - 添加加载动画：提升用户等待体验
- 超时检测：8 秒超时，避免无限等待
用户体验设计
UI/UX 设计原则
1. 极简主义
- 去除蓝紫色渐变（避免 AI 感过强）
- 采用灰白色调，更专业、更低调
- 浮动窗口设计，不遮挡学习内容
2. 性能优化
- 图片懒加载：初始只加载网格结构
- 异步解码：
decoding='async'提升渲染性能 - 智能显示：至少一张图片加载成功即隐藏加载提示
3. 错误处理
- 友好的错误提示
- 加载失败时显示半透明占位符，而非完全隐藏
- 失败图片显示 ✕ 图标，明确状态
交互流程
用户按下 Ctrl+Shift+I
↓
识别当前单词（<100ms）
↓
调用 Google API（500-1000ms）
↓
提取图片 URL（<10ms）
↓
开始加载图片（异步，多张并行）
↓
第一张图片加载成功 → 隐藏加载提示
↓
其他图片持续加载（2-5秒）
总响应时间： < 1.5 秒即可看到第一张图片
🔧 核心技术挑战与解决方案
挑战 1：Extension Context Invalidated
问题：
- 扩展重新加载后，旧的 content script 尝试与已失效的 background script 通信
- 导致
Extension context invalidated错误
解决方案：
- 实现扩展上下文有效性检查
- 在消息发送前验证
chrome.runtime.id是否有效 - 提供友好的错误提示和刷新页面按钮
挑战 2：Service Worker 限制
问题：
- Service Worker 不支持
XMLHttpRequest - 某些自定义 headers 可能不被支持
- 生命周期管理复杂
解决方案：
- 仅使用
fetchAPI - 简化请求配置，不设置过多自定义 headers
- 实现完善的错误处理和降级策略
挑战 3：图片加载失败
问题：
- 某些图片 URL 可能有 CORS 限制
- 图片服务器可能拒绝跨域请求
- 部分图片 URL 可能失效
解决方案：
- 多重加载策略：直接加载 + referrerPolicy 优化
- 失败降级：加载失败时显示占位符，不影响其他图片
- 统计成功率：至少一张成功即认为可用
挑战 4：Google API 配额限制
问题：
- Google Custom Search API 免费额度：100 次/天
- 超出后需要付费或等待重置
解决方案：
- 实现备用图片源（Unsplash）
- 优化 API 调用：一次调用获取多张图片
- 缓存机制（可选）：相同单词不重复调用
性能指标
关键指标
| 指标 | 目标值 | 实际表现 |
|---|---|---|
| 首张图片显示时间 | < 2s | ~1.5s |
| API 响应时间 | < 1s | ~800ms |
| 单词识别准确率 | > 90% | ~95% |
| 图片加载成功率 | > 70% | ~80% |
资源占用
- 扩展体积： < 50KB（未压缩）
- 内存占用： ~5MB（运行时）
- CPU 占用： 几乎为 0（仅在触发时）
未来优化方向
短期优化
-
缓存机制
- 本地缓存常用单词的图片 URL
- 减少 API 调用，提升响应速度
-
图片预加载
- 识别到单词后，后台预加载下一张可能出现的单词图片
- 进一步降低用户等待时间
-
多图片源支持
- 集成 Bing Image Search API
- 自动切换最佳图片源
长期规划
-
AI 图片筛选
- 使用机器学习模型筛选最相关的图片
- 提升图片质量和相关性
-
用户个性化
- 记录用户偏好，调整图片展示风格
- 支持自定义图片数量、尺寸等
-
跨平台支持
- Firefox 扩展版本
- Edge 扩展版本
产品与技术思考
技术选型的权衡
为什么选择 Chrome Extension 而不是：
- Web App：无法全局热键，无法直接注入到第三方网站
- 桌面应用：开发成本高，需要额外安装，用户门槛高
- 浏览器插件（非扩展） ：功能受限，无法访问外部 API
为什么选择 Google Custom Search API：
- 相比直接抓取：更稳定，不易因页面变化失效
- 相比其他图片 API：如百度，搜狗等国内引擎，搜索结果质量更高，相关性更好
- 成本考量：免费额度（100次/天）对个人用户足够
