如何为指定网站单独设置CPU性能限制？
功能定位：为什么想给“某个网站”单独限CPU？
Chrome 的多进程沙盒里，一个标签页即一条渲染进程。当网页狂刷 WebGL、WebAssembly 或后台挖矿脚本时，整条进程会吃掉单核甚至多核资源，风扇骤起、电量暴跌。Chrome 128 虽已内置 Memory Saver 与 Battery Saver，但策略粒度只到“后台冻结”与“全局节能”，无法把“特定站点”与“CPU 上限”绑定。于是出现两类诉求：① 企业 IT 想给内部 OA 站点留足算力，把娱乐站点压到 20 % 以下；② 个人用户直播推流时，防止某个媒体站突然抢占导致帧率跳水。本文给出“官方能点到哪”与“必须靠外援”的完整路径，并告诉你每种做法的副作用与回退方式。
先确认：Chrome 原生真的做不到？
截至当前最新版本，Chrome 没有“站点→CPU 配额”这一栏。任务管理器（Shift+Esc）只能查看或手动降低优先级，无法预设数值；Enterprise Core 策略里也没有“渲染进程 CPU 上限”字段。结论：想“自动化、量化”必须借助操作系统级手段或容器沙盒，浏览器本身只提供“杀进程”与“降优先级”两种半手动操作。
方案一：利用 Chrome 任务管理器“临时降优先级”
操作步骤（Windows / macOS / Linux 通用）
- 在目标站点标签页激活状态下，按 Shift+Esc 调出 Chrome 内置任务管理器。
- 找到“Task”列里对应标题的进程，通常显示为“Tab: 网站标题”。
- 右键 → 选择“降低优先级”（Lower priority）。此时操作系统会把该进程放入 Below Normal 队列，CPU 调度权重下降。
- 若发现页面卡顿过度，在同一窗口再次右键“恢复正常优先级”即可回退。
适用场景与边界
适合“临时直播”“线上会议”场景，手动把娱乐站压下去，会议结束即恢复。缺点：① 只能降权，无法设硬上限；② 重启浏览器后失效；③ 若站点跨域开新进程（如 iframe 嵌入另一个源），需要逐个手动降权。
方案二：Windows 组策略 + Job Object 给进程硬封顶
思路
利用 Windows Job Object API，把“所有匹配命令行含特定站点域名”的渲染进程收进同一作业，再分配 CPU Rate 控制。可写成 50 MB 的便携 C 小程序，也可用开源工具“Process Governor”。
最小可复现步骤
- 安装 Process Governor（GitHub 可下载，MIT 协议）。
- 为 Chrome 创建批处理：
pgov.exe --cpu 30 --chrome-match "*bilibili.com*"
- 先启动批处理，再打开 Chrome。任何命令行包含 bilibili.com 的渲染进程都会被压到 30 % 单核上限。
- 回退：关闭 pgov 控制台即解除限制，无需重启浏览器。
警告
Job Object 与某些杀毒软件钩子冲突，可能触发 Chrome 的“进程崩溃”保护。若出现反复重启标签，请把 pgov 加入杀软白名单或改用方案三。
方案三：Linux cgroups v2（systemd-run）单站限速
操作路径
- 创建切片单元：
systemd-run --uid=$USER --slice=limit_site --unit=chrome_throttle \ --property=CPUQuota=30% \ /usr/bin/google-chrome-stable --app=https://example.com
- Chrome 将以独立 slice 运行，CPU 被硬限制在 30 %。
- 如需同时开多站，可写 systemd 模板，参数化 %i 对应域名。
经验性观察
在 8 线程笔记本上，30 % 配额≈2.4 核，后台跑 WebGL 粒子 demo 时风扇噪音下降“一个数量级”；但页面帧率会掉到 15 FPS 左右，不适合交互游戏场景。
方案四：macOS 的 “App Police” 或 “cputhrottle”
macOS 无官方作业对象，可借助开源小工具 cputhrottle（签名后运行）。示例：找到渲染进程 PID，执行 sudo cputhrottle PID 30，即把该进程压到 30 %。回退：Ctrl-C 即解除。注意：macOS 的 SIP 会阻止对系统级进程的 attach，但对用户态的 Chrome 渲染进程有效。
方案五：容器化 Chrome（Docker + --cpus）
场景映射
公司运维想给“内部 ERP”和“公共资讯站”各分配 0.5 核与 0.2 核，且互不干扰。可打包官方 chrome:stable 镜像，写两条 docker-run 脚本：
# ERP 容器 docker run -d --cpus="0.5" --name chrome_erp \ -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=$DISPLAY \ chrome:stable --app=https://erp.corp.com # 资讯容器 docker run -d --cpus="0.2" --name chrome_news \ chrome:stable --app=https://news.example.com
优点与代价
硬隔离、可横向扩展、快照回滚方便；代价是图形透传需配置 X11 或 Wayland，视频硬解可能失效，GPU 进程占用反而升高，需要实测权衡。
最佳实践清单：如何挑方案？
- 临时直播/会议 → 方案一（Shift+Esc 手动降优先级），零成本。
- Windows 办公机，需自动化 → 方案二（Process Governor），30 分钟可落地。
- Linux 机房批量部署 → 方案三（systemd cgroups），与现有配置管理（Ansible）无缝衔接。
- macOS 个人开发 → 方案四（cputhrottle），一条命令即可。
- 强隔离 + 审计需求 → 方案五（容器化），但需接受 GPU 透传损耗。
不适用场景与副作用
- 站点采用 Service Worker 离线推送：若 CPU 被压到 10 % 以下，后台同步可能超时，导致消息延迟“数分钟”。
- WebRTC 视频会议：限制 20 % 以下时，编码帧率骤降，对方画面出现马赛克。
- 多进程模型下，子框架（iframe）跨域会开新进程，需匹配多条规则，否则限制失效。
- 某些扩展（如安全沙箱）会注入额外进程，若未纳入同一作业，可能出现“母进程被限、子进程跑满”的跷跷板效应。
验证与观测方法
- 浏览器内：Shift+Esc 看“CPU”列，确认数值是否落在配额附近（允许 ±5 % 抖动）。
- 系统级：Windows 用 perfmon，Linux 用 systemd-cgtop，macOS 用 top -p PID，观察“%CPU”是否被钳住。
- 压力测试：在受限标签打开 WebGL Ocean (Three.js) 演示，记录帧率；经验性观察，30 % 单核配额下帧率约掉 40–50 %，可接受办公场景，不可接受游戏。
FAQ（结构化数据）
Chrome 以后会不会原生支持站点级 CPU 上限？
截至目前最新版本，官方公开文档与 Chromium 日志中均未提及该特性；企业策略也未出现相关字段。若未来落地，预计先以实验 flag 形式出现，可关注 chrome://flags#site-cpu-limit。
限制后页面卡死，如何快速恢复？
Windows/Linux 关闭对应控制脚本或 systemd 单元即可；macOS 在终端 Ctrl-C 退出 cputhrottle；Chrome 内部可直接 Shift+Esc 杀进程，刷新后自动重生。
笔记本节能模式与 CPU 限制叠加吗？
会叠加。Battery Saver 先把后台标签冻结，若前台标签再被外部 Job Object 限制，可能出现“双杀”导致页面假死；建议两者二选一，或把配额放宽到 40 % 以上。
结论与下一步行动
Chrome 自身尚未开放“站点级 CPU 配额”接口，真正的硬上限只能依赖操作系统级工具。临时救急用 Shift+Esc 降优先级；长期方案根据平台选 Process Governor、systemd、cgroups 或容器化，并记得留 5–10 % 余量防止页面卡死。部署后务必用浏览器任务管理器与系统监视器交叉验证，发现异常立即回退。下一步，可把脚本封装成开机服务，结合域名白名单自动匹配，就能在“性能”与“体验”之间取得可量化、可撤销的平衡。