Chrome扩展程序本质上就是扩展一堆放在文件夹里的HTML、CSS和JavaScript文件，程序加上一个叫manifest.json的扩展配置文件，打包成.crx或直接以开发者模式加载。程序浏览器启动时读取这个清单，扩展知道你要注入哪些脚本、程序申请哪些权限、扩展在哪些页面上生效。程序就这么简单。扩展没有魔法，程序也没有复杂的扩展编译流程，一个能用的程序扩展可能只有几十行代码。

我写过最实用的扩展一个扩展，功能是程序自动关闭所有重复标签页。代码不到四十行——监听标签更新事件，扩展遍历所有窗口的标签，用URL做键去重，关掉多余的。全程没碰任何框架，纯原生API。Chrome提供的chrome.tabs、chrome.storage、chrome.runtime这几个模块，覆盖了八成日常需求。很多人一上来就找React模板、Webpack配置，其实没必要。一个manifest.json加一个background.js就能跑起来。

manifest.json的版本差异是个坑。V2和V3的写法差别不小。V2允许background页面常驻，V3改成了Service Worker，没有DOM访问权，也不能用XMLHttpRequest。我有个旧扩展用V2写的，2023年之后Chrome开始逐步禁用，只能重写。迁移时最麻烦的是权限声明——V3把host_permissions单独拆出来，之前混在permissions里的写法会直接报错。谷歌的文档写得很全，但示例代码更新不及时，经常要翻GitHub issue才能找到正确写法。

内容脚本（content script）是另一个容易踩坑的地方。它运行在网页的上下文中，但和页面本身的JavaScript是隔离的。你想修改页面上的某个变量，直接赋值不行，得通过注入script标签或者用window.postMessage来通信。我做过一个批量下载图片的扩展，一开始想直接调用页面里的懒加载函数，折腾半天才发现隔离机制。后来改成用chrome.scripting.executeScript注入一段代码，才拿到真实的图片地址。

调试倒是方便。background脚本在扩展管理页点“Service Worker”就能打开DevTools，内容脚本直接右键审查对应页面元素就行。唯一麻烦的是Service Worker会休眠，状态得存到chrome.storage里，不能依赖全局变量。我见过有人把登录token放在内存变量里，结果过几分钟扩展就失效了，查半天才反应过来是Worker被回收了。

分发渠道就两个：Chrome Web Store或者自己打包给别人加载。上架要交5美元注册费，审核周期从几小时到几周不等。我提交过一个修改百度搜索结果的扩展，被拒了两次，理由是“影响其他网站正常功能”。后来把功能改成只在特定域名下生效，才通过。自己分发的话，用户得开开发者模式拖文件夹进去，每次重启浏览器还会弹警告。适合内部工具，不适合普通用户。

性能方面，别在内容脚本里做重计算。我见过一个扩展在document_start阶段同步遍历所有DOM节点，页面直接卡死两秒。改成requestIdleCallback分批处理，或者干脆放到background里用OffscreenCanvas算，体验就好很多。内存占用也要留意，每个标签页都会跑一份内容脚本，开二十个标签就是二十份实例。用事件委托代替逐个绑定，能省不少资源。

最后说个观察：很多扩展其实用书签脚本（bookmarklet）就能替代。比如一键提取页面所有链接、修改字体大小这类操作，写个javascript:开头的书签更轻量，不用装任何东西。扩展的优势在于能跨页面持久运行、能访问chrome.* API、能后台静默工作。想清楚需求再动手，别为了写扩展而写扩展。