Symfony Stopwatch 无法测量 Fiber 切换开销，因其仅记录显式 start/stop 的用户代码段，而 Fiber 挂起/恢复发生在 Zend 引擎底层，不触发 PHP 用户层钩子；应改用 hrtime 手动打点、Zend VM 调试统计、Xdebug/Blackfire 采样或基准对比来评估真实调度成本。
Symfony 的 Stopwatch 无法直接测量 Fiber 切换本身的开销。
Fiber 切换不在 Stopwatch 的观测范围内
Fiber 的挂起（fiber_suspend()）和恢复（fiber_resume()）是 Zend 引擎底层的协作式调度行为，不触发 PHP 用户层的函数调用、异常或事件钩子。Stopwatch 依赖 microtime(true) 或 hrtime() 打点，但它只能记录你显式调用 start()/stop() 的代码段——而 Fiber 切换发生在你“看不见”的执行流中断点，比如 await 表达式求值完成、生成器 yield 返回、或协程调度器接管控制权的瞬间。
这意味着：即使你在 Fiber 内部 start/stop，测到的是业务逻辑耗时；一旦控制权移交，Stopwatch 实例的状态（如开始时间、是否运行中）不会自动跨 Fiber 边界延续或同步。
真正能反映 Fiber 开销的替代方式
要评估 Fiber 对性能的实际影响，应避开 Stopwatch，改用更底层、更可控的方法：
立即学习“PHP免费学习笔记（深入）”；
-
用
hrtime(true)手动打点：在 Fiber 创建前后、每次await前后、关键调度点插入高精度时间戳，手动计算差值。例如：$t0 = hrtime(true); $fiber = new Fiber(...); $t1 = hrtime(true); // 创建开销 ≈ $t1 - $t0 -
启用 Zend VM 调试统计：编译 PHP 时加
--enable-debug，运行时设置ZEND_DEBUG=1，配合php -d zend_extension=opcache.so -v查看 VM 指令计数与 Fiber 相关 opcode（如ZEND_FIBER_SUSPEND）的执行频次和平均耗时。 -
结合 Xdebug 或 Blackfire 的底层采样：开启
xdebug.mode=profile或使用 Blackfire 的“VM-level”探针，可捕获 Fiber 切换引发的栈帧重建、Zval 复制、上下文保存等真实开销，比 Stopwatch 精确两个数量级。 -
对比基准测试：写两组功能完全一致的代码——一组用 Fiber +
await，一组用传统同步调用——在相同负载下压测 RPS 和内存波动。差值中扣除 I/O 等共性因素后，剩余部分才接近 Fiber 调度的真实成本。
Stopwatch 在 Fiber 场景下的合理用法
它适合测量 Fiber 内部“一段连续执行”的业务耗时，前提是明确其局限性：
- 只在单个 Fiber 的生命周期内调用 start/stop，不跨
await或yield边界 - 避免在 Fiber 启动回调（
Fiber::__construct第二个参数）里初始化 Stopwatch 实例，防止闭包捕获导致内存泄漏 - 若需聚合多个 Fiber 的耗时，应在主 Fiber 或调度器中统一收集
hrtime()结果，再交由 Stopwatch 汇总展示（而非让它参与调度逻辑）
本质上，Stopwatch 是为同步请求生命周期设计的工具。Fiber 的协作式并发打破了“一次请求一个执行流”的前提，想精确量化切换开销，得下沉到 VM 层或借助专业剖析器——Stopwatch 只能帮你看清“每段代码跑多快”，而不是“切换本身花了多少”。
