浏览器容器资源限制：实用规划方法
为容器化浏览器工作负载规划 CPU 与内存限制，同时区分容量信号、浏览器身份和隐私边界。
BotBrowser Team
容器限制回答的是运维问题：这个浏览器工作负载最多可以消耗多少 CPU 和内存？它不能回答浏览器是否隐私、安全，也不能说明两个会话是否属于不同的人，更不能保证每台宿主机上的页面行为都相同。可靠的规划要把这些问题分开。
BotBrowser 可以在声明的 Profile、版本、路由和平台条件下重复经过授权的工作负载，并比较资源预算下可见的结果。它不能分配宿主机容量、保证吞吐量、削弱浏览器隔离，或根据资源行为推断个人身份。
先定义浏览器工作负载
不要从偏好的容器大小开始，而要从声明的工作负载开始。记录浏览器版本、Profile 类别、页面或自有测试路由、导航步骤、预期完成状态、并发量、存储策略，以及是否涉及图形或媒体。纯文本页面和图形密集页面即使使用同一镜像，也可能有不同的内存曲线。
观察范围要有边界。只记录能支持运维决定的字段：启动成功、页面完成、CPU 压力、内存压力、队列延迟，以及 worker 关闭后的恢复。资源观察不是指纹结论。若粗粒度的通过/失败和声明预算已经足够，就不要保留原始浏览器转储。对于浏览器自动化，还要预先说明什么算完成。页面显示外壳但没有到达自有测试断言，不算成功；如果队列仍有余量，较慢但完成的结果可能可以接受。测量前写清这个标准，才能把容量决定绑定到用户可见行为，而不是单个进程计数器。测试路由应当是自有的合成路由，记录也不需要私人业务流量。
使用预算决策表
根据实际要运行的工作负载和并发量选择起始预算。下表是规划工具，不是普适的容量保证。
| 工作负载信号 | 首个决定 | 增加并发前重新检查 |
|---|---|---|
| 轻量文档，一到两个会话，完成稳定 | 从较小且有界的 CPU 与内存请求开始，为宿主机留下余量 | 浏览器版本或页面变化后重复测量 |
| 多个页面并发，队列延迟上升 | 暂停并发增加，测量整个容器而不是单个标签页 | 检查内存斜率、CPU 节流和关闭后的恢复 |
| 媒体或图形密集页面反复产生压力 | 降低准入量或拆分工作负载类别 | 确认共享内存、图形策略和优雅关闭 |
| 内存限制在完成前触发 | 停止接收新任务，保留失败工作负载记录 | 使用合成数据复现并设置新预算后才增加限制 |
选择规则很直接：如果预期结果不能在声明预算内完成，就先降低准入量或改变工作负载类别，再考虑提高限制。更大的限制可能只是掩盖泄漏或无界队列。为浏览器启动、短时 worker、共享内存和维持容器运行的宿主机服务保留余量。余量不是固定百分比，应由选定运行点的重复测量说明。浏览器或镜像更新后余量消失，应视为容量变化并重新比较，而不是静默接受更紧的边界。
区分容器限制与浏览器信号
Docker 和 Kubernetes 提供的是容器或 Pod 级别的资源控制。浏览器 API（例如 navigator.hardwareConcurrency）向页面提供环境提示，它不是容器剩余容量的测量。两者都应被视为上下文而不是身份。同一个提示值并不意味着调度器没有节流，两个容器也可能拥有不同限制。
隐私边界同样重要。如果记录同时保存稳定的资源提示、Profile 标签、路由细节和时间戳，即使每个字段看起来无害，也可能形成可关联组合。保留版本、工作负载类别和预算决定，删除不必要的原始值和标识符。像审查浏览器存储一样审查保留期和访问权限。
监控压力并有计划地恢复
监控整个浏览器组：浏览器进程、共享内存、图形缓冲区、网络池，以及容器的 CPU 和内存计数器。单个标签页的数字有助于诊断，但不是容量合同。记录 worker 启动、达到预期结果、关闭，以及释放足够压力让下一批有界任务运行的时间点。
按固定顺序采取优雅动作：停止接收新任务，完成或取消自有旅程，关闭浏览器上下文，并记录结果。如果压力没有恢复，保留最小可复现工作负载并停止容器，而不是反复重试。这样可以保护宿主机，也让证据保持可解释。
用边界进行 BotBrowser 比较
比较两个经过授权的 BotBrowser 版本时，固定 Profile、路由、工作负载、容器限制和并发量。比较可见结果和声明的资源观察，并写明条件与限制。差异只能支持特定版本的后续调查，不能证明内核原因、普遍性能或用户身份。
交接记录至少应包含：工作负载版本、浏览器版本、Profile 类别、CPU 和内存预算、并发量、观察结果、不确定性、保留决定和下一步有界动作。这样其他运维人员可以重复决定，而不需要接触私人载荷或检测器配方。
来源
相关阅读：Docker 浏览器部署指南 和 BrowserContext 容量规划。
当服务迁移到不同区域或宿主机类别时，保持路由和浏览器版本不变，只改变一个基础设施变量并重复有界旅程。大宿主机上的余量并不证明小宿主机有缺陷。把宿主机类别作为条件记录，并选择匹配实际部署的预算。记录下一步动作的负责人，避免因为没人知道谁能行动而扩大隐私敏感记录的传播。
用其他团队可以重复的步骤描述旅程，并预先写明可见的完成标准。
从较小并发开始，观察关闭和恢复后再逐步增加。
记录压力出现的阶段：启动、稳定运行、队列还是关闭。
把编排器请求、容器限制和应用超时分开记录。
有界队列可以保护宿主机，并避免重复重试扩大保留状态。
镜像、Profile 或路由变化后，用同一合成负载重新比较。
大宿主机上的结果不等于普遍容量。
只保留会改变准入决定的粗粒度测量。
如果路由类别已经足够，就不要保存页面文本、账户标识和完整地址。
为准入、镜像、路由或恢复动作指定下一步负责人。
资源差异不能证明内核原因，也不能识别个人。
触发限制时，先保留最小可复现案例，再改变预算。
关闭上下文后的恢复是独立于页面完成的检查。
精确值不再影响运维时，应重新审查保留策略。
BotBrowser 可以在声明条件下重复授权观察，但不会分配宿主机容量。
这个运维合同让比较保持有用，也避免建立多余的信号清单。