浏览器开发入门：扩展、UserScript、DevTools 与 Web API 总目录
浏览器开发总目录：先分清 UserScript、浏览器扩展、DevTools 与 Web API 四条路的边界，再讲开发环境隔离、最小工作流与外壳/内核/引擎的术语，最后给出四篇正文的阅读顺序。
浏览器开发 · 图文教程
这一块专讲「站在浏览器这一侧做东西」：给网页加自己的功能、给浏览器加常驻能力、把页面为什么不对查清楚、以及让站点调用系统级别的能力。它和服务端的框架、数据库、后端语言没有关系，只用到浏览器自己就提供的东西。
最后更新：2026-10-04 · 全篇 8 节 · 覆盖 4 篇正文与 12 篇站内深读页
一、先确认你要解决的是哪一类问题
这四种做法的名字经常被混着用，但它们的入口、能力边界和交付方式完全不同。先对号入座，能省掉后面一大半返工。
1.1 我想给某个网站加自己的功能，但不想动它的代码
这是 UserScript（用户脚本）的活。它是一段 JavaScript，加上一段元数据注释，由浏览器里的脚本管理器在打开匹配的网页时注入执行。改的是「你本机看到的页面」，网站服务器上什么都没有变，也不会影响别人的访问。适合：去掉某个网站的弹窗、给页面补一个按钮、批量导出列表、把外文站点的排版改顺眼。
1.2 我想要常驻的工具栏按钮、想拦截或改写网络请求
这是浏览器扩展（extension）的活。扩展有独立于网页的界面（工具栏图标、弹出面板、选项页、开发者工具面板），能申请比脚本更高的权限，也能在页面加载前就介入。当前的扩展平台是 Manifest V3：清单文件里写 "manifest_version": 3，后台从常驻页面改成了 Service Worker，网络请求的拦截也从阻塞式 webRequest 换成了声明式的规则接口。细节见 浏览器扩展开发入门。
1.3 页面效果不对，我要先查清楚原因
这是开发者工具（DevTools）的活，也是上面两件事的必备前置。它不需要你先写代码，只需要会看：DOM 树、控制台报错、网络请求、断点、性能录制。见 浏览器 DevTools 调试。
1.4 我想让网页用摄像头、剪贴板、离线缓存这类系统能力
这是 Web API 的活。浏览器把设备能力包装成 JavaScript 接口，网页调用前通常要经过一次用户授权，并且越来越多接口要求页面跑在 HTTPS 下（安全上下文）。哪些接口在哪些浏览器上可用，是这块最常踩的坑。见 Web API 与浏览器兼容性检测。
1.5 我要让老浏览器用户看到一个升级提示
这属于「兼容性检测」这一小类，做法有新旧两代：老办法读 navigator.userAgent 判断浏览器型号和版本，新办法不认浏览器、只认「这个能力在不在」。两代做法各有适用场景，也各有坑，一并写在 Web API 与浏览器兼容性检测 里。
1.6 我只想改改样式，不想写逻辑
改样式同样是 UserScript 的活：在元数据里声明目标站点，脚本里注入一段 CSS，或者直接改元素的类名。它和「写逻辑」的脚本没有区别，只是内容更短。判断标准只有一条：改动只发生在你这台机器上、只发生在你打开的那个页面里。
二、四种做法的能力边界对照
同一件事往往有多种做法。下表把四条路放在一起，按「能不能做」而不是「哪个更高级」来排。
| 能力 | UserScript | 浏览器扩展 | DevTools | Web API（网页自己用） |
|---|---|---|---|---|
| 改当前页面的 DOM 与样式 | 可以 | 可以（内容脚本） | 可以，但只在你这台机器上临时生效 | 可以，但只能改自己的页面 |
| 加工具栏按钮 / 弹出面板 | 不能 | 可以 | 不能 | 不能 |
| 在页面脚本运行前介入 | 可以（把运行时机提前到文档开始阶段） | 可以，且时机更可控 | 可以，用于观察 | 不适用 |
| 拦截或改写网络请求 | 有限（一般只能改自己发的请求） | 可以，Manifest V3 用声明式规则 | 只能看和限速，不能长期改 | 可以，用 Service Worker 代理自己站点的请求 |
| 分发给别人用 | 发一个 .user.js 文件或链接 | 要打包、要过商店审核，或让别人手动加载 | 不适用 | 随网站一起发布 |
| 上架商店后自动更新 | 取决于脚本管理器 | 可以 | 不适用 | 不适用 |
2.1 最常见的选择错误：拿扩展做脚本的事
只为了改一个网站的一处显示，却去写一个完整扩展，代价是多出一套清单、图标、打包和审核流程。反过来，用脚本去做「常驻工具栏 + 跨站规则拦截」，能力又不够。判断口径很简单：有没有独立于网页的界面、要不要在页面之外常驻、要不要改请求——三个里有一个是「要」，就该用扩展。
2.2 权限是成本，不是功能
扩展在清单里申请的每一项权限，都会在安装时被列出来给用户看。host_permissions 里写得越宽（例如匹配所有站点），用户看到的提示越刺眼，被拒绝的概率也越高。先写最小范围，等确实需要再放宽——这一点在 Manifest V3 里尤其重要，因为主机权限已经和其它权限分成了两个字段。
2.3 别把「能跑」当成「能维护」
网页会改版。任何依赖具体 DOM 结构、具体类名或具体接口返回格式的脚本，都会在某次改版后失效。写的时候给关键选择器留一句注释、给失败分支留一条控制台输出，比追求一次写全更划算。
三、开发环境：先给自己一个可以弄坏的浏览器
这一节是给所有四条路通用的。开发期的扩展和脚本经常把浏览器搞到打不开页面，所以第一件事不是写代码，是隔离。
3.1 为什么不要在日常主配置上开发
日常主配置里有你的书签、密码、登录态和几十个扩展。一旦新扩展在启动阶段抛错，或者内容脚本把某个网站改坏，你分不清是「网站的问题」还是「自己的问题」。更麻烦的是排查过程中要反复开关扩展、清缓存、清站点数据，这些动作会直接作用在你的真实数据上。
3.2 三种隔离做法，按成本从低到高
第一种：同一个浏览器里新建一个用户配置（Chrome 叫「个人资料」，Firefox 叫「配置文件」），把开发期的扩展只装在这个配置里；第二种：用无痕/隐私窗口做临时验证，但要注意无痕窗口默认不加载扩展，各家策略不同；第三种：干脆用另一个浏览器或另一个浏览器版本专门做开发。三者的共同点是「主配置永远保持干净」。
3.3 弄坏了怎么一键回到干净状态
如果已经把主配置弄坏了，按这个顺序处理：先在扩展管理页把所有开发期扩展停用（不是卸载），再看页面是否恢复；仍然不正常，就用「无痕窗口打开同一页面」对比一次——无痕下正常、普通窗口不正常，基本可以确定是扩展或缓存的问题，而不是网站的问题。清缓存和清 Cookie 的具体入口见 怎么清理浏览器缓存 与 怎么清理 Cookie。
3.4 开发期要养成的两个小习惯
一是随时保留一个「能打开的普通网页」作为对照组，出问题时先对比；二是每次改动只改一件事，改完立刻刷新验证——浏览器开发没有编译期检查，靠的是小步快跑。
四、最小可用工作流
下面四条闭环都短，但顺序不能省。跳过最后一步自查，是绝大多数「在别人机器上不好使」的原因。
| 路线 | 第一步 | 第二步 | 第三步 |
|---|---|---|---|
| UserScript | 写元数据块，声明目标站点与运行时机 | 在脚本管理器里新建并保存，打开目标页验证 | 确认在页面刷新、跨页跳转、iframe 里的表现 |
| 扩展 | 写清单文件与最小脚本，加载已解压的扩展 | 打开扩展的后台调试页看报错 | 收紧权限、补图标与说明，再考虑打包 |
| 调试 | 先看控制台有没有报错，再看网络请求是否成功 | 在出问题的代码位置下断点，逐行看变量 | 用性能面板确认是不是卡在渲染或脚本上 |
| Web API | 先做能力检测，缺能力就走降级分支 | 确认页面处在安全上下文（HTTPS 或本机） | 处理用户拒绝授权的分支，别只写成功路径 |
4.1 每一步都要有「我看到了什么」
新手最常见的卡点是「点了没反应」。把「没反应」拆成可观察的信号：请求发出去了吗（网络面板）、代码执行到了吗（断点）、变量是什么值（控制台）。三者中至少有一个会给你线索，剩下两个用来排除猜测。
4.2 用站内工具做两件杂事
开发过程里有两类小活不必装软件：一是格式化与校验 JSON，用 JSON 格式化工具；二是构造假数据联调，用 Mock 数据生成。这两件都在浏览器本机跑，内容不出本机。
4.3 上线前必查的四条
一、把权限收到最小；二、在所有分支上都打日志，但发布前把日志降到只在出错时输出；三、确认在无痕窗口和全新用户配置下也能跑；四、写一份「这个脚本/扩展在什么情况下会失效」的说明。第四条尤其重要，因为网页改版是必然事件，不是意外。
五、术语表：别把外壳、内核、引擎混着说
这块的名词混乱度很高，先把三层分清楚，再看代码就顺了。
5.1 四层结构
最外层是浏览器外壳（界面、书签、设置、账号同步）；往里是内核（把 HTML、CSS、JavaScript 跑起来的那一整套实现）；内核里通常再分成渲染引擎（负责排版和绘制）和 JavaScript 引擎（负责执行脚本）。「内核」是习惯叫法，它不是一个官方标准名词。内核是什么、为什么国内很多浏览器用的是同一套内核，见 浏览器内核是什么。
5.2 Chromium 系与非 Chromium 系，差别落在哪
差别首先落在扩展接口上：Chromium 系用 chrome.* 命名空间，Firefox 同时提供 browser.*（并支持 Promise 风格）。其次落在Web API 的覆盖速度上：新接口往往先在 Chromium 系出现，其它内核跟进有时间差。这就是为什么「能力检测」比「认浏览器名字」更可靠。
5.3 双核浏览器的那点事
国内不少浏览器标称「双核」，指的是内置两套内核，遇到老站点自动切到兼容内核。对开发者的影响是：同一台机器上可能出现两套渲染结果。写脚本时不要假设「只有一种内核」。相关选型见 双核浏览器怎么选。
六、这条线怎么往下走
6.1 四篇正文的阅读顺序
建议顺序：DevTools 调试 → UserScript 用户脚本 → 浏览器扩展开发 → Web API 与兼容性检测。先把「能看见」练熟，再学「能改动」；先做轻的（脚本），再做重的（扩展）；最后回到网页自身，看它怎么用浏览器提供的能力。
6.2 配套的站内入口
已装扩展的排查与推荐看 Chrome 扩展管理与权限、扩展怎么挑；日常效率相关的看 开发者工具日常用法 与 浏览器快捷键大全；想知道自己当前这台机器的浏览器信息，用 浏览器信息检测 和 User-Agent 查询。
七、常见问题
UserScript 和浏览器扩展到底该选哪个？
看要不要「离开网页还存在」。只需要在特定网页里改点东西，选 UserScript；需要工具栏按钮、弹出面板、跨站规则、改网络请求，选扩展。扩展的能力更强，代价是要打包、要处理权限与更新。
学这块需要先会写后端吗？
不需要。这一块只用到 HTML、CSS、JavaScript 和浏览器自己的接口。只有当你需要把数据存到服务器、或者要调第三方接口时，才会碰到服务端的事情，而那部分和浏览器开发是两件事。
为什么我的脚本在控制台里能跑，装成脚本管理器里的脚本就不行？
最常见的两个原因：一是运行时机不对，页面元素还没生成脚本就执行完了，需要把运行时机往后放；二是脚本运行在隔离环境里，拿不到页面自身的变量。先在脚本里加一行输出确认它到底有没有被执行。
Manifest V3 之后，原来的扩展是不是都不能用了？
不是「都不能用」，而是「按旧清单写的扩展需要迁移」。主要改动集中在三处：清单版本号、后台页改成 Service Worker、网络请求拦截改成声明式规则。纯内容脚本类的扩展迁移量通常不大。
为什么开发时要专门开一个干净的用户配置？
为了把变量降到最少。主配置里有几十个扩展和大量缓存，出问题时无法判断是谁造成的。用一个干净配置，装上你自己的东西就能复现，问题范围一下就缩到最小。
在这块内容里，会不会碰到「改别人网站」的合规问题？
这一段只能给方向，不给法律结论。技术上的事实是：UserScript 和扩展都只在你自己这台机器上生效，不改变网站服务器上的内容，也不影响其他访问者；但如果你把它分发给别人、或者绕过网站本身的访问控制，性质就变了。涉及具体场景请自行确认适用条款。
手机上能做这些吗？
手机上装扩展和脚本的限制比桌面多，各家差别很大，具体支持情况以你手上那款浏览器的官方说明为准。桌面端是这套内容的主场，建议先在桌面上把流程走通。
这块内容和「浏览器怎么用」有什么区别？
「怎么用」讲的是设置、书签、快捷键、隐私选项；这块讲的是拿浏览器当运行环境来写东西。两者共用同一套基础知识，但目标不同：一个是用好它，一个是改造它。
八、接下来做什么
- 浏览器 DevTools 调试：面板、断点与网络分析——先学会看，再学会改。
- UserScript 用户脚本入门——最短的一条路，一个文件就能跑。
- 浏览器扩展开发入门——要做常驻界面和请求拦截时的正路。
- Web API 与浏览器兼容性检测——网页自己能用哪些系统能力。
- 开发者工具的日常用法——不写代码也能用上的那些功能。