简介这是一款面向开发者、用于加速 Stack Overflow 访问的浏览器扩展资源包特别适合经常在 Win10 系统下使用 Chrome 或 Firefox 查阅技术文档与问答的用户。它通过替换 Google CDN 相关引用有效降低资源加载耗时让页面响应速度大幅提升安装步骤简单无需额外配置或高级编程技能即可上手。压缩包共 6 个文件包含 2 个 JS 脚本、2 个 PNG 图标和 2 个 JSON 配置文件分别承担扩展核心逻辑、界面展示与权限声明等功能整体仅 61KB非常轻量同时内置 Chrome 与 Firefox 两套独立实现方便不同浏览器用户直接选用。目前已有 1522 人学习下载资源虽小但内容完整清晰适合遇到 Stack Overflow 访问缓慢问题的开发者快速部署使用能够明显改善日常浏览与检索体验。 上周一个老同事发消息给我说公司新上的报表后台打开一直是白屏转几圈后出来一堆没有样式的文字控制台里全是红色报错。我远程看了一眼问题很典型页面里引用的几个JS库、字体文件全部挂在ajax.googleapis.com、fonts.googleapis.com上这些请求在网络环境不理想的情况下要么一直pending要么直接net::ERR_FAILED。这就是经典的Google CDN 拖垮页面问题。Replace Google CDN 这类小工具专治这种资源挂在外网 CDN 上导致页面半残的场景。这篇文章我会从项目背后的替换逻辑讲起把它常用做法、镜像源选择、容易翻车的几个细节全部过一遍供遇到同类问题的朋友参考。1. 先搞懂网页为什么会卡在Google CDN上1.1 哪些站点在悄悄依赖Google CDN很多网站并不是开发者主动想用 Google CDN而是被上游模板、开源项目顺手带进来的。最典型的几个来源WordPress 主题大量付费和免费主题默认加载 Google Fonts用于渲染字体样式。开源后台模板许多管理后台、博客程序默认引用ajax.googleapis.com/ajax/libs/...路径下的 jQuery、AngularJS、Bootstrap。富文本编辑器、图表库不少第三方插件把依赖直接写死为 Google Hosted Libraries没有做本地化处理。统计、验证类组件部分站点还嵌入了 Google Analytics、reCAPTCHA 相关脚本这类请求往往还带有额外参数失败后前端会静默降级但某些页面功能会直接失效。这些资源有一个共同点它们都是页面渲染的关键路径资源。JS 库位于head中且没有async或defer时浏览器会阻塞解析直到下载并执行完毕。如果这个下载请求迟迟不返回页面就一直白屏。字体资源虽然不阻塞 HTML 解析但会导致文字迟迟不显示正确字体出现无样式文字闪烁。1.2 请求失败后页面到底经历了什么一次外部 CDN 请求失败浏览器通常不是立刻放弃而是会经历 DNS 解析、TCP 连接、TLS 握手、发送请求、等待响应等一系列步骤。默认超时时间在数十秒级别TCP 连接还会做多次重试这就是为什么用户感觉转圈转了很久。等超时结束后页面通常呈现以下状态script标签加载失败依赖该库的后续代码全部抛异常页面交互功能大面积失效。link样式加载失败页面回到无样式的裸 HTML布局错乱。字体加载失败浏览器回退到系统字体但很多主题的字号、字重是针对特定字体设计的观感差距很大。异步统计脚本失败一般不影响主流程但数据分析链路断裂对运营有影响。更麻烦的是这种情况往往是间歇性的。同一个请求某些网络环境下几毫秒就返回了另一些环境下几十秒超时。于是这类问题很难稳定复现容易被打上玄学标签。1.3 为什么线上问题总是反复出现核心原因是开发者本地网络正常和用户网络环境异常之间存在信息差。开发者在办公室或家里访问站点外部 CDN 资源几乎是秒开根本不会意识到依赖了外网资源。等用户报障时用开发者工具一看又全是OK。这种问题在内部系统、面向特定地区的业务站点上尤其常见。Replace Google CDN 这类工具解决的正是这个最后一环它不要求你改源码也不要求你切换服务器只要在浏览器端把写死的 Google CDN 地址替换成更稳定的镜像地址就能让页面正常加载。理解了问题成因再看它内部的替换逻辑就顺理成章了。2. Replace Google CDN的替换逻辑从URL改写说到请求拦截2.1 一张域名映射表做掉80%的事Replace Google CDN 的核心逻辑并不复杂本质上就是维护一张域名映射表原域名替换目标用途ajax.googleapis.com镜像站相同路径JS 库文件fonts.googleapis.com镜像站相同路径字体样式 CSSfonts.gstatic.com镜像站相同路径字体文件storage.googleapis.com镜像站或本地路径部分静态资源www.gstatic.com镜像站或本地路径通用静态资源替换时只换域名不换路径和参数。比如https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js https://cdn.bootcdn.net/ajax/libs/jquery/3.6.0/jquery.min.js这种规则的好处是保留了原生路径结构镜像站只要按照 Google 的目录结构同步文件替换后就能直接走通。多数公共镜像都支持这种路径兼容方式。2.2 静态改代码与运行时拦截是两条完全不同的路处理外部依赖最正规的做法是从源码层面解决把所有第三方库下载到本地或者改成在构建时引用国内 CDN。但这对普通用户不现实你不可能给访问的每个网站改代码。所以工具通常走第二条路运行时拦截请求。运行时拦截在浏览器端有几种实现方式浏览器扩展通过chrome.webRequest或declarativeNetRequest监听请求命中规则后重定向到镜像地址。优点是工具对页面完全透明页面代码感知不到变化。用户脚本配合 Tampermonkey、Violentmonkey 等脚本管理器在页面加载早期注入脚本。可以改写页面中的静态标签也可以拦截XMLHttpRequest和fetch灵活性更高。Service Worker注册一个fetch事件处理函数对请求 URL 做映射后返回镜像响应粒度可以做得非常细。其中扩展的declarativeNetRequest方式效率最高因为重定向规则由浏览器底层执行不需要往页面里注入 JS。但写起来限制也多某些条件下不支持动态修改请求头。用户脚本虽然优雅度略差但胜在规则灵活修改即时生效是很多前端开发者调试时的首选。2.3 为什么多数在线工具选择浏览器扩展路线如果你要替换的是别人网站上的资源服务端方案基本不可行因为你不掌握别人的服务器。浏览器扩展则是以用户身份运行的最外层翻译官它不需要站点配合也不需要服务器。用户装上扩展后访问任意站点时只要请求命中规则就会被重写覆盖面是全网所有页面。这也解释了为什么这个项目常被打包成 zip 文件分发——zip 解压后加载到浏览器扩展管理页即可使用。相比上架应用商店zip 分发省掉了审核流程用户也能直接看到扩展源码对很多注重透明度的开发者来说反而是加分项。2.4 路径和query参数必须原样保留替换规则里最容易忽略的是 query 参数。Google Fonts 的 CSS 请求长这样https://fonts.googleapis.com/css2?familyRoboto:wght400;700displayswap替换域名后family、display这些参数必须原样保留否则镜像返回不了对应的字体子集。同理ajax.googleapis.com/ajax/libs/...路径中ajax/libs这部分也不能改动镜像站的目录结构依赖它做映射。如果替换逻辑把整个 URL 重新拼了一遍很容易丢参数。一个比较稳妥的写法是只替换 URL 中的域名部分其余内容不动。遇到完整 URL 时用 URL 对象解析只改host字段再拼回去这样能最大程度避免误伤路径和参数。3. 实操落地三种替换方式与镜像源选择3.1 拿到zip包后怎么装你拿到的Replace Google CDN.zip解压后通常是一个扩展目录里面包含manifest.json、JS 脚本、图标等文件。安装步骤解压 zip 到本地一个固定目录不要删。打开 Chrome/Edge 的扩展管理页地址栏输入chrome://extensions/或edge://extensions/。打开右上角的开发者模式开关。点击加载已解压的扩展程序选择刚才解压的目录。扩展列表出现后建议顺手固定到工具栏方便查看当前页面的替换命中情况。安装后可以先在扩展的规则页里确认要启用哪些替换项。通常默认全开但如果你只关心 JS 库而不管字体可以把字体项关掉减少误替换风险。3.2 用用户脚本做更细粒度的规则如果你不想装扩展或者扩展的规则满足不了需求可以用 Tampermonkey 用户脚本的方式。写一个最简单的规则脚本// UserScript // name Google CDN Replacer // namespace local.cdn.replacer // match *://*/* // run-at document-start // grant none // /UserScript const RULES [ { from: ajax.googleapis.com/ajax/libs, to: cdn.bootcdn.net/ajax/libs } ]; function replaceResourceUrl(url) { if (!url) return url; for (const rule of RULES) { if (url.includes(rule.from)) { return url.replace(rule.from, rule.to); } } return url; } const originalCreateElement document.createElement.bind(document); document.createElement function (tagName, options) { const el originalCreateElement(tagName, options); if (tagName.toLowerCase() script) { const originalSetAttribute el.setAttribute.bind(el); el.setAttribute function (name, value) { if (name src) { value replaceResourceUrl(value); } return originalSetAttribute(name, value); }; } return el; }; new MutationObserver((mutations) { for (const mutation of mutations) { for (const node of mutation.addedNodes) { if (node.nodeType ! 1) continue; const scripts node.querySelectorAll ? node.querySelectorAll(script[src], link[href]) : []; scripts.forEach((el) { if (el.tagName SCRIPT el.src) { const replaced replaceResourceUrl(el.src); if (replaced ! el.src) el.src replaced; } if (el.tagName LINK el.href) { const replaced replaceResourceUrl(el.href); if (replaced ! el.href) el.href replaced; } }); } } }).observe(document.documentElement, { childList: true, subtree: true });这个脚本做了三件事重写createElement、监听 DOM 变化、对新增的script和link标签做 URL 替换。对于大部分由运行时插入的资源基本都能覆盖。如果你是普通用户而不是开发者不建议直接抄这段脚本优先用现成扩展就好。3.3 服务端接入层替换思路如果你管着一台服务器又希望让整个内网的用户都受益可以在接入层做统一替换。以 nginx 为例思路是碰到ajax.googleapis.com的请求时rewrite掉原 host然后回源到国内镜像。或者直接用proxy_pass把对应路径转发到镜像站。这种方案的优点是浏览器端零配置缺点是镜像站如果挂了所有请求跟着挂所以务必配置超时和 failover。此外服务端替换要考虑 TLS 证书、回源带宽、日志记录等问题适合有一定运维基础的人。3.4 镜像源怎么选镜像源的选择直接决定替换后的体验。我整理了一份常用公共库的对比镜像名覆盖库范围HTTPS国内访问速度维护情况BootCDN常用前端库路径兼容较好支持快社区维护更新及时字节跳动静态资源库覆盖多曾提供Google库镜像支持快大厂维护Staticfile常用库覆盖较广支持较快社区维护jsDelivr依托 npm/GitHub覆盖极广支持时有波动独立组织维护unpkg严格对应 npm 包支持视网络而定独立维护选择原则我总结了四条先验证目标库和版本在镜像上确实存在。很多镜像只同步了常用版本冷门版本经常缺。优先支持 HTTPS。现代站点基本都是 HTTPS镜像不支持 HTTPS 会导致混合内容被浏览器拦截。关注 CORS 响应头。部分场景需要跨域读取资源比如 Canvas 绘制、模块加载镜像必须返回正确的Access-Control-Allow-Origin。不要只盯一个镜像。我见过 BootCDN 某个库临时抽风的情况所以规则里最好给同一资源配多个后备镜像。4. 替换后最容易翻车的三个坑4.1 SRI完整性校验会把替换后的脚本当场拦下SRISubresource Integrity是很多安全要求高的站点给外部脚本加的一道锁。比如页面里写的是script srchttps://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js integritysha384-... /script浏览器会计算下载内容的哈希跟integrity里的值比对不一致就拒绝执行。问题在于很多镜像为了压缩或统一出口对文件做了二次处理导致内容和原文件哈希对不上。扩展虽然把请求地址替换成了镜像但integrity属性还在浏览器校验不过脚本照样不会执行。排查方法很简单打开控制台看有没有类似Failed to find a valid digest in the integrity attribute的报错。解决思路有三种在替换规则里同时删除integrity属性。提前把镜像文件的哈希算出来写进自定义规则。如果站点是你自己的直接改用构建阶段本地化不要再依赖外部 SRI。个人建议是第二种最稳既保留了完整性校验又不会因为替换导致校验失败。4.2 字体文件路径和CORS问题比想象中多替换 Google Fonts 时如果只把fonts.googleapis.com换掉而 CSS 文件里font-face指向的fonts.gstatic.com没有被替换那么字体文件依然会去原域名请求。轻则加载慢重则字体彻底加载失败。所以字体相关的替换必须同时覆盖fonts.googleapis.com和fonts.gstatic.com两个域名。另一个隐蔽问题是 CORS。字体文件在真正被绘制前浏览器会做跨域检查。如果镜像响应头里没有Access-Control-Allow-Origin那么控制台会报字体跨域错误常见于某些不规范的公共镜像。遇到这种情况优先换一个支持 CORS 的镜像而不是自己去写复杂的绕过逻辑。4.3 动态插入的脚本经常被漏掉SPA 应用里脚本加载比传统页面复杂得多。很多库是路由切换时才通过动态import()或appendChild插入script标签的。如果替换逻辑只处理页面初始 HTML 里的标签那这些运行时请求全部会走原地址替换效果大打折扣。处理这类情况需要在页面初始化阶段就注册好MutationObserver监听所有新增的script和link标签。同时建议重写createElement的setAttribute因为有些框架会在创建元素后通过setAttribute设置src常规的 DOM 监听不一定能及时捕获到。这也是我前面脚本示例里同时做两层兜底的原因。4.4 建议维护一份站点名单不要对全网所有站点一律开启替换。有些大站已经自建了 CDN第三方资源走的是自己的加速域名有些页面虽然引用了 Google CDN 地址但已经加了 SRI 兜底逻辑还有些镜像上的文件版本偏老替换后反而会引发兼容问题。我在实际使用中会维护一份名单明确需要对哪些域名启用替换哪些域名直接跳过。这个名单随用随调线上遇到问题半小时内就能定位到是不是替换规则误伤。工具是死的规则是活的别让一个救火工具变成新的纵火源。5. 从替换到自救长期更稳的资源本地化方案5.1 如果你是站点管理员请从构建期解决问题Replace Google CDN 这类工具解决的是客户端问题但对于你运营的站点来说它只是临时止血。长期方案是构建期就把第三方依赖全部收敛用 npm 或 yarn 安装前端依赖构建时统一打包到本地静态目录。如果需要走 CDN选一个稳定的国内公共库并把版本号固定好。打包后的静态资源加上内容哈希配合长期缓存策略整体加载速度反而优于逐个请求外部 CDN。这样做的好处是彻底摆脱对外部 CDN 的运行时依赖也不需要考虑镜像同步、SRI 冲突、CORS 这些问题。代价只是首次构建配置稍微多花点时间但对站点稳定性的提升非常明显。5.2 如果你是普通用户可以试试Service Worker兜底Service Worker 是另一个值得关注的思路。注册一个fetch事件处理函数当页面请求第三方 CDN 资源失败时从本地缓存或离线包里返回同名资源。这个方案比通用替换更智能它只在原请求失败时介入正常访问时完全不影响性能相当于给页面加了一层保险。实现上也没有想象中复杂先把常用库的静态文件缓存到 Cache Storage然后在fetch事件里对匹配的 URL 做event.respondWith先尝试网络请求失败后再从缓存读取。相比扩展方案Service Worker 的优势是它跟随站点部署所有访问该站点的用户都能受益但前提是你需要对站点有控制权。5.3 根据个人经验给出三条建议第一临时访问别人站点时用浏览器扩展或用户脚本替换即可重点关注 JS 库和字体两个大类其他资源不必贪多。第二长期维护自己的站点时老老实实做构建期本地化不要指望所有用户都会装替换工具。第三不管用哪种方案都要留一条验证路径打开控制台确认替换后资源请求的Name列已经指向镜像域名同时观察有没有 SRI 或 CORS 报错。最后分享一个小技巧在规则里给每种资源配置两个镜像第一个镜像超时超过 3 秒就自动切换第二个。别小看这个设置我靠它在一次镜像源故障中硬是没让线上页面出现白屏。工具的价值从来不是让你守着它而是让你关键时刻能腾出手来解决真正的问题。本文还有配套的精品资源点击获取 Replace Google CDN：解决页面白屏与静态资源加载失败的实用指南
简介这是一款面向开发者、用于加速 Stack Overflow 访问的浏览器扩展资源包特别适合经常在 Win10 系统下使用 Chrome 或 Firefox 查阅技术文档与问答的用户。它通过替换 Google CDN 相关引用有效降低资源加载耗时让页面响应速度大幅提升安装步骤简单无需额外配置或高级编程技能即可上手。压缩包共 6 个文件包含 2 个 JS 脚本、2 个 PNG 图标和 2 个 JSON 配置文件分别承担扩展核心逻辑、界面展示与权限声明等功能整体仅 61KB非常轻量同时内置 Chrome 与 Firefox 两套独立实现方便不同浏览器用户直接选用。目前已有 1522 人学习下载资源虽小但内容完整清晰适合遇到 Stack Overflow 访问缓慢问题的开发者快速部署使用能够明显改善日常浏览与检索体验。 上周一个老同事发消息给我说公司新上的报表后台打开一直是白屏转几圈后出来一堆没有样式的文字控制台里全是红色报错。我远程看了一眼问题很典型页面里引用的几个JS库、字体文件全部挂在ajax.googleapis.com、fonts.googleapis.com上这些请求在网络环境不理想的情况下要么一直pending要么直接net::ERR_FAILED。这就是经典的Google CDN 拖垮页面问题。Replace Google CDN 这类小工具专治这种资源挂在外网 CDN 上导致页面半残的场景。这篇文章我会从项目背后的替换逻辑讲起把它常用做法、镜像源选择、容易翻车的几个细节全部过一遍供遇到同类问题的朋友参考。1. 先搞懂网页为什么会卡在Google CDN上1.1 哪些站点在悄悄依赖Google CDN很多网站并不是开发者主动想用 Google CDN而是被上游模板、开源项目顺手带进来的。最典型的几个来源WordPress 主题大量付费和免费主题默认加载 Google Fonts用于渲染字体样式。开源后台模板许多管理后台、博客程序默认引用ajax.googleapis.com/ajax/libs/...路径下的 jQuery、AngularJS、Bootstrap。富文本编辑器、图表库不少第三方插件把依赖直接写死为 Google Hosted Libraries没有做本地化处理。统计、验证类组件部分站点还嵌入了 Google Analytics、reCAPTCHA 相关脚本这类请求往往还带有额外参数失败后前端会静默降级但某些页面功能会直接失效。这些资源有一个共同点它们都是页面渲染的关键路径资源。JS 库位于head中且没有async或defer时浏览器会阻塞解析直到下载并执行完毕。如果这个下载请求迟迟不返回页面就一直白屏。字体资源虽然不阻塞 HTML 解析但会导致文字迟迟不显示正确字体出现无样式文字闪烁。1.2 请求失败后页面到底经历了什么一次外部 CDN 请求失败浏览器通常不是立刻放弃而是会经历 DNS 解析、TCP 连接、TLS 握手、发送请求、等待响应等一系列步骤。默认超时时间在数十秒级别TCP 连接还会做多次重试这就是为什么用户感觉转圈转了很久。等超时结束后页面通常呈现以下状态script标签加载失败依赖该库的后续代码全部抛异常页面交互功能大面积失效。link样式加载失败页面回到无样式的裸 HTML布局错乱。字体加载失败浏览器回退到系统字体但很多主题的字号、字重是针对特定字体设计的观感差距很大。异步统计脚本失败一般不影响主流程但数据分析链路断裂对运营有影响。更麻烦的是这种情况往往是间歇性的。同一个请求某些网络环境下几毫秒就返回了另一些环境下几十秒超时。于是这类问题很难稳定复现容易被打上玄学标签。1.3 为什么线上问题总是反复出现核心原因是开发者本地网络正常和用户网络环境异常之间存在信息差。开发者在办公室或家里访问站点外部 CDN 资源几乎是秒开根本不会意识到依赖了外网资源。等用户报障时用开发者工具一看又全是OK。这种问题在内部系统、面向特定地区的业务站点上尤其常见。Replace Google CDN 这类工具解决的正是这个最后一环它不要求你改源码也不要求你切换服务器只要在浏览器端把写死的 Google CDN 地址替换成更稳定的镜像地址就能让页面正常加载。理解了问题成因再看它内部的替换逻辑就顺理成章了。2. Replace Google CDN的替换逻辑从URL改写说到请求拦截2.1 一张域名映射表做掉80%的事Replace Google CDN 的核心逻辑并不复杂本质上就是维护一张域名映射表原域名替换目标用途ajax.googleapis.com镜像站相同路径JS 库文件fonts.googleapis.com镜像站相同路径字体样式 CSSfonts.gstatic.com镜像站相同路径字体文件storage.googleapis.com镜像站或本地路径部分静态资源www.gstatic.com镜像站或本地路径通用静态资源替换时只换域名不换路径和参数。比如https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js https://cdn.bootcdn.net/ajax/libs/jquery/3.6.0/jquery.min.js这种规则的好处是保留了原生路径结构镜像站只要按照 Google 的目录结构同步文件替换后就能直接走通。多数公共镜像都支持这种路径兼容方式。2.2 静态改代码与运行时拦截是两条完全不同的路处理外部依赖最正规的做法是从源码层面解决把所有第三方库下载到本地或者改成在构建时引用国内 CDN。但这对普通用户不现实你不可能给访问的每个网站改代码。所以工具通常走第二条路运行时拦截请求。运行时拦截在浏览器端有几种实现方式浏览器扩展通过chrome.webRequest或declarativeNetRequest监听请求命中规则后重定向到镜像地址。优点是工具对页面完全透明页面代码感知不到变化。用户脚本配合 Tampermonkey、Violentmonkey 等脚本管理器在页面加载早期注入脚本。可以改写页面中的静态标签也可以拦截XMLHttpRequest和fetch灵活性更高。Service Worker注册一个fetch事件处理函数对请求 URL 做映射后返回镜像响应粒度可以做得非常细。其中扩展的declarativeNetRequest方式效率最高因为重定向规则由浏览器底层执行不需要往页面里注入 JS。但写起来限制也多某些条件下不支持动态修改请求头。用户脚本虽然优雅度略差但胜在规则灵活修改即时生效是很多前端开发者调试时的首选。2.3 为什么多数在线工具选择浏览器扩展路线如果你要替换的是别人网站上的资源服务端方案基本不可行因为你不掌握别人的服务器。浏览器扩展则是以用户身份运行的最外层翻译官它不需要站点配合也不需要服务器。用户装上扩展后访问任意站点时只要请求命中规则就会被重写覆盖面是全网所有页面。这也解释了为什么这个项目常被打包成 zip 文件分发——zip 解压后加载到浏览器扩展管理页即可使用。相比上架应用商店zip 分发省掉了审核流程用户也能直接看到扩展源码对很多注重透明度的开发者来说反而是加分项。2.4 路径和query参数必须原样保留替换规则里最容易忽略的是 query 参数。Google Fonts 的 CSS 请求长这样https://fonts.googleapis.com/css2?familyRoboto:wght400;700displayswap替换域名后family、display这些参数必须原样保留否则镜像返回不了对应的字体子集。同理ajax.googleapis.com/ajax/libs/...路径中ajax/libs这部分也不能改动镜像站的目录结构依赖它做映射。如果替换逻辑把整个 URL 重新拼了一遍很容易丢参数。一个比较稳妥的写法是只替换 URL 中的域名部分其余内容不动。遇到完整 URL 时用 URL 对象解析只改host字段再拼回去这样能最大程度避免误伤路径和参数。3. 实操落地三种替换方式与镜像源选择3.1 拿到zip包后怎么装你拿到的Replace Google CDN.zip解压后通常是一个扩展目录里面包含manifest.json、JS 脚本、图标等文件。安装步骤解压 zip 到本地一个固定目录不要删。打开 Chrome/Edge 的扩展管理页地址栏输入chrome://extensions/或edge://extensions/。打开右上角的开发者模式开关。点击加载已解压的扩展程序选择刚才解压的目录。扩展列表出现后建议顺手固定到工具栏方便查看当前页面的替换命中情况。安装后可以先在扩展的规则页里确认要启用哪些替换项。通常默认全开但如果你只关心 JS 库而不管字体可以把字体项关掉减少误替换风险。3.2 用用户脚本做更细粒度的规则如果你不想装扩展或者扩展的规则满足不了需求可以用 Tampermonkey 用户脚本的方式。写一个最简单的规则脚本// UserScript // name Google CDN Replacer // namespace local.cdn.replacer // match *://*/* // run-at document-start // grant none // /UserScript const RULES [ { from: ajax.googleapis.com/ajax/libs, to: cdn.bootcdn.net/ajax/libs } ]; function replaceResourceUrl(url) { if (!url) return url; for (const rule of RULES) { if (url.includes(rule.from)) { return url.replace(rule.from, rule.to); } } return url; } const originalCreateElement document.createElement.bind(document); document.createElement function (tagName, options) { const el originalCreateElement(tagName, options); if (tagName.toLowerCase() script) { const originalSetAttribute el.setAttribute.bind(el); el.setAttribute function (name, value) { if (name src) { value replaceResourceUrl(value); } return originalSetAttribute(name, value); }; } return el; }; new MutationObserver((mutations) { for (const mutation of mutations) { for (const node of mutation.addedNodes) { if (node.nodeType ! 1) continue; const scripts node.querySelectorAll ? node.querySelectorAll(script[src], link[href]) : []; scripts.forEach((el) { if (el.tagName SCRIPT el.src) { const replaced replaceResourceUrl(el.src); if (replaced ! el.src) el.src replaced; } if (el.tagName LINK el.href) { const replaced replaceResourceUrl(el.href); if (replaced ! el.href) el.href replaced; } }); } } }).observe(document.documentElement, { childList: true, subtree: true });这个脚本做了三件事重写createElement、监听 DOM 变化、对新增的script和link标签做 URL 替换。对于大部分由运行时插入的资源基本都能覆盖。如果你是普通用户而不是开发者不建议直接抄这段脚本优先用现成扩展就好。3.3 服务端接入层替换思路如果你管着一台服务器又希望让整个内网的用户都受益可以在接入层做统一替换。以 nginx 为例思路是碰到ajax.googleapis.com的请求时rewrite掉原 host然后回源到国内镜像。或者直接用proxy_pass把对应路径转发到镜像站。这种方案的优点是浏览器端零配置缺点是镜像站如果挂了所有请求跟着挂所以务必配置超时和 failover。此外服务端替换要考虑 TLS 证书、回源带宽、日志记录等问题适合有一定运维基础的人。3.4 镜像源怎么选镜像源的选择直接决定替换后的体验。我整理了一份常用公共库的对比镜像名覆盖库范围HTTPS国内访问速度维护情况BootCDN常用前端库路径兼容较好支持快社区维护更新及时字节跳动静态资源库覆盖多曾提供Google库镜像支持快大厂维护Staticfile常用库覆盖较广支持较快社区维护jsDelivr依托 npm/GitHub覆盖极广支持时有波动独立组织维护unpkg严格对应 npm 包支持视网络而定独立维护选择原则我总结了四条先验证目标库和版本在镜像上确实存在。很多镜像只同步了常用版本冷门版本经常缺。优先支持 HTTPS。现代站点基本都是 HTTPS镜像不支持 HTTPS 会导致混合内容被浏览器拦截。关注 CORS 响应头。部分场景需要跨域读取资源比如 Canvas 绘制、模块加载镜像必须返回正确的Access-Control-Allow-Origin。不要只盯一个镜像。我见过 BootCDN 某个库临时抽风的情况所以规则里最好给同一资源配多个后备镜像。4. 替换后最容易翻车的三个坑4.1 SRI完整性校验会把替换后的脚本当场拦下SRISubresource Integrity是很多安全要求高的站点给外部脚本加的一道锁。比如页面里写的是script srchttps://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js integritysha384-... /script浏览器会计算下载内容的哈希跟integrity里的值比对不一致就拒绝执行。问题在于很多镜像为了压缩或统一出口对文件做了二次处理导致内容和原文件哈希对不上。扩展虽然把请求地址替换成了镜像但integrity属性还在浏览器校验不过脚本照样不会执行。排查方法很简单打开控制台看有没有类似Failed to find a valid digest in the integrity attribute的报错。解决思路有三种在替换规则里同时删除integrity属性。提前把镜像文件的哈希算出来写进自定义规则。如果站点是你自己的直接改用构建阶段本地化不要再依赖外部 SRI。个人建议是第二种最稳既保留了完整性校验又不会因为替换导致校验失败。4.2 字体文件路径和CORS问题比想象中多替换 Google Fonts 时如果只把fonts.googleapis.com换掉而 CSS 文件里font-face指向的fonts.gstatic.com没有被替换那么字体文件依然会去原域名请求。轻则加载慢重则字体彻底加载失败。所以字体相关的替换必须同时覆盖fonts.googleapis.com和fonts.gstatic.com两个域名。另一个隐蔽问题是 CORS。字体文件在真正被绘制前浏览器会做跨域检查。如果镜像响应头里没有Access-Control-Allow-Origin那么控制台会报字体跨域错误常见于某些不规范的公共镜像。遇到这种情况优先换一个支持 CORS 的镜像而不是自己去写复杂的绕过逻辑。4.3 动态插入的脚本经常被漏掉SPA 应用里脚本加载比传统页面复杂得多。很多库是路由切换时才通过动态import()或appendChild插入script标签的。如果替换逻辑只处理页面初始 HTML 里的标签那这些运行时请求全部会走原地址替换效果大打折扣。处理这类情况需要在页面初始化阶段就注册好MutationObserver监听所有新增的script和link标签。同时建议重写createElement的setAttribute因为有些框架会在创建元素后通过setAttribute设置src常规的 DOM 监听不一定能及时捕获到。这也是我前面脚本示例里同时做两层兜底的原因。4.4 建议维护一份站点名单不要对全网所有站点一律开启替换。有些大站已经自建了 CDN第三方资源走的是自己的加速域名有些页面虽然引用了 Google CDN 地址但已经加了 SRI 兜底逻辑还有些镜像上的文件版本偏老替换后反而会引发兼容问题。我在实际使用中会维护一份名单明确需要对哪些域名启用替换哪些域名直接跳过。这个名单随用随调线上遇到问题半小时内就能定位到是不是替换规则误伤。工具是死的规则是活的别让一个救火工具变成新的纵火源。5. 从替换到自救长期更稳的资源本地化方案5.1 如果你是站点管理员请从构建期解决问题Replace Google CDN 这类工具解决的是客户端问题但对于你运营的站点来说它只是临时止血。长期方案是构建期就把第三方依赖全部收敛用 npm 或 yarn 安装前端依赖构建时统一打包到本地静态目录。如果需要走 CDN选一个稳定的国内公共库并把版本号固定好。打包后的静态资源加上内容哈希配合长期缓存策略整体加载速度反而优于逐个请求外部 CDN。这样做的好处是彻底摆脱对外部 CDN 的运行时依赖也不需要考虑镜像同步、SRI 冲突、CORS 这些问题。代价只是首次构建配置稍微多花点时间但对站点稳定性的提升非常明显。5.2 如果你是普通用户可以试试Service Worker兜底Service Worker 是另一个值得关注的思路。注册一个fetch事件处理函数当页面请求第三方 CDN 资源失败时从本地缓存或离线包里返回同名资源。这个方案比通用替换更智能它只在原请求失败时介入正常访问时完全不影响性能相当于给页面加了一层保险。实现上也没有想象中复杂先把常用库的静态文件缓存到 Cache Storage然后在fetch事件里对匹配的 URL 做event.respondWith先尝试网络请求失败后再从缓存读取。相比扩展方案Service Worker 的优势是它跟随站点部署所有访问该站点的用户都能受益但前提是你需要对站点有控制权。5.3 根据个人经验给出三条建议第一临时访问别人站点时用浏览器扩展或用户脚本替换即可重点关注 JS 库和字体两个大类其他资源不必贪多。第二长期维护自己的站点时老老实实做构建期本地化不要指望所有用户都会装替换工具。第三不管用哪种方案都要留一条验证路径打开控制台确认替换后资源请求的Name列已经指向镜像域名同时观察有没有 SRI 或 CORS 报错。最后分享一个小技巧在规则里给每种资源配置两个镜像第一个镜像超时超过 3 秒就自动切换第二个。别小看这个设置我靠它在一次镜像源故障中硬是没让线上页面出现白屏。工具的价值从来不是让你守着它而是让你关键时刻能腾出手来解决真正的问题。本文还有配套的精品资源点击获取