直接用 selenium 启动 200 个 chrome 实例进行并发用户模拟，会导致极高的内存与 cpu 开销，且违背其设计初衷；官方明确不推荐用于性能测试，更优解是采用 jmeter 等专用负载工具，并通过合理配置模拟真实浏览器行为。
在实际自动化测试或负载模拟场景中，开发者常误将 Selenium 当作“高并发用户生成器”——例如通过多线程循环创建 ChromeDriver 实例来模拟 200 个独立登录会话。但这一做法存在根本性瓶颈：每个 Chrome 浏览器实例（即使 headless）均需独占约 1–2 GB 内存与 1 个逻辑 CPU 核心。Firefox 109 官方系统要求已明确标注“每实例需 2 GB RAM + 1 CPU”，而 Chrome 实际开销通常更高。这意味着 200 个并行 WebDriver 实例将轻易耗尽数十 GB 内存与全部 CPU 资源，不仅不可扩展，还会因操作系统调度压力导致响应延迟失真，完全丧失测试可信度。
更关键的是，Selenium 的定位是端到端 UI 功能验证，而非性能/负载测试。Selenium 官方文档明确指出：“Selenium is not designed for performance testing”，其核心价值在于精确操控 DOM、验证交互逻辑与视觉反馈，而非高效复现海量用户请求流。
✅ 正确的技术选型：Apache JMeter
JMeter 是专为可扩展负载测试设计的开源工具，具备以下不可替代优势：
- 极低资源占用：单机可轻松模拟数千并发用户（线程），内存消耗通常仅数百 MB；
- 协议级精准控制：通过 HTTP Request 取样器发送标准 HTTP(S) 请求，配合 Cookie Manager、HTTP Cache Manager、User-Agent 配置等，能高度还原浏览器行为（如会话保持、资源缓存、AJAX 异步调用）；
- 真实场景建模能力：支持 Think Time（随机停顿）、事务控制器（模拟完整登录→操作→登出流程）、JSON Path 提取器（解析登录响应中的 token）、JSR223 断言（校验业务逻辑）等；
- 分布式执行支持：可通过 Master-Slave 架构横向扩展至数万并发，远超单机浏览器实例极限。
? 示例：用 JMeter 模拟带登录态的用户操作
Thread Group (200 Threads, Ramp-up 60s)
├── HTTP Request: POST /login → 提交用户名/密码
├── JSON Extractor: 提取响应中的 "session_id" 或 "access_token"
├── HTTP Header Manager: 添加 Authorization: Bearer ${token}
├── HTTP Request: GET /dashboard → 访问受保护页面
├── Response Assertion: 检查返回状态码=200 且包含 "Welcome"
└── Constant Timer: 设置 2–5 秒随机思考时间（模拟真实用户）⚠️ 注意事项：
- 避免在 JMeter 中滥用“Browser Simulation”插件（如 WebDriver Sampler）——它本质仍是启动真实浏览器，会重蹈 Selenium 资源困境；仅在必须验证前端 JS 行为或 Canvas 渲染等无法绕过 UI 的极少数场景下谨慎使用。
- 所有接口需确保服务端未强制校验 User-Agent 或 Referer 等头信息，否则需在 JMeter 中显式配置（HTTP Header Manager）。
- 生产环境压测前，务必在测试环境完成全链路验证，并监控服务端指标（CPU、GC、DB 连接池、慢 SQL）而非仅关注响应时间。
总结：追求 200+ 并发用户模拟时，请果断放弃多 WebDriver 实例方案。以 JMeter 为核心，辅以合理的协议层建模与监控体系，才能实现轻量、稳定、可重复、可扩展的高性能负载测试。真正的“轻量高效”，源于工具选型的正确性，而非对错误方案的参数微调。
