fiber 不是 swoole 协程的平替，而是调度权上收至 zend vm 的范式切换；必须自行管理挂起与恢复，不能用 fiber::suspend() 替代 co::sleep()，需配合异步 i/o 或定时器驱动恢复。
Fiber 不是 Swoole 协程的平替，而是调度权从扩展层上收至 Zend VM 的范式切换 —— 直接后果是：你不能再依赖 Co::sleep() 或 hook_flags，必须自己管理挂起点与恢复时机。
为什么 Fiber::suspend() 不能替代 Co::sleep()
两者语义完全不同：Co::sleep() 是带时间语义的 I/O 等待封装，底层触发 epoll_wait + 调度器自动唤醒；而 Fiber::suspend() 只是无条件让出控制权，不绑定任何事件、不等待任何资源。
- 误用示例：在 Fiber 中调用
Fiber::suspend()模拟延时，却不配对resume()触发逻辑，会导致 Fiber 永久挂起，内存泄漏 - 正确路径：需配合真实异步 I/O（如
amphp/socket的非阻塞 connect）或手动定时器（Revolt\EventLoop::delay()）驱动恢复 - 关键区别：Swoole 的 sleep 是“协程感知的等待”，Fiber 的 suspend 是“纯控制流让渡” —— 后者不自带时间/事件语义
Fiber::create() 和 new Fiber() 的行为差异
PHP 8.1+ 支持两种构造方式，但生命周期管理逻辑不同：
-
new Fiber($callback)：返回未启动 Fiber，调用start()才首次执行，且start()只能调用一次 -
Fiber::create($callback)：返回已创建但未运行的 Fiber，语义等价于new Fiber()，但更明确表达“惰性构造”意图 - 陷阱：多次调用
start()抛出FiberException: Cannot start a fiber that has already been started；而resume()可重复调用，但仅对已挂起状态有效 - 兼容建议：统一用
new Fiber()，避免混淆；create()多见于早期 RFC 示例，实际项目中无优势
协程退化为同步阻塞的三个典型场景
即使用了 Fiber，只要调用链中存在任意同步 I/O，整个 Fiber 就会卡住，拖垮整个 Event Loop：
- 调用
file_get_contents()、curl_exec()、mysqli_query()等原生阻塞函数 —— Fiber 无法中断它们，只能干等 - 使用未适配 Fiber 的 SDK，例如
openai-php/client底层依赖 GuzzleHttp 同步请求栈，await无效 - 在 Fiber 内部调用
sleep()或usleep()—— 这些函数不会自动 hook，直接阻塞线程 - 验证方法：在 Fiber 中插入
microtime(true)前后打点，若耗时远超预期且 CPU 占用低，基本可判定发生了隐式阻塞
Event Loop 与 Fiber 必须显式协同，没有默认绑定
PHP 原生 Fiber 不提供调度器，Fiber 和 Revolt / Amp 是松耦合关系 —— 你得亲手把 Fiber 的挂起/恢复接入 Loop 的就绪队列。
- 常见错误：只创建 Fiber 并
start()，却不注册suspend()后的回调到 Loop，导致无人resume() - 正确模式：当 Fiber 因等待 socket 可读而
suspend()，需用stream_select()或Revolt\EventLoop::onReadable()监听，就绪后调用$fiber->resume($data) - 性能影响：每次
resume()都涉及栈上下文恢复，高频调用（如每毫秒 resume 一次）会显著抬高 CPU，应合并等待条件 - 注意：
Revolt的async()函数本质是 Fiber + Loop 封装，但它不改变底层规则 —— 你仍要确保所有 I/O 走异步通道
真正难的不是写 Fiber，而是把整条调用链上的每个函数都变成“可挂起”的。一个未适配的 json_decode() 不会阻塞，但一个未重写的数据库连接池初始化函数，可能在 start() 里就卡死整个 Loop。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
