调试前端页面的时候，最烦的就是跟 URL 参数打交道。参数一多，地址栏里挤成一长串，眼睛根本分不清哪个值对应哪个键；想临时改个参数验证一下某个状态，手动改地址栏又容易手滑弄错编码；遇到接口报错，想确认是参数格式问题还是服务端问题，还得复制 URL 出去解码，来回折腾。我在项目里做了个 URL Query Editor 的浏览器扩展工具，专门解决这一串麻烦。核心就是把 URL 里的查询参数解析成可视化表格，支持直接编辑、搜索、批量替换、历史记录，甚至能保存常用参数模板。调试效率提升非常明显，尤其是面对复杂页面的场景。这篇就把这个工具的完整设计思路、核心实现、实战流程和踩过的坑一次讲清楚，适合前端开发、测试以及所有经常跟 URL 参数打交道的人参考。
1. 为什么纠结 URL 参数调试，以及方案选型背后的思路
先说一个真实场景。某次排查一个电商活动页面，地址栏里的 query 参数加起来接近一百个字符，里面既有渠道标识、页面来源、用户分级，还有若干埋点用的随机字段。光靠肉眼根本看不出某一个参数的当前值到底是什么，更别提高亮差异了。而接口联调的时候，后端随口说 “你把 rid 这个参数的值改一下再发一次请求”，我第一反应就是找 rid 在哪，在那一长串字符里去辨认，脑袋都是晕的。
1.1 URL 参数调试的真实痛感
往细了拆，日常调试 URL 参数有四个绕不开的痛点：
第一是可视性差。原生地址栏就是一串连续文本，没有格式化，没有颜色区分，参数边界只能靠&符号脑补。当参数值本身带有中文、空格、特殊符号时，会变成%E4%B8%AD%E6%96%87这种百分号编码，更没法读。
第二是编辑成本高。改参数全靠手动定位光标，准确度低。参数多的时候，一不小心就把a=1删成了a1，改完很难发现。遇到值需要整体替换时，还得小心的选中正确的值片段，效率极低。
第三是编码规则复杂。同一个 URL 里，路径段、查询键、查询值、hash 片段的编码规则并不完全一样。比如查询参数值里的空格可以编码成%20也可以+，而路径中的空格一般只认%20。手动改的时候，很容易因为编码方式不对导致后端解析出不同的字符。
第四是历史状态追溯难。改来改去之后，经常会忘记最初的参数到底是什么样，也没有办法对比参数集合的差异。页面一刷新，参数丢了，之前辛苦构造的状态全部消失。
用工具解决之前，我先想过三种替代方案：直接改地址栏、写书签脚本来解析、做一个浏览器扩展。直接改地址栏并不满足需求，因为可视化和纠错能力为零。写书签脚本能实现解析，但书签栏执行脚本的环境受限，不能常驻页面，也没法监听地址栏变化之后实时更新。最终选了浏览器扩展里注入一个小型开发者工具面板的方案。
1.2 方案选型：为什么采用扩展而不是改业务代码
很多团队会在项目里加一个全局的query api调试面板，或者干脆把参数直接打印到控制台。用业务代码做调试工具的致命问题在于：生产环境必须删掉，而调试环境又容易忘删。更重要的是，这是对业务代码的一种侵入，改版、发布、回归都带着风险。
用浏览器扩展实现的好处有三点：第一，完全不侵入业务代码，页面上感知不到你装了什么工具，所有逻辑跑在扩展的 content script 和 page 面板中；第二，工具和环境隔离，本地、测试、生产环境统一使用同一套调试体验，不因页面部署环境出现差异；第三，分发方便，团队成员在扩展管理页加载解压包就能用，无需改动各自的工程配置。
设计上还有一个关键决定：参数可视化编辑不做成悬浮窗，而是做成一个独立展开的侧边面板或者底部抽屉。原因很实际，悬浮窗容易遮挡页面内容，特别是你在调试响应式布局的时候，一个悬浮球卡在右下角特别碍事。抽屉式的面板可以在代码调试时打开，调完一键收起，视觉空间互不干扰。
2. 核心功能拆解：可视化表格、原地编辑、智能编码与历史判重
一个工具好不好用，不在于功能多有创意，而在于是否精准命中了使用频率最高的那几个操作。URL Query Editor 最终锁定在五个核心功能上：参数解析成表、单元格级编辑、智能转义、搜索过滤、以及快照历史。五个功能互相咬合，构成完整的参数调试闭环。
2.1 参数解析成表：键、值、来源一屏看全
URL 查询参数并不是格式化数据，它只是一个原始字符串。解析成可视化表格之前，我先做了两个层级的拆分：第一层按&拆分出 key=value 对，第二层做=和多个=的情况判定。比如a=1=2这种边界情况，标准查询字符串解析库会直接把1=2当成值，我就沿着这个思路处理，取值保留原始串，不强制 split 掉多余等号。
表格的列不止“键”和“值”两列，还加了“是否被 urlencoded 编码”“字节长度”“编码前预览”“来源”四个辅助列。“是否被 urlencoded 编码”非常重要，因为很多参数默认不带编码，比如纯数字、英文字母和部分符号。每一次刷新参数列表，我都会自动检测每个值是否包含%和十六进制序列，如果有就认为是已编码状态，并在表格里标记一个浅色高亮。
“来源”列则是为了区分参数是地址栏原生携带的，还是工具内部通过历史模板恢复出来的。这个信息在用户误操作时极有价值，可以直接一键回滚。
2.2 单元格级编辑：改动即所见，失焦即生效
表格里的每个单元格都应该能直接编辑。双击某个参数的“值”单元格，就进入输入态；输入时，右侧同步展示编码后的结果，并且地址栏会实时更新，同时使用history.replaceState方法改变地址栏显示，不触发浏览器跳转。这一设计为什么关键？因为地址栏本身就是这个工具的数据源，也是调试者最终想要维护的对象，所以所有编辑都应以地址栏为终点，立即反向同步。
不过这里有一个必须处理好的细节：history.replaceState改变了地址栏显示的 URL，但不会触发popstate事件，因此不会产生页面刷新。如果页面本身监听了hashchange或popstate，是不会感知到这类变化的，页面内部状态下一次初始化时才会用到新参数。这个特性我专门做了开关，默认开启实时同步。如果你只想改参数但不想让页面有任何感知，可以切到一个“仅编辑，不写回地址栏”的模式，所有改动都在面板内部积累，最后手动点一次“应用”按钮才写回。
2.3 智能转义与编码处理：不同位置规则不同
编码处理是整个工具里最容易写错、也最值得展开说明的部分。URL 中的字符分为三类：保留字、非保留字、其他字符。保留字比如:/?#[]@，在特定位置具有语法含义，一般不能直接使用，需要转义；非保留字包括大小写字母、数字和-_.~，可以直接用；其余字符比如中文、空格、引号，需要encodeURIComponent或者encodeURI。
不同位置的编码规则有差异，我把它们整理成一张对照表：
| URL 位置 | 编码规则 | 注意事项 |
|---|---|---|
| 路径段 | 空格编码为%20，保留字按需编码 | 不要用+代替空格 |
| 查询键名 key | 用encodeURIComponent | 键名通常不应包含=和& |
| 查询值 value | 用encodeURIComponent，空格一般编码为%20 | 部分场景如表单默认编码会用+，扩展里统一按%20处理 |
| hash 片段 | 一般不编码 | hash 片段不会被发送到服务端，只作用于浏览器本地 |
所以在可视化编辑面板中，我引入了一个“当前编辑值状态”的概念，把值区分为“原始值”和“编码后值”，两者通过一个实时预览框对应。这样你可以直接看到中文原文，也清楚最终浏览器发送出去的编码形式。既然涉及到原始值与编码值的双向转换，这里就引出了下一节的算法实现：解析时先拆键值对，再对值做感知解码；写入时则统一编码。
2.4 搜索过滤与同键分组：快速定位与合并聚合
参数多且结构类似时，比如多个渠道标识都叫ch_前缀，就要靠搜索过滤。搜索框支持按键名模糊匹配、按值精确匹配、按是否符合编码状态过滤。只要输入ch_，表格就只剩那几个渠道参数，非常方便定位。
“同键分组”则是处理那些在 query 里多次出现的同名参数，例如tag=tech&tag=life这种数组式传参。默认会合并成一个聚合单元格，显示tag (共2个值)，展开后可以逐个编辑。这个设计主要是从稳定性的角度考虑，避免误改其中一个导致整体参数结构错乱。
2.5 历史快照与常用模板：一键恢复“此前状态”
调试过程中的状态记录是个容易忽略但实际收益很大的功能。每应用一次修改，我都会截一个快照并存入扩展的本地存储中，快照包含完整的 URL、参数集合、时间戳和操作类型。比如你改着改着发现当前参数组合不如之前的组合能复现 bug，直接在历史列表里选一个快照点击恢复，一切回到当时的状态，可以反复实验。这个功能在生产环境排查问题时特别好用，因为生产环境出了问题你往往是不敢乱点乱刷的，能停在一个稳定状态反复验证，就很关键。
常用模板功能则是给不同环境准备的，比如保存一套完整的“本地联调提供商版参数模板”，包含 source、channel、uid、deviceId 等字段，下一次切换到别的页面，直接加载模板，一键替换地址栏参数。
3. 核心实现解读：数据流、解析算法、渲染更新与关键代码
工具的目标用户不一定是插件开发者，但理解了核心实现，才知道如何调优，遇到问题也有排查方向。所以这一章我直接深入到代码层，把工具的骨架和关键逻辑讲清楚。
3.1 浏览器扩展的模块划分
扩展本身的模块划分包括四个部分：mainfest 清单文件、content script、background、以及注入到页面里的 HTML/CSS。content script 负责从地址栏读取 URL、监听地址栏变化、初始化参数容器；background 负责扩展图标点击事件、弹出面板的开关，以及把扩展的本地存储在前台面板和后台之间做中转。visual editor 面板本体是一个建立在 shadow DOM 里的组件，这样能隔离页面现有样式，避免相互污染，是这类调试工具必须考虑的一项。
manifest.json 的写法我这里直接贴一份基础配置：
{ "manifest_version": 3, "name": "URL Query Editor", "version": "1.0.0", "permissions": ["storage", "tabs", "activeTab"], "background": { "service_worker": "background.js" }, "content_scripts": [ { "matches": ["<all_urls>"], "js": ["content-script.js"], "run_at": "document_idle" } ], "action": { "default_title": "URL Query Editor", "default_popup": "popup.html" } }这个配置里有几个细节值得展开：为什么给storage权限？因为历史快照和常用模板需要持久化。为什么run_at选document_idle而不是document_start？原因很实际，document_idle时可以保证需要注入自定义事件的宿主元素已经存在，避免初始化阶段找不到容器导致面板无法挂载。
3.2 解析算法：未知 query 串的可逆拆解
解析 query 串的难点在于：你可能拿到一个并不规范、但浏览器允许的 URL 字符串。比如?a=hello%20world&b=1&b=2。正确解析后，应得到两个键a和b，再说b有两次出现。但如果你简单用split('&')再split('=')，会遇到两个问题：值是空字符串时split结果里缺少数组元素，键值里本身包含=时又会被多拆。
所以我用了一个严格的一遍扫描逻辑，核心是先按&或;切分参数对（注意;在部分遗留系统里也作为分隔符出现，这个兼容是实测中遇到的，适用范围确实存在），然后对每一对做“严格保留原始值”的拆解：
function parseQueryPairs(queryString = '') { const pairs = []; const segments = queryString.split(/[&;]/); for (const segment of segments) { if (segment === '') continue; const eqIndex = segment.indexOf('='); if (eqIndex === -1) { pairs.push({ keyRaw: segment, key: safeDecode(segment), valueRaw: '', value: '' }); } else { const keyRaw = segment.slice(0, eqIndex); const valueRaw = segment.slice(eqIndex + 1); pairs.push({ keyRaw, key: safeDecode(keyRaw), valueRaw, value: safeDecode(valueRaw), }); } } return pairs; }这里为什么用indexOf而不是split('=')？因为只取第一个=的位置作为键值分界点，剩下的所有=都归入值，这是处理a=1=2这种串最可靠的方式。value 的解码用到了一个safeDecode函数，它会先尝试decodeURIComponent，如果报错则原样返回，从而避免遇到非法百分号编码序列导致整个解析流程崩溃。
然后是不可忽视的 URL 重建逻辑。修改完参数后，需要把新的 query 串替换回原 URL。这个过程不能把 URL 里其他部分弄乱，尤其是 hash 部分。我用URL对象来做切分，但要注意：旧版本浏览器对带 hash 的 URL 的一些解析并不完全一说，因此这里用的还是location.origin + pathname + search + hash的组合方式，严谨可靠。
function buildUrlFromPairs(origin, pathname, pairs, hash) { const queryString = pairs .map(({ keyRaw, valueRaw }) => { return encodeURIComponent(keyRaw) + '=' + encodeURIComponent(valueRaw); }) .join('&'); return origin + pathname + (queryString ? `?${queryString}` : '') + hash; }重建时，键名和值我都先取 raw 形式，再统一做编码，可以保证输出格式一致。这样做的原因是：解析时已经把keyRaw、valueRaw保留下来，而编辑后用户输入的是解码形式，因此写入时一律视为普通字符，通过encodeURIComponent处理即可。
3.3 面板渲染与状态管理：尽量避免脏更新
面板内部我自建了一个简单的状态对象，用形如{ url, pairs, keyword, viewMode, filters }的结构存储当前面板的所有状态。每当 URL 地址栏变化或用户更改了单元格里的值，就会生成一个新的状态并触发render。
每次渲染时，我并不直接操作整棵 DOM 树，而是复用已有表格行，只对有差异的单元格做原地更新。这项优化看着微小，但实测下来很稳，尤其当参数达到一两百个时，整表重建会明显卡顿，原地更新则几乎没有感知延迟。实现时我用了一种“按 key 值”的对比法，给每个参数行赋予稳定 ID，用 ID 判断该行是否需要重建、单元格是否需要更新。
编辑行为还搭配了键盘快捷操作：Tab 跳到下一个单元格，Enter 确认并跳到下一个单元格，Esc 放弃当前修改并恢复到上一个值。这些操作是高频场景，不做好会让工具非常难用。
3.4 与地址栏的双向同步
地址栏与面板的状态同步存在两个方向。第一个方向：地址栏变化带动面板刷新。通过window.addEventListener('popstate', ...)加上setInterval的 hashchange 兜底可以达到目的。第二个方向：面板编辑反过来写入地址栏。这使用的是history.replaceState(null, '', newUrl)。两个方向互相配合，就形成了一个双向同步闭环。
这里有一个代码使用上容易踩的坑：history.replaceState在某些浏览器中会由于 URL 长度超限或含特殊字符而抛错。因此写入地址栏前一定要加 try/catch，失败时回退到location.href = newUrl并提示用户当前改动已强制刷新页面。这个点我在第四节会再展开。
4. 实战流程全演示：从安装到完成一次典型调试
光看功能列表，你可能还没有直观感受。我花点时间演示一个最典型的调试场景：某开发者在联调一个订单列表页，页面 URL 类似https://example.com/order/list?page=1&size=20&status=pending&source=home_banner&channel=app，后端说现在的订单列表只显示了已审核状态，怀疑是status参数传递有误。
4.1 安装扩展并打开面板
加载扩展包时，浏览器提示的是“加载已解压的扩展程序”，开发者模式打开后选择项目里的dist目录即可。加载成功后，浏览器工具栏会出现对应图标，点击图标就会呼出面板。面板默认停靠在页面右侧，宽度约 360 像素，必要时可以切换到底部模式。
首次打开时，面板会自动抓取当前标签页的 URL 并立即完成解析。地址栏中那一长串查询参数，瞬间变成带颜色区分的表格：键名用蓝色、值用深灰色、已编码值用浅黄背景。一眼扫过去，就能看出当前页面带了多少参数，哪些是服务端锚字段，哪些是业务动态字段。
注意：如果当前页面是
chrome://内部页或者浏览器商店页面，扩展自身的 content script 不会被注入，面板也无法工作。这不是扩展缺陷，是浏览器对内部页面的安全限制。遇到这种情况，随便打开一个普通网站即可正常使用。
4.2 快速定位目标参数并修改
在页面参数列表的搜索框输入status，表格立即只保留这一行。双击“值”单元格进入编辑态，原本显示的值pending被高亮选中，直接输入approved，右侧的“编码预览”立即更新。按下 Enter 确定，地址栏随即变成：
https://example.com/order/list?page=1&size=20&status=approved&source=home_banner&channel=app这时按 F5 或直接点击页面的“查询”按钮，页面就会带着新参数重新请求数据。整个过程不超过三秒钟，找到目标参数、改值、生效，一气呵成。
如果只是想测试参数但不希望地址栏被污染，可以切到“手动应用”模式，把面板里的改动积累起来，最后统一点击“应用到地址栏”。我用这个模式在代码评审场景下演示过，非常方便，不影响别人的当前操作状态。
4.3 使用历史快照恢复现场
实际操作中经常出现“我刚才那个能复现 bug 的参数组合哪去了”的窘境。比如上一步我把status改成了approved，但后来发现真正的问题只有在status=pending时才出现，而我又已经做过若干次改动，回不去了。这时打开历史快照列表，按时间倒序排列，找到几分钟前那一条 “status=pending, source=home_banner”，点击恢复。地址栏完全回到旧状态，页面再刷新，bug 如约复现，问题定位继续。
这个功能也解决了调试时的“误操作恐惧”问题。之前没有快照时，每做一次危险操作前都要复制原 URL 到文本编辑器留底，很浪费时间。现在不必了，每次改动都有痕迹，即使错了也能一键回滚。
4.4 用模板切换多环境参数组合
前端联调最烦的是每个环境参数组合不同。我保存了一套“生产图文详情页参数”，关键信息包括rid=7842&ab=experiment_2&traceId=build-7344等。当需要在不同环境快速对比时，直接加载这套模板，面板里自动填充对应参数，点击“应用”即可替换当前地址栏 URL 中的相关项。模板里没有出现的参数默认保留不动，防止误删原有上下文。
以上三个操作环节其实是这个工具的“本分”工作——解析、编辑、恢复。第五个功能点搜索过滤，以及同键分组，则是在做“增益”。靠近实战使用时，这两个功能会大幅提高处理复杂 query 的速度。
5. 常见问题与排查技巧实录
工具开源后，不少同事和朋友都装了。用得多了，各种稀奇古怪的报错和异常情况也一点一点汇总上来。挑几个出现频率高、又有代表性的列在这里，也给后面想自己做类似工具的人参考。
5.1 参数值带特殊字符导致接口报错
典型场景：把一个值为hello#world的参数写入地址栏，后端接口却收到hello，world被截断了。排查下来发现根因在于：用户在编辑面板里输入的值确实包含#，但#在 URL 里是 hash 分隔符，从#开始的所有字符都被浏览器当作片段锚点，根本不会发送到服务端。
排查思路很简单：先看面板中“编码后值”列，如果发现#被原样保留而没有变成%23，就说明工具没有对值做充分的编码处理。这里的修正方案是：把所有非保留字字符，尤其是#/?@&都统一转成百分号编码格式，再写入地址栏。
我自己实践经验是：编辑面板中展示的是解码后的原文，写入地址栏前必须执行一次encodeURIComponent。任何想当然认为浏览器会自动修正的想法都会导致这类问题。
5.2 框架路由下地址栏变化被吞掉
场景：Vue 或 React 项目里用了 HTML5 History 模式，页面跳转不会产生完整页面加载，仅通过history.pushState更新地址栏。这种情况下，工具在地址栏变化后没有立刻刷新面板，显示的还是上一个页面的参数。
排查思路：popstate事件只在前进、后退、hashchange时触发，pushState和replaceState本身是无法通过事件监听直接捕获的。可行的方案是：在面板轮询location.href并与本地缓存做对比，差异出现则触发重新解析。我实测用 500 毫秒的轮询间隔，性能开销极小，但能覆盖绝大多数 SPA 路由场景。
5.3 编码状态误判导致显示乱码
有一次用户反馈说工具把某参数显示成了一堆%，根本没法读。打开面板一看，该参数的“已编码”标记高亮，但编码前预览显示的还是%E4...这种形式，说明解析阶段做了两次解码导致原始信息丢失。
排查思路：经过完整编码的值，通常形如%E4%B8%AD%26%E6%96%87，解码一次即可得到原文。但如果原值本身包含%字符，比如文件名字符串里的百分号，就会出现“看起来像编码其实不是”的场景。我给safeDecode增加了严格性判断：只有能完整解码、且解码后不包含额外%开头的非法序列时才认为这是编码状态，否则保持原始值。说白了就是让“解码可逆性验证”决定最终显示形式，从根上避免二次解码。
5.4 设置模板后出现重复参数
加载模板并应用后，地址栏里出现两组相同的参数，一组是模板携带的，一组是原地址栏中已有的。排查结果：模板替换逻辑最初是“追加式”的，即新参数直接拼接在原有 query 末尾，没有做 merge。
修正方案：应用模板前先按键名比对，遇到同键参数，默认采用模板值并覆盖原值。同时保留一个“保留原键值”的开关，允许高级用户在同一键下保留多个值（例如数组式参数场景）。合并逻辑的核心是：模板是“期望态”，地址栏是“当前态”，两者之间应做差异计算，而不是简单叠加。
5.5 特殊页面无法注入与降级方案
前面提过chrome://页面无法注入 content script。这个问题在线下演示时很容易踩，现场页面一旦是扩展页或新标签页，演示就尴尬了。我后来在工具中做了一个降级方案：检测到无法注入时，面板里显示一个静态输入框，用户手动粘贴任意 URL，工具同样可以解析和编辑参数，操作完毕后手动复制生成的 URL 去访问。虽然不像直接改地址栏那样实时，但兜底效果很好。
5.6 性能与稳定性问题速查表
把我在线上使用和用户反馈的高频问题整理成一张速查表，方便对照处理：
| 现象 | 可能原因 | 排查步骤 |
|---|---|---|
| 面板打开后空白 | content script 注入失败或 shadow DOM 容器未渲染 | 刷新页面，查看扩展错误日志 |
| 修改参数后页面立即刷新 | replaceState异常回退到了location.href | 检查 URL 是否含超长字符串，尝试手动应用模式 |
| 参数丢失 | 应用模板时 merge 策略不正确 | 检查模板应用开关是否开启“保留原键值” |
| 中文显示为百分号编码 | 值处于已编码状态，面板中应有解码预览 | 确认“编码前预览”列是否展开 |
| 历史快照恢复旧值失败 | 快照中 URL 已失效或参数顺序变化 | 恢复后手动刷新页面 |
| 与页面自身调试面板的样式冲突 | shadow DOM 隔离失败，面板混入页面样式 | 检查面板是否挂载在 shadow root 下 |
| 编辑时输入法候选框被遮挡 | 面板 z-index 过低或层级不符 | 在面板容器的全局样式里提高层级 |
单个问题写清楚排查路径，比单纯放一个“已知问题”列表有价值得多。调试工具也需要被调试，这个环节其实是打磨整个产品闭环中最耗时、但最能提升大家实际使用体验的部分。
6. 扩展方向：从个人工具到团队协作的轻量桥
工具做到这个程度，对个人调试已经完全够用。但实践过程中我也发现，它可以往两个方向再拓宽一步，变成一个团队效率资产。
第一个扩展方向是 URL 参数模板的共享。项目组里经常要联调的接口和页面相对固定，每个模块的参数组合也基本稳定。我当前版本的模板只能存本地，团队协作时大家各自维护各自的一套，肯定会存在版本不一致的情况。后来我在内网做了一个轻量化方案：把常用模板转成 JSON 文件，存到公共配置仓库中，工具启动时检测到远端配置更新就自动拉取。团队成员不必手动同步就能保持模板一致，规避了大量重复沟通成本。
第二个方向是差异对比模式。生产环境和本地环境之间的差异排查，往往就是参数差异排查。我在扩展里增加了一个 “对比模式”：粘贴或选取两个 URL，工具会分别解析参数集合，然后列出哪些键只在 URL A 中出现、哪些只在 URL B 中出现、哪些键相同但值不同，并且高亮展示具体差异。这样一来，联调分析“为什么本地接口报 400 而生产是 200”就变得很直接，不用再人工一处一处对照地址栏了。
不过说实话，功能越多，维护成本越高。我在迭代过程中有意识地控制新增功能的数量，尽量不做那种“听起来花哨但实际没人点”的设计。比如曾经想过做一个实时的命令面板，通过快捷键输入参数名直接改值，看起来效率很高，后来评估下来发现它跟搜索框、表格编辑这两个已有能力高度重叠，而且新用户学习成本更高，最终就没做。
我的原则是：工具应该做深自己最擅长的那几个核心场景，而不是把页面里每一个位子都塞满按钮。URL 参数调试的核心永远只有三件事：快速看清、快速改对、快速找回。剩下的所有功能都是围绕这三件事添砖加瓦，千万别本末倒置。
至于代码维护上，我最后再分享一点实践经验：这个扩展虽然组件较多，但核心逻辑其实很薄。建议后续接手维护的人，把解析算法、编码策略和状态管理单独拆成纯函数模块，不要和 DOM 渲染代码混在一起。这样当浏览器规范升级或遇到特例 URL 时，定位问题会快很多。我踩过几次代码纠缠的坑之后，深刻地认识到，工具自身如果设计得不好调试，本身就会变成一个负担，而干净的数据层是避免这种负担的最有效手段。
