每次按下 Ctrl+T 打开一个新的浏览器标签页时你是否也曾感到过一丝迷茫？面对着空白的页面或者是被各种资讯流占据的复杂界面原本清晰的思路往往会被瞬间打断。作为一名开发者，我渴望的不仅仅是一个网页，而是一个Neng够让我瞬间进入工作状态的生产力仪表盘。我想kan到今天的待办事项，想启动番茄钟，想回顾昨天的进度——就在我打开浏览器的第一秒。

正是这种对效率的极致追求，催生了 FocusTab。这不仅仅是一个简单的 Chrome 新标签页替换插件，geng是一个集成了任务管理、番茄工作法、日报周报自动生成的一站式工作站。今天我想抛开那些枯燥的文档，用Zui接地气的方式，聊聊这款插件从一行代码dou没有，到Zui终上架 Chrome Web Store 的完整心路历程。这里面有技术选型的纠结，有踩坑的痛苦，当然也有解决问题后的快感。

技术选型：在“极简”与“功Neng”之间走钢丝

在动工之前，我给自己定下了一个kan似苛刻的规矩：零框架，零依赖。

现在的 Web 开发，React、Vue 似乎成了标配。但对于一个 Chrome 来说引入这些庞然大物往往意味着需要配置复杂的构建工具链，还要处理 Content Security Policy 带来的各种限制。geng重要的是FocusTab 的核心逻辑并不复杂，原生 JavaScript 足以胜任。于是整个技术栈回归到了Zui原始的状态：纯 HTML + CSS + Vanilla JS，并基于Zui新的 Manifest V3 规范进行开发。

Zui终打包出来的代码量控制在了惊人的范围内，核心逻辑仅几百行，体积geng是压缩到了 KB 级别。这种轻量感，是任何框架dou无法比拟的。

项目结构一览

为了保持代码的清晰，我采用了模块化的目录结构。虽然dou在一个文件夹里但职责划分得相当明确：

FocusTab/
├── chrome-extension/           # 
程序的大本营
│   ├── manifest.json           # 身份证：Manifest V3 配置文件
│   ├── newtab.html             # 主战场：新标签页
│   ├── newtab.js               # 大脑：主界面逻辑
│   ├── popup.html              # 快捷入口：工具栏弹窗
│   ├── popup.js                # 弹窗逻辑
│   ├── background.js           # 幕后英雄：Service Worker
│   └── icons/                  # 门面：各种尺寸的图标
├── privacy-policy.html         # 必须的合规文件
├── chrome-store-assets/        # 商店展示用的宣传图
└── FocusTab-v1.0.zip           # Zui终上架的压缩包

核心功Neng实现：不仅仅是待办清单

FocusTab 的界面设计采用了当下流行的毛玻璃风格，视觉上通透且现代。但在这个漂亮的外表下藏着几个硬核的技术实现。

1. 番茄钟：状态机与 SVG 动画

番茄钟是 FocusTab 的心脏。为了实现流畅的计时体验，我没有使用现成的库，而是手写了一个简单的状态机。它包含三个核心状态：专注短休息和长休息。

整个流程就像一个精密的齿轮组：

┌─────────┐    完成     ┌──────────────┐    完成     ┌─────────┐
│  Focus  │ ────────>  │  Short Break │ ────────>  │  Focus  │
│  │            │        │            │  │
└─────────┘            └──────────────┘            └─────────┘
     │                                                  │
     │ 每 4 轮                                          │
     v                                                  v
┌──────────────┐                                        │
│  Long Break  │ ───────────────────────────────────────┘
│       │                      完成
└──────────────┘

为了直观展示进度，我用 SVG 绘制了一个圆环，并通过 JavaScript 动态计算 `stroke-dashoffset` 来实现倒计时的动画效果。这种实现方式比引入庞大的图表库要轻量得多，而且动画极其丝滑。用户Ke以在设置里自由调整时长，所有的状态变gengdou会实时反映在 UI 上。

2. 待办清单：原生拖拽的艺术

任务列表不仅要Neng增删改，还得Neng排序。hen多人第一反应是去用 Sortable.js 这样的库，但我觉得杀鸡焉用牛刀。HTML5 原生的 Drag and Drop API 其实非常强大，只要处理好 `dragstart`、`dragover` 和 `drop` 这几个事件，就Neng实现完美的拖拽体验。

这里有个小细节：在 `dragover` 事件中，我们需要实时计算鼠标位置，判断当前拖拽的元素应该插入到哪个兄弟节点之前。通过 `getBoundingClientRect` 获取坐标，再结合 `clientY` 进行比对，就Neng实现那种“跟随鼠标即时占位”的流畅感。代码写出来虽然有点繁琐，但完全不需要引入外部依赖，加载速度自然是快到飞起。

3. 数据存储：为什么我选择了 chrome.storage.local

hen多新手会习惯性地用 `localStorage`，但在 开发里这其实是个坑。`localStorage` 是基于域名的，而且在某些隐身模式下可Neng会受限。我Zui终选择了 `chrome.storage.local`，这是 Chrome 专门为 提供的存储 API。

它的好处显而易见：数据是同步的，而且Ke以在 Popup和 Background之间无缝共享。所有的任务数据、番茄钟设置、用户偏好，dou以 JSON 对象的形式存储在这里。即便用户关闭了浏览器，数据依然稳如泰山。

后台与通知：Service Worker 的那些坑

Manifest V3 Zui大的变化就是废弃了 Background Page，转而强制使用 Service Worker。这玩意儿虽然好，Neng省内存，但它有个让人头疼的脾气：它不常驻内存。

也就是说当你不需要它的时候，Chrome 会把它杀掉。这对于需要定时执行任务的场景来说简直是灾难。为了解决这个问题，我不得不请出 `chrome.alarms` API。

Service Worker 充当通知系统的指挥官，但它需要闹钟来叫醒它：

// 创建一个每分钟响一次的闹钟
chrome.alarms.create;
// 监听闹钟响铃
chrome.alarms.onAlarm.addListener => {
  if  return;
  const now = new Date;
  const settings = await chrome.storage.local.get;
  // 检查是不是该推日报了
  if ) {
    await sendDailyNotification;
  }
  // 检查是不是该推周报了
  if  === 0 && isTimeToNotify) {
    await sendWeeklyNotification;
  }
});

通过这种方式，即使 Service Worker 一直在“睡觉”，闹钟也Neng按时把它叫醒干活。通知内容会自动汇总当天的任务完成情况，支持中英文双语，让用户在每天结束时douNengkan到一份清晰的“成绩单”。

国际化与快捷键：细节决定成败

作为一个面向全球用户的工具，多语言支持是必须的。我没有使用 Chrome 自带的 `_locales` 目录方案，因为那种方案需要重启 才Neng生效，体验不够即时。我采用了一种geng“前端”的Zuo法：运行时字典替换。

我在 JS 文件头部定义了一个巨大的 `i18n` 对象，包含了中英文的所有文案：

const i18n = {
  zh: {
    greeting_morning: '早安',
    add_placeholder: '添加新任务...',
    // ... geng多文案
  },
  en: {
    greeting_morning: 'Good Morning',
    add_placeholder: 'Add a new task...',
    // ... more texts
  }
};

切换语言时脚本会遍历所有带有 `data-i18n` 属性的 DOM 元素，直接替换 `textContent`。这种方案的好处是切换即时生效，无需刷新页面用户体验非常顺滑。

此外为了方便重度用户，我还注册了全局快捷键。通过 `manifest.json` 中的 `commands` 字段，我绑定了 `Alt+T`。无论用户当前在浏览哪个网页，只要按下这组键，FocusTab 的 Popup 窗口就会立刻弹出，方便快速记录一闪而过的灵感。

上架之路：填坑与审核

代码写完了真正的挑战才刚刚开始——上架 Chrome Web Store。这过程绝对Neng称得上是“过五关斩六将”。

1. 注册费与隐私政策

你得有个开发者账号。这需要一次性支付 5 美元的注册费。别嫌贵，这是为了过滤掉一大批垃圾开发者。注册完后千万记得去验证你的联系邮箱，否则根本无法发布。

接下来是隐私政策。Chrome 现在对隐私抓得非常严，即使你的 不收集任何用户数据，也必须提供一个隐私政策页面的链接。我偷了个懒，直接写了个简单的 HTML，托管在 GitHub Pages 上。这样既免费又稳定，把链接填进商店后台就算完事。

2. 权限说明：寸土必争

Chrome 要求你对申请的每一个权限dou写出令人信服的理由。FocusTab 只申请了三个权限：`storage`、`alarms`、`notifications`。我特意在描述里强调：“没有使用 tabs、history 等敏感权限”。这不仅是为了安全，geng是为了过审。审核团队非常挑剔，Ru果你申请了不必要的权限，大概率会被直接打回。

3. 描述字数限制：精简的艺术

这里有个非常隐蔽的坑。`manifest.json` 里的 `description` 字段有严格的 132 字符上限。我一开始写了一大段介绍，结果上传时直接报错：

資訊清單中的 description 欄位過長 。這個欄位Yi超過 132 字元的上限。

没办法，我只Neng忍痛割爱，把描述精简到了极致：

New tab productivity dashboard with todo list, Pomodoro timer, daily/weekly reports, dark mode & bilingual support.

刚好 132 个字符，一个标点dou没浪费。

4. 截图：像素级的强迫症

商店要求的图片素材尺寸非常严格，尤其是 1280x800 的截图，必须是像素级精确。手动截图hen难保证尺寸完美对齐，而且容易有偏差。

我祭出了 Playwright 这个自动化测试工具来帮我截图。思路hen简单：写一个 HTML 文件还原 UI，然后用 Playwright 打开它，Zui后执行截图命令。这里有个大坑：deviceScaleFactor。Ru果你在 Mac 的 Retina 屏幕上跑，默认缩放比例可Neng是 2，生成的图片分辨率就会变成 2560x1600，直接导致上传失败。

必须在代码里强制设为 1：

const { chromium } = require;
 => {
  const browser = await chromium.launch;
  const context = await browser.newContext({
    viewport: { width: 1280, height: 800 },
    deviceScaleFactor: 1  // 必须设为 1，否则必挂
  });
  const page = await context.newPage;
  await page.goto;
  await page.screenshot;
  await browser.close;
});

5. 打包：目录结构的陷阱

Zui后一步是打包。Chrome 要求上传 `.zip` 文件，且 `manifest.json` 必须在根目录。hen多人习惯在项目根目录执行打包命令，结果压缩包里多了一层文件夹目录，导致审核被拒。

正确的姿势是先进入 目录再打包：

cd chrome-extension
zip -r ../FocusTab-v1.0.zip . -x "*.DS_Store"

千万别偷懒，这一步错了就得重新排队审核。

零依赖的胜利

从零开始，到Zui终上架，FocusTab 的开发过程虽然充满了各种琐碎的坑，但结果令人欣慰。它证明了回归本源依然是一种强大的选择。

没有 React 的虚拟 DOM，没有 Webpack 的热geng新，没有复杂的 CI/CD 流水线，有的只是Zui纯粹的 HTML、CSS 和 JavaScript。这不仅让代码变得极其轻量，也让维护变得异常简单。对于 Chrome 这种轻量级应用场景，我的建议依然是：不要过度工程化。

Ru果你也想尝试开发自己的 ，希望这篇实战记录Neng帮你避开那些我曾经踩过的坑。毕竟把时间花在创造价值上，而不是配置环境上，这才是我们作为开发者的初心。

---