Bilibili-Evolved 网址参数清理：原理、内置参数表与扩展机制全解析

Bilibili-Evolved 网址参数清理原理、内置参数表与扩展机制全解析【免费下载链接】Bilibili-Evolved强大的哔哩哔哩增强脚本项目地址: https://gitcode.com/gh_mirrors/bi/Bilibili-Evolved导读Bilibili-Evolved 的「网址参数清理」组件urlParamsClean会自动移除 B 站网址中spm_id_from、vd_source、from_source等大量跟踪/跳转参数并在启用「清理页面中的 A 标签」后同步清理视频简介、推荐列表、标签、评论中的外链参数。本文从功能定位出发结合 index.ts 与 anchor.ts 的源码实现完整呈现内置过滤参数表、站点定向参数、页面锚点清理机制、History API 拦截原理以及第三方插件扩展点帮助你彻底理解并正确使用这一组件。一、组件是什么一句话定位与适用场景「网址参数清理」是 Bilibili-Evolved 中一个位于「工具」分类componentsTags.utils的组件核心功能是自动删除网址中的多余跟踪参数例如视频分享链接中常见的spm_id_from、vd_source、seid、share_source等。它解决的典型痛点包括从移动端 App「分享到网页」产生的链接带有大量share_*、spmid、buvid等参数既不美观也无益于阅读从站外如微信、QQ、搜索引擎跳转进入 B 站时URL 上会被附加vd_source、tdsourcetag、from等来源追踪参数干扰书签、收藏与复制视频页、直播页、空间页内部跳转时B 站前端自身会在 URL 上叠加from_spmid、hotRank、accept_quality等运行态参数导致地址栏 URL 持续膨胀。该组件在 Bilibili-Evolved 的功能清单中登记名为urlParamsClean展示名为「网址参数清理」详见 doc/features/features.json。二、启用方式与唯一开关清理页面中的 A 标签2.1 在设置面板中启用在 Bilibili-Evolved 的「设置 → 组件设置 → 工具」分类中找到「网址参数清理」打开开关即可生效。组件仅有一个可配置选项选项默认值说明清理页面中的 A 标签true开启清理视频简介、推荐列表、标签、评论中的链接该选项在源码中定义于 index.tsconst options defineOptionsMetadata({ cleanAnchors: { defaultValue: true, displayName: 清理页面中的 A 标签, }, })关闭该项后组件仍然会清理当前地址栏 URL含 History API 拦截只是不再改写页面中a标签的href。2.2 组件入口与运行前提组件入口函数index.ts在运行前做了两层环境判断const entry async () { if (isNotHtml() || isIframe()) { return } ... }即在非 HTML 文档如纯文本响应以及 iframe 内不执行清理避免对 B 站内嵌的第三方页面造成误伤。同时组件声明了排除匹配urlExclude见 index.ts以下页面不会加载本组件game.bilibili.com/fgolive.bilibili.com/p/html/live-app-hotrank/三、核心清理逻辑getCleanUrl 的完整流程组件所有清理行为的共同底层是getCleanUrl(originalUrl)index.ts地址栏清理与 A 标签清理都复用该函数。其处理流程如下解析 URL用new URL(originalUrl, location.origin)将相对地址解析为绝对地址展开查询参数通过new URLSearchParams(url.search)将查询串拆成keyvalue数组其中 value 会经过encodeURIComponent编码保证含特殊字符的参数不会被破坏豁免检查noClean若任意参数名包含noClean列表中的关键词如videocard_series则整体放弃清理原样返回原始 URL参数过滤blockParams删除所有命中内置黑名单的参数站点定向过滤siteSpecifiedParams按「当前页面 URL 是否匹配指定正则」来决定是否删除特定参数尾部斜杠处理tailingSlash对命中规则的路径去掉结尾的/默认内置列表为空主要留给插件扩展重建 URL把剩余参数用拼接回查询串必要时补?前缀最后返回url.toString()。3.1 内置黑名单参数表blockParams这是组件最核心的资产。内置参数名单定义于 index.ts按用途大致可分为几类站外来源/追踪类from_source、from_spmid、from、seid、share_source、share_medium、share_plat、share_tag、share_session_id、share_from、bbid、ts、timestamp、unique_k、rt、tdsourcetag、bsource、spm、spmid、vd_source、msource、visit_id、trackid、referfrom、buvid、goFrom、launch_id播放器/清晰度运行态类accept_quality、broadcast_type、current_qn、current_quality、playurl_h264、playurl_h265、quality_description、network、network_status、platform_network_status、p2p_type跳转/排行/杂项类hotRank、-Arouter、is_story_h5、plat_id、jumpLinkType、hasBack、noTitleBar、live_from、extra_jump_from、subarea_rank、popular_rank、from_avid、from_comid名单中既有spm_id_from这类最常见的分享追踪参数也有-Arouter这类通配形态参数名以-Arouter结尾即命中因为匹配方式是p.startsWith(\${b})覆盖相当全面。3.2 豁免名单noClean某些参数虽然名字里带有黑名单关键词但删掉会破坏功能因此需要豁免。内置豁免名单为[videocard_series]index.ts。匹配规则是「参数是否包含该子串」if (urlParams.some(param noClean.some(it param.includes(it)))) { return originalUrl }也就是说只要 URL 里存在一个参数名包含videocard_series该 URL 就整体不做清理防止系列视频卡片链接的参数被误删。3.3 站点定向参数siteSpecifiedParams某些参数只在特定页面类型下才需要删除。内置规则表如下index.ts匹配页面正则删除的参数www.bilibili.com/audio/(au[\d]|mycollection)typelive.bilibili.com/session_idlive.bilibili.com/is_room_feedwww.bilibili.com/bangumi/themewww.bilibili.com/video/midwww.bilibili.com/video/up_idmall.bilibili.com/noReffer注意这里的匹配对象是当前页面的 URLdocument.URL.match(match)而不是被清理链接自身的 URL。因此其语义是当你在视频页时凡是链接中带mid、up_id参数的都会被剔除在直播页时则剔除session_id、is_room_feed。四、三种清理路径地址栏、History API、页面链接4.1 直接清理当前地址组件加载时以及后续每次 URL 变化时都会执行clean()index.tsconst clean () { const newUrl getCleanUrl(document.URL) if (newUrl ! document.URL) { console.log(直接清理, document.URL, newUrl) window.history.replaceState(history.state, , newUrl) } }即用replaceState把当前历史记录项替换为清理后的 URL——不会新增历史记录地址栏立即显示干净链接。4.2 拦截 History API仅清理当前地址还不够因为 SPA 页面在切换路由时会不断调用pushState/replaceState写入新 URL。组件通过包装原生方法实现前置拦截index.tsconst originalPushState unsafeWindow.history.pushState unsafeWindow.history.pushState createHistoryHook(originalPushState) const originalReplaceState unsafeWindow.history.replaceState unsafeWindow.history.replaceState createHistoryHook(originalReplaceState)createHistoryHook会先尝试用new URL(url, location.origin location.pathname)解析传入的 URL解析失败则记录警告并原样放行解析成功后调用getCleanUrl若结果与原始 URL 不同就把清理后的 URL传给原生方法并在控制台输出History API 拦截日志。这样B 站前端无论怎样切换路由写入历史记录的 URL 都已被自动净化。4.3 页面内定时/增量清理 A 标签当选项cleanAnchors为true时组件会调用cleanAnchors(getCleanUrl)实现在 anchor.ts。该函数的核心策略是「一次性清理 MutationObserver 增量监听」clean(a)判断节点是否为a且有href用getCleanUrl计算新地址不同则改写a.href并打印清理A标签日志视频标签tag-panelDOMContentLoaded时统一清理.tag-panel .tag-linkHTML 自带参数不会触发 MutationObserver同时用监听器观察.tag-panel的href属性变化与子节点新增切换视频时标签由 JS 动态添加视频简介#v_desc监听子节点插入对新插入元素内的所有a进行清理视频推荐列表.recommend-list-container / .rcmd-tab先全量清理.recommend-list-container a再监听.rcmd-tab,.recommend-list-container区域内的新增节点与href变化评论区通过forEachCommentArea遍历评论区对CommentAreaV3区域监听ShadowRootEvents.Updated事件Shadow DOM 内容更新对每次更新中新增的节点执行清理。监听配置统一使用observeChildListSubtreeHrefanchor.ts即同时观察href属性变化与子节点增删characterData: false表示不关心文本内容变化。五、已知副作用历史记录与后退行为官方文档明确提示了两点副作用属于该组件的设计预期使用时需要知晓浏览器历史记录会出现重复标题由于组件会同时改写pushState/replaceState的 URL 与页面内链接浏览器历史中会存在转换前、转换后两个网址对应的记录条目尤其当用户先访问带参数链接、随后地址栏被replaceState净化时后退可能需要多退几次历史栈中多出的“转换前”条目会导致按一次后退键不一定回到期望页面可能需要多按几次。这两点并非缺陷而是「保持历史栈真实记录原始访问链」与「提供干净 URL」之间的权衡结果。六、第三方扩展机制四个可注册数据点组件内置的过滤名单并非写死。它通过 Bilibili-Evolved 的插件数据系统registerAndGetDatasrc/plugins/data.ts将默认数据注册为可被其他插件覆盖/追加的「数据点」const [blockParams] registerAndGetData(urlParamsClean.params, builtInBlockParams) const [noClean] registerAndGetData(urlParamsClean.noClean, builtInNoClean) const [siteSpecifiedParams] registerAndGetData(urlParamsClean.siteSpecifiedParams, builtInSiteSpecifiedParams) const [tailingSlash] registerAndGetData(urlParamsClean.tailingSlash, builtInTailingSlash)四个数据点及数据类型如下数据点 key元素类型语义urlParamsClean.paramsstring追加进黑名单的参数名按key前缀匹配urlParamsClean.noCleanstring追加豁免关键词参数名包含即整链不清理urlParamsClean.siteSpecifiedParams{ match: string \| RegExp, param: string }追加“当前页匹配match时删除param”的规则urlParamsClean.tailingSlash{ match: string \| RegExp }追加“路径匹配时去掉结尾斜杠”的规则以追加黑名单参数为例第三方插件只需registerAndGetData(urlParamsClean.params, my_custom_track_param)即可让组件在后续清理中同时剔除该参数无需修改组件源码。matchPatternsrc/core/utils/index.ts的实现说明tailingSlash的match既可以是子串字符串也可以是正则表达式。七、URL 变化联动与 observer 系统的配合为了在页面不刷新SPA 路由切换时也能持续清理地址栏组件等待页面完全加载后注册urlChange回调index.tsconst { fullyLoaded } await import(/core/life-cycle) const { urlChange } await import(/core/observer) fullyLoaded(() { urlChange(() clean()) })urlChangesrc/core/observer.ts会在注册时立即回调一次document.URL并在 Bilibili-Evolved 内部派发的urlChange事件触发时再次回调。配合前面包装过的 History API两者共同保证了当前地址被立即清理注册时回调 replaceState后续每次路由变化写入的 URL 在进入历史栈前就被净化History 钩子即使有未被钩子覆盖的 URL 变化路径urlChange监听也会兜底重新执行clean()。八、从源码结构可以推断的扩展方向基于上述源码结构可以推断出该组件的几个自然扩展方向供有定制需求的开发者参考扩充站点定向规则若某些页面如番剧、专栏也存在专属的无用参数可通过urlParamsClean.siteSpecifiedParams数据点按页面类型精准追加比全局黑名单更安全去除尾部斜杠tailingSlash数据点默认为空数组说明项目有意将“去掉路径结尾/”的能力留给插件按需启用结合导出日志排查组件在控制台输出直接清理、History API 拦截、清理A标签三类日志均带「网址参数清理」作用域前缀见 index.ts排查“某个参数为何没被清理”时可按此定位是命中豁免、未命中黑名单还是站点定向规则未匹配。九、小结「网址参数清理」是一个“小而精”的工具组件对外只暴露一个开关内部却覆盖了地址栏直接清理、History API 拦截、SPA 路由联动和页面 DOM 增量清理四条路径并内置了数十个 B 站常见跟踪/运行态参数的过滤规则。它的核心设计经验值得借鉴统一清理函数getCleanUrl被所有清理路径复用保证行为一致黑名单 豁免名单 站点定向规则三层过滤模型兼顾覆盖面与误伤控制通过registerAndGetData开放数据点让第三方插件无需改动组件即可扩展规则对「历史记录重复 / 后退多退几次」等副作用在文档中明确告知属于经过权衡的预期行为而非缺陷。若你正在使用 Bilibili-Evolved建议开启该组件并在浏览器控制台观察其日志输出即可直观看到每条链接被净化的前后对比若你正在开发相关插件四个数据点是接入本组件最简洁、也最符合项目规范的扩展入口。【免费下载链接】Bilibili-Evolved强大的哔哩哔哩增强脚本项目地址: https://gitcode.com/gh_mirrors/bi/Bilibili-Evolved创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考