Chromium 151 BrowserContext 内存容量规划

容量问题发生了变化

很多自动化服务会让一个浏览器组承载大量活动 BrowserContext。每个上下文保留自己的存储和应用会话，同时共享浏览器启动带来的开销。这种安排可以节省重复工作，但上下文成本不仅取决于页面，也取决于浏览器版本。

从 151.0.7922.108 起的部分 Chromium 151 构建，在 headless 或自动化并且同时保持很多上下文时，基线内存会更高。一个活跃上下文可能伴随一个额外的浏览器 UI renderer，它服务于浏览器自身界面。因此，即使页面没有变化，内存也会随着活跃上下文数量增加。

这不是对所有 Chromium 构建或所有操作系统的断言。相同版本系列的维护构建可能不同，Linux x64 也只是一种对照环境。请在实际 release、主机、配置文件策略和工作负载上测量，本文数字只表示示例量级。

如何理解对照数字

在一次 Linux x64 对照中，151.0.7922.76 的该工作负载没有看到额外的 omnibox UI renderer，约为每个活跃上下文 120 MB。151.0.7922.138 的对照看到了额外 renderer，约为每个活跃上下文 289 MB。具体环境中每上下文约相差 169 MB。额外 renderer 在这些示例中通常约为 250 到 280 MB。

这些数字不是所有工作负载的承诺。媒体、文档、下载、脚本 worker 和大型应用都会改变成本。还要单独计算浏览器组共享内存。可以用“共享浏览器内存 + 活跃上下文数量 × 单上下文成本 + 工作负载波动”来组织测量，但不要把它当作通用计算器。

容量记录应说明主机、图形模式、配置文件策略、扩展、网络类别和任务类别。只有一个并发数字，版本变化后就无法解释。可以参考 BrowserContext 扩容指南，它涵盖队列、生命周期和隔离边界；本文增加的是 Chromium 151 的版本因素。

升级前检查

在推广维护构建前，记录浏览器版本、操作系统和架构、主机规格、容器限制、图形模式、配置文件策略、扩展、网络类别和代表性任务。使用相同镜像和相同任务，对当前批准版本与候选版本进行分阶段对照。

分别测量浏览器组空闲时、创建上下文时、稳定活动时、上下文空闲时和关闭之后的内存。记录组总量与活动上下文数量，观察单上下文成本的斜率。创建可能带来短时峰值，关闭也可能需要时间完成，因此清理完成前不要立刻把容量交回调度器。

已确认的行为不是永久泄漏：关闭上下文后，额外进程可以释放。但上下文只要常驻，成本就会常驻；如果创建速度超过关闭速度，主机仍可能先达到 OOM。观察可用内存、内存压力、CPU、创建和关闭延迟、队列等待、完成量及重启情况。

发布流程可参考 浏览器版本验证。使用身份隔离时，同时阅读 Per-Context 文档，确保内存调整没有改变批准的会话边界。

临时启动参数

对于受影响的 headless 或自动化工作负载，可以临时使用：

--disable-features=WebUIOmniboxPopup,WebUIOmniboxAimPopup

两个名称必须一起传。该设置只影响浏览器自己的地址栏 UI，不改变页面 JavaScript、DOM 或 CSS。headless 场景通常没有用户可见变化，因此在完成验证后可以作为短期容量措施。

另一个设置是：

--disable-features=PreloadTopChromeWebUI

它只能降低额外进程占用的内存，不能移除该进程，所以不是完整 workaround。未来 Chromium rollout 可能移除或忽略这些开关。启动后应观察实际内存，不要永久假定开关仍然有效。这不是 BotBrowser 独有修复，必须在目标版本、主机、配置文件和工作负载上复测。

用准入控制保护余量

从主机可用内存而非安装内存开始规划。为操作系统、监督服务、日志、网络服务、文件缓存、崩溃处理和创建峰值保留空间，再减去浏览器共享基线与工作负载波动，剩余才是活动上下文池。

达到上限后使用有界队列。新任务可以等待有限时间、收到容量响应或转到另一个批准的浏览器组。重试也要遵循同一限制，否则故障会在内存紧张时放大活动上下文数量。逐步创建上下文，避免一次启动整批任务。

创建上下文的服务应负责关闭、释放租约并确认清理。关闭超时就按策略排空并替换浏览器组，不要通过提高上限来掩盖资源所有权不明。更广泛的页面生命周期建议见 性能优化。

首次发布运行手册

发布前固定候选版本和主机类别，确认配置文件包与 Per-Context 策略已批准，并保留上一版本以便回退。发布时使用小规模部署组，观察组内存、活动上下文、可用内存、创建和关闭延迟、队列等待及完成量。若内存压力上升或清理落后，先暂停准入，再按生命周期规则排空受影响的组。

发布后确认关闭上下文确实释放额外进程，并检查主机回到预期恢复范围。不要只测最轻任务，也要检查媒体、下载、文档等类别。每次浏览器、主机、配置文件、页面、扩展、图形或网络变化后重新验证。可在 价格页面 查看计划容量，但计划限制与主机内存限制是不同约束。

Chromium 151 的 BrowserContext 容量应由测量得出。额外浏览器 UI renderer 是活跃上下文期间的真实成本，关闭上下文后的释放是有用的恢复特性，而临时参数只能在验证后使用。长期控制仍是保留恢复余量、版本感知的内存预算。