fiber让strategy和state模式更透明：strategy中策略封装于单个fiber内，suspend/resume替代execute/handleresult两层接口；state中每个状态对应一个fiber实例，suspend返回状态标识，resume自动跳转，无需手动维护state变量和transitionto方法。
Fiber 不改变设计模式的本质，但让某些模式的实现更轻量、更贴近业务逻辑，尤其在 I/O 密集型场景中能绕过传统模式的调度包袱。
为什么 Strategy 和 State 模式在 Fiber 下变得更“透明”
传统异步编程中，Strategy 模式常被 Promise/Callback 套壳包裹，导致策略执行路径被拆散；State 模式则因状态迁移需跨 await 边界而被迫引入额外上下文管理。Fiber 让这两类模式回归“函数即策略”“协程即状态机”的原始语义：
-
Fiber内部可完整封装一个策略分支，Fiber::suspend()作为策略暂停点，resume()携带决策结果继续执行，无需抽象出execute()+handleResult()两层接口 - State 模式不再需要手动维护
currentState变量和transitionTo()方法 —— 每个状态直接对应一个Fiber实例，suspend()返回下个状态标识，resume()自动跳转到对应协程 - 注意：
Fiber本身不提供状态持久化，若需跨请求保留状态，仍得配合外部存储（如 Redis），不能仅靠Fiber栈变量
Observer 模式在 Fiber 环境里容易误用成“伪响应式”
常见错误是把 Fiber::suspend() 当作事件订阅入口，在协程里循环 suspend() 等待通知。这会导致：
- 协程长期处于
Suspended状态却无实际 I/O 阻塞，白白占用内存和调度器资源 - 通知方若未严格配对
resume()，协程将永久挂起，形成内存泄漏 - 真正适合的写法是：Observer 的
notify()方法内部调用目标Fiber->resume($data)，且确保每个suspend()都有明确触发条件（如stream_select()就绪、pcntl_signal_dispatch()收到信号）
如何用 Fiber 替代传统 Worker Pool 模式
Worker Pool 常见于队列消费、批量 HTTP 请求等场景。Fiber 让它从“进程/线程池”退化为“协程池”，关键差异在调度权归属：
- 传统 Worker Pool 依赖
pcntl_fork()或pthread，每个 worker 是独立 OS 进程/线程，通信靠 IPC 或共享内存 - Fiber Pool 中所有 worker 是同一线程内的
Fiber实例，通过单个调度器统一resume()，数据共享直接读写变量，无序列化开销 - 必须显式控制并发数：用
count($activeFibers) 判断是否 <code>schedule()新协程，否则会因无限启动Fiber耗尽栈内存 -
Fiber不处理超时，sleep()会阻塞整个线程 —— 必须用stream_select()或EventLoop::delay()（如 amphp）模拟非阻塞等待
最易被忽略的一点：Fiber 的栈空间默认极小（PHP 8.1 是 256KB，8.3 可调），递归调用或大数组局部变量极易触发 Fatal error: Allowed memory size exhausted。这不是 GC 问题，而是栈溢出 —— 调试时看报错堆栈深度比看内存用量更有效。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
