上个月我在处理一台旧笔记本时，实在被各种网页拖垮了性能——打开一个门户首页CPU就直接顶到100%，风扇像飞机起飞。排查了半天，真正的“凶手”其实是满屏的JavaScript脚本、广告SDK、埋点统计和自动播放组件。当时我就在想，要是能像防火墙一样，给Chrome里运行的JavaScript做一个黑白名单，该多省心。后来我确实做到了，而且发现方法不止一种。这篇文章就来系统说说：谷歌浏览器Chrome如何允许或禁止JavaScript运行？黑白名单怎么加？从原生设置、扩展插件、开发者工具到企业组策略，我会一层层讲透，最后附上我踩过的坑和处理方案。
1. 屏蔽 JavaScript 前，先搞清楚你失去了什么
1.1 JavaScript 对普通用户来说，等于网页的“手和脚”
JavaScript不是网页的全部代码，但它是让页面“活”起来的核心。HTML负责结构，CSS负责样式，JavaScript负责行为——按钮的点击反馈、表单的自动校验、无限滚动、轮播图、地图拖动、评论区展开、视频播放器的控制条，背后基本都是JS在跑。
理解这一点很重要，因为很多用户把“禁用JavaScript”当成一种清理网页的方式，结果发现页面瞬间变成了“毛坯房”。这不算配置错误，而是没有做好预期管理。禁用JS之后，你得到的东西和失去的东西都很明确。
从我实测的角度说，禁用JS后最常见的“失去”有这些：
- 绝大多数按钮点了没反应，尤其是一些传统网站用
javascript:void(0)做的假链接，点击后完全无响应； - 评论区分页失效，或者根本没有评论区；
- 表单提交后不会自动校验邮箱、手机号等格式；
- 部分视频网站无法播放视频，因为播放器本身靠JS加载；
- 网页乱码倒是不会发生，但排版可能稀碎，因为一些布局信息依赖JS计算后插入DOM。
1.2 禁用之后，你“得到”的东西更实在
禁用JavaScript带来的收益，在低配设备上特别明显：
- CPU占用率肉眼可见地下降，风扇不再狂转；
- 弹窗、悬浮提示、自动播放视频的概率大幅降低；
- 第三方统计脚本、广告追踪代码被挡在门外，隐私泄露面变小；
- 页面加载速度变快，对网速有限的场景帮助很大；
- 阅读体验更接近“读文档”，没有花哨动效分散注意力。
所以说，JavaScript本身不是坏东西，坏的是那些被塞进网页里的第三方脚本。这也是为什么我后来一直推荐“默认禁止，白名单放行”的模式，而不是“一刀切全部禁止”。
1.3 谁最适合用“全局禁用 + 白名单放行”
我试过几种组合后，觉得以下三类场景最适合这套策略：
- 老电脑、低配置办公机：这类机器内存和CPU捉襟见肘，禁用JS能让浏览器顺畅很多；
- 家长给孩子用电脑上网课：可以禁止绝大多数娱乐页面的动态脚本，减少干扰；
- 注重隐私的用户：很多追踪脚本本质是JavaScript，禁掉之后网站拿不到你的行为数据。
当然，如果你日常要使用复杂的在线表格、在线会议、专业SaaS后台，那就不建议全局禁JS了，最多用下面要说的黑名单模式，把确定有问题的站点拉黑。
2. Chrome 原生设置：三分钟配好全局限用与站点白名单
2.1 找到 JavaScript 设置入口
Chrome的JavaScript设置藏在站点设置里，最简单的打开方式是直接在地址栏输入：
chrome://settings/content/javascript也可以走菜单路径：点击右上角三个点 → 设置 → 隐私设置和安全性 → 站点设置 → JavaScript。
进入后，你会看到一个开关：“网站可以使用JavaScript”。这是Chrome的默认行为，即大多数站点都可以执行JS。
在这个页面上，往下拉还能看到两个列表：“不允许使用”和“允许使用”。这两个列表就是原生黑名单和白名单的雏形。
2.2 全局禁止 JavaScript，然后用白名单放行需要的网站
如果你想走“默认全部禁止，只信任少数站点”的路线，操作是这样的：
- 在
chrome://settings/content/javascript页面，把“网站可以使用JavaScript”开关关掉。这一步会让所有网站默认不能执行JS。 - 关闭后，页面会多出一个“允许”标签。点击旁边的“添加”，输入你要放行的网站域名。
- 保存后，刷新目标网站，JS就生效了。
这里要特别注意域名写法。直接写https://example.com/也可以，但只能匹配这个域名和路径，不一定能覆盖子域名。建议写成：
[*.]example.com这个写法匹配的是example.com本身和它的所有子域名，比如www.example.com、mail.example.com。如果某个网站有多个子域（像帮助中心、文档站和主站），这种匹配方式最实用。
2.3 保持全局开启，只屏蔽特定站点
如果你的诉求恰恰相反——大部分网站都要正常用JS，但个别网站总是弹窗、挖矿或者卡顿——那就用纯黑名单方案。
操作路径一样，在chrome://settings/content/javascript页面里，保持“网站可以使用JavaScript”开关开启，然后在下面的“不允许使用”区域点击“添加”，把问题站点填进去。这样除了这个黑名单里的域名，其他所有网站都能正常执行JS。
我的经验是，黑名单模式适合已经明确知道“哪个网站有问题”的情况，而白名单模式适合“我需要一个干净的浏览器，但没时间逐个排查网站”的情况。两者的使用场景不同，选哪个取决于你对浏览器的掌控需求。
2.4 URL 匹配模式语法：别把规则写错了
Chrome的站点例外不是正则表达式，它的语法有一定限制。我整理几个常用写法：
| 写法 | 匹配范围 |
|---|---|
https://example.com/* | 仅https协议下的example.com，所有路径 |
http://example.com/* | 仅http协议下的example.com |
[*.]example.com | example.com及其所有子域名，任意协议 |
*://example.com/* | example.com下任意协议、任意路径 |
http://localhost:* | 本地开发环境，常用于调试 |
最稳妥的写法是第一种或第三种。如果你不确定对方网站用http还是https，直接写[*.]example.com最省心。
2.5 修改之后需要刷新才生效
原生设置改完不会自动作用于已打开的标签页。你需要在修改后手动刷新页面，最好用硬刷新：Windows下按Ctrl + F5，Mac下按Cmd + Shift + R。
而且要注意：个别网站有Service Worker做缓存，硬刷新也不一定立刻反映最新状态。这种情况可以关掉标签页重新打开，或者在无痕模式下测试——无痕模式默认不继承站点的本地缓存，用来验证配置是否生效非常方便。
3. 比原生更细的控制：ScriptSafe 扩展怎么用才安心
3.1 原生限制：只能按域名整体开关，识别不了具体脚本
Chrome原生设置虽然能配白名单和黑名单，但它只能对“整个域名”生效。实际使用中问题很明显：很多网站的主站代码和安全验证必须要JS，但页面里混进来的统计脚本、广告SDK、埋点脚本是你不想要的。原生设置没法区分“这个页面的JS是必要的”还是“这个JS是想偷数据的”。
这时候就需要更细粒度的工具。我比较推荐的是ScriptSafe，它属于“前端脚本管理器”，原理上比原生设置更进一步：可以按页面拦截JS，也可以按域名放行，甚至能列出当前页面加载了哪些第三方脚本，让你一个个决定要不要放行。
3.2 ScriptSafe 的核心功能和使用逻辑
ScriptSafe 安装后，浏览器右上角会出现一个图标。点击图标，你会看到一个滑块式的控制界面：
阻止所有脚本：当前页面所有JS都不执行；允许/临时允许：把当前域名加入信任列表，或者仅本次会话放行；在学习模式中运行：它先不拦截，而是记录当前页面加载了哪些脚本，相当于“观察期”；在此网站上禁用扩展：某些网站功能复杂，一键排除。
我最常用的流程是：在某网站打开ScriptSafe，先切到“学习模式”，看它列出了哪些脚本来源，然后决定哪些要永久放行、哪些直接屏蔽。比如在线文档站点，我通常允许其主域名的脚本，但会拦截广告域名的脚本。
这个流程比原生“允许/禁止整个域名”精细得多，也是我想推荐的ScriptSafe核心价值所在。
3.3 配置经验：从“观察期”过渡到自己维护规则
刚装ScriptSafe时，建议不要直接全局阻止，而是用一两周的学习模式。理由很简单：你还不清楚自己常访问的网站哪些脚本是必须的。
以我的经验，常见必要脚本来源包括：
- 网站主域名自身的
/static/、/assets/等目录； - 在线支付平台的SDK（比如某些支付机构的校验脚本）；
- 页面本身引用的开源库，例如jQuery、Vue、React的CDN地址。
常见可拦截脚本来源包括：
- 广告联盟的域名；
- 第三方大数据统计平台；
- 用户行为追踪和热力图脚本；
- 视频平台自动播放相关脚本。
在观察期结束后，再切换到“阻止未知脚本”模式，把定期访问的网站加入白名单，就能形成一个比较稳定的黑白名单体系了。
3.4 扩展安全小提醒
这里必须多说一句：这类脚本管理扩展的权限很大，它能看到你访问的每一个页面发起的所有脚本请求。所以一定要选择开源、评价多、更新活跃的扩展，从Chrome网上应用店安装。别图省事去第三方网站下载“破解版crx”文件，那才是真的引狼入室。
另外，如果装了ScriptSafe之后发现某个网站功能异常，先别急着骂扩展，大概率是脚本被拦截了。点击扩展图标，把这个域名临时允许，刷新页面看是否恢复正常，然后再决定是永久加入白名单还是调整拦截规则。
3.5 同类工具怎么选
| 工具 | 核心定位 | 适用场景 | 备注 |
|---|---|---|---|
| ScriptSafe | 按脚本/域名控制JS | 普通用户精细管控 | 经典延续，配置直观 |
| uMatrix | 按请求类型、域名矩阵式控制 | 高级用户 | 已停止维护，但能跑 |
| NoScript | 按域名允许/阻止JS | 安全洁癖用户 | Chrome版功能受限 |
| Tampermonkey | 注入用户脚本，不是拦截器 | 想改网页行为，而非禁用 | 和黑白名单不是一回事 |
如果你只是想把“可疑脚本”挡住，ScriptSafe够用了。如果你已经懂得看Host资源、理解XHR和WebSocket请求类型，uMatrix会给你更细的矩阵控制权，但学习成本也更高。
4. 开发者工具：临时开关与自动化场景下的 JavaScript 控制
4.1 DevTools 里一条命令临时禁用 JS
有时候你并不想永久禁用JS，只是想看一眼“这个页面没有JS时长什么样”，或者排查某个页面加载缓慢是不是脚本拖累的。这种情况用Chrome开发者工具最省事。
操作很简单：
- 在当前页面按
F12或Ctrl + Shift + I打开开发者工具； - 按
Ctrl + Shift + P打开命令面板（Mac下是Cmd + Shift + P）； - 输入
Disable JavaScript； - 回车。
此时DevTools会提示“JavaScript已禁用”，当前标签页的JS会被停掉。刷新页面后会以无JS状态重新加载。
要恢复JS，再次打开命令面板，输入Enable JavaScript并回车即可。
这个方法的好处是快，而且它是会话级的，不影响全局设置，也不改浏览器配置。缺点是它只对当前标签页有效，而且你手动关掉DevTools并不会自动恢复JS，得重新打开DevTools敲一次命令。一句话：这是开发调试工具，不是日常管理工具。
4.2 CDP 与 Puppeteer：自动化场景下的 JS 启停
如果你有自动化需求——比如写爬虫、做页面性能测试、批量巡检业务系统——那就要走Chrome DevTools Protocol（CDP）这条路。Puppeteer是Node.js环境下最常用的库，启动一个无头Chrome实例，然后通过page.setJavaScriptEnabled(false)就能禁用JS。
典型的示例代码如下：
const puppeteer = require('puppeteer'); (async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); // 禁止当前页面执行 JavaScript await page.setJavaScriptEnabled(false); await page.goto('https://example.com', { waitUntil: 'domcontentloaded' }); const html = await page.content(); console.log(html); await browser.close(); })();这个方法在爬取依赖较少、内容以服务端渲染为主的站点时很好用：不用等几十个脚本加载完再解析，速度和稳定性都提升不少。做性能对比测试的时候也可以这样：同一个页面分别在启用/禁用了JS的情况下截图，对比首屏渲染耗时和布局差异。
4.3 一个网上流传但实测存疑的命令行参数
搜索“Chrome禁用JavaScript”时，很多教程会提到一个命令行参数：
chrome --disable-javascript这个说法在很老的Chrome版本里是成立的。但在我近两年的实测中，新版本的Chrome和Chromium内核对这个参数的响应很不可靠。我试过在Windows和Linux系统下启动，页面中的JS仍然能正常执行，也就是说这个参数在某些版本上已经失效或没有被正确传递。
所以别在这个参数上浪费时间了。如果真要命令行级别的控制，用Chrome DevTools Protocol或者Puppeteer，它们才是官方支持、行为稳定的方案。
5. 企业批量下发：用组策略管住一群浏览器的 JavaScript 权限
5.1 什么时候适用组策略
如果你管理着学校机房、公司内网电脑或者双人以上运维的公共终端，一台台去开chrome://settings配置是不现实的。这时候就需要用Chrome的企业策略，把JavaScript的允许/禁止规则批量下发到每一台机器上。
Chrome企业策略在Windows下走注册表，在macOS下走plist配置描述文件，在Linux下走JSON配置文件。我平时接触最多的是Windows注册表，就以它为例。
5.2 三个核心策略
这次真正要用的策略就三个：
DefaultJavaScriptSetting：全局默认值，1表示允许，2表示禁止；JavaScriptAllowedForUrls：允许执行JS的URL列表；JavaScriptBlockedForUrls：禁止执行JS的URL列表。
注意，这里的URL列表走的是Chrome的URL模式语法，同样支持[*.]example.com这类写法。以我的实际经验，JavaScriptBlockedForUrls的优先级要高于JavaScriptAllowedForUrls，也就是说，如果一个站点同时命中了允许和禁止规则，最终结果通常是禁止。所以配置时务必检查列表里有没有重复条目。
5.3 Windows 注册表配置示例
在Windows上执行以下命令，可以设置全局禁止JavaScript，然后为example.com及其子域名添加允许例外：
reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v "DefaultJavaScriptSetting" /t REG_DWORD /d 2 /f reg add "HKLM\SOFTWARE\Policies\Google\Chrome\JavaScriptAllowedForUrls" /v "1" /t REG_SZ /d "[*.]example.com" /f如果要对多个站点进行配置，再添加第二个值即可：
reg add "HKLM\SOFTWARE\Policies\Google\Chrome\JavaScriptAllowedForUrls" /v "2" /t REG_SZ /d "[*.]another-example.com" /f同理，禁止列表使用JavaScriptBlockedForUrls路径。注意：注册表修改后需要重启Chrome浏览器才生效，部分情况下还需要重启计算机才能让策略完全加载。
5.4 验证策略是否生效
配置完组策略，不验证可不行。在Chrome地址栏输入：
chrome://policy这里能看到当前浏览器拉取到的所有策略。如果DefaultJavaScriptSetting的值显示为“2”，同时JavaScriptAllowedForUrls列表里有你的站点，那说明策略已经生效。页面右上角还有一个“重新加载策略”按钮，修改完注册表之后可以点一下试试，不用反复重启浏览器。
5.5 企业版的额外提醒
企业策略不是用来保护浏览器的，它是用来“管理”浏览器的。如果你所在的单位机器已经由IT部门统一下发了策略，那本机用户在chrome://settings里折腾是没用的，最终解释权在策略手里。
我见过不少同事手动把JS关了，第二天开机又恢复原样，就是因为公司组策略强制覆盖了用户配置。如果你也遇到这种情况，别折腾设置页面了，直接看chrome://policy还有没有相关的强制项，或者找IT管理员沟通，别私自尝试绕过策略。
6. 实操中容易踩的坑和我的处置方法
6.1 通配符写错导致白名单失效
这是最常见的问题，没有之一。很多人第一次添加站点时，直接输入example.com，结果不生效。原因是Chrome的URL匹配规则要求写协议和路径，至少得是https://example.com/*这种完整形式。
如果懒得关心协议和子域名，直接写[*.]example.com最省事。记住一点：在Chrome的站点例外列表里，不是写example.com就一定能匹配到子域名的，也不是写*就万事大吉——*是模式里的通配符，要有协议前缀和域名结构，别把它当成正则表达式用。
6.2 页面“看起来没变化”的真正原因
有时候你明明已经把JS禁了，但打开目标网站，弹窗还在、脚本还在跑。这通常不是因为设置无效，而是因为：
- 页面被Service Worker缓存了：旧逻辑还在本地缓存里。处理方式是打开
chrome://serviceworker-internals/，按域名停掉对应的Service Worker，然后再刷新页面； - 浏览器扩展往页面注入了脚本：有些扩展（比如翻译插件、密码管理器、截图工具）会往页面里注入JS，这是扩展行为，跟网页脚本不是一回事；
- 页面开了预渲染或预加载：Chrome可能在后台已经把页面用旧配置加载了。关掉标签页，重新打开一次，或者用无痕窗口测试。
这一条排查经验在社区里流传不多，但几乎每次“设置不生效”都是这几个原因导致的。建议按顺序检查：先停Service Worker，再禁用近期安装的扩展试试，最后才怀疑是设置本身的问题。
6.3 某些“必要的JS”被误伤，页面直接不可用
有时你禁了某个域名的JS，结果发现这个网站的核心功能也挂了。典型的例子是在线客服聊天窗口、多因素认证页面、支付弹层、扫码登录等组件——它们虽然长得像“第三方的”，但业务上缺一不可。
我的建议是遇到这种页面，先在该域名下临时允许JS，然后开DevTools的Network面板，刷新页面看看到底加载了哪些脚本，把必要的脚本域名加入白名单，再恢复屏蔽。这个过程比一次性全局放行好得多，能保证页面功能完整，同时仍然拦掉大部分广告和追踪脚本。
6.4 装了“优化类”扩展，悄悄改回 JS 开关
有段时间我老是发现自己把JS全局禁用后，第二天又变成允许了。后来一查，原来是某款“一键清理”类浏览器扩展在后台执行了“恢复默认设置”。这类扩展的权限往往很大，它不仅会改你的搜索引擎和主页，还会顺手把你的内容设置重置掉。
排查方法很简单：在chrome://extensions页面把近期安装的扩展逐个禁用，然后重新配置JavaScript开关，再观察一两天，多半能定位到元凶。记住，不要装来源不明的“清理优化”类扩展，浏览器本身已经够安全了，外挂式优化反而容易引入不可控因素。
6.5 移动端 Chrome 没有直接的 JS 开关
最后补一个很多人问过的坑：Android和iOS版Chrome并没有像桌面版那样可以直接关闭JavaScript的开关。Android版在实验室标志里曾经有过一些相关选项，但官方从未把它做成稳定功能；iOS版受系统限制更严格，基本没有可配置性。
如果你在手机上也需要类似能力，目前可行方案是使用第三方浏览器，比如带内容拦截规则的浏览器，或者把特定网站交给内置广告拦截能力更强的浏览器处理。别指望在Chrome移动版设置里找到和桌面版一样的白名单功能。
6.6 怎么形成长期可维护的规则
经历了上面的各种坑之后，我现在维护黑白名单的原则很简单：宁可少加，不可滥加。每次遇到一个必须放行的网站，我在加白名单之前都会问自己三个问题——这个网站的JS是核心功能必需的吗？是否只允许主域名就够了？这个规则能否覆盖子域名而不会放得太宽？
如果答案都符合，才把它写入白名单。这样的管理方式看起来很保守，但长期下来规则列表非常干净，浏览器基本不会出现莫名奇妙被放行了一堆广告脚本的情况。如果你也打算用白名单模式管理JavaScript，这套思路同样适用——别看它慢，但稳定。
