Workerman 5.0 的 Fiber 由框架底层自动调度，不提供手动创建/切换 API；业务代码须在 onMessage/onRequest 等回调中使用 Co:: 系列协程函数，禁用 new Fiber()、全局协程调用及第三方 Fiber 库，确保 DNS 解析、HTTP/DB 请求等均走协程化路径。
Workerman 5.0 里 Fiber 不是拿来“用”的，而是框架底层自动调度的
Workerman 5.0 的协程能力基于 PHP 8.1+ 的 Fiber，但它**不提供手动创建/切换 Fiber 的 API**。你写的业务代码里不需要、也不应该直接调用 new Fiber() 或 $fiber->start() —— 那样反而会破坏 Workerman 的协程调度器（Lib\Coroutine）。
常见错误现象：Fiber::getCurrent() returns null、协程上下文丢失、yield 报错、异步 IO 不生效。根本原因是你试图绕过 Workerman 的运行时接管，自己搞协程生命周期。
- 所有协程化操作（如
Co::sleep()、Co::mysql()、Co::httpGet()）必须在 Workerman 的onMessage/onRequest等回调中执行 - 不能在
__construct、全局作用域、或非 Workerman 启动的 CLI 脚本里触发协程函数 - 第三方库若内部用了
Fiber（比如某些新版swoole兼容层），和 Workerman 5.0 冲突，直接禁用
Co::mysql() 和 Co::redis() 这类协程客户端怎么配才不阻塞
它们不是“开启协程”就能用的，依赖两个前提：PHP 编译时启用 --enable-mysqlnd（默认已有），以及 Workerman 启动时已加载协程驱动（5.0 默认开启，但需确认没被禁用）。
使用场景：在 Worker 或 WebServer 的回调里发数据库/缓存请求，期望不卡主线程。
- 连接必须用
Co::mysql()->connect()创建，不能复用传统mysqli实例 -
Co::redis()不支持pconnect，每次connect()是轻量级协程安全的，别自己做连接池（Workerman 5.0 内置了） - 如果看到
PHP Warning: Swoole\Coroutine\MySQL::connect(): connect timeout，不是网络问题，大概率是 DNS 解析未协程化 —— 改用 IP，或确保Co::dnsLookup()提前解析
为什么 file_get_contents('http://...') 在协程里还是阻塞
因为它是同步函数，不走 Workerman 的协程 Hook。PHP 原生函数不会自动变成协程版，除非你显式替换成协程替代品。
性能影响：一个 file_get_contents 可能拖慢整个进程的并发能力，因为它会让当前协程线程完全挂起，无法调度其他任务。
- 必须换为
Co::httpGet()、Co::curl_exec()或GuzzleHttp\Client+Workerman\Guzzle\CoroutineHandler -
Co::httpGet()不支持复杂 Cookie 管理或重定向链，需要就上Guzzle配合协程 Handler - 别对 HTTPS URL 直接传
ssl://，Co::httpGet()内部自动处理，传https://即可
协程上下文丢失：Co::getContext() 返回空，Co::stats() 数值不对
这通常发生在你试图在定时器回调（Timer::add()）、信号回调（Process::signal()）或子进程里访问协程 API —— 这些上下文不在协程调度器管理范围内。
兼容性影响：PHP 8.2+ 对 Fiber 生命周期更严格，这类误用会直接报 Fatal error: Uncaught Error: Cannot get current fiber outside a fiber。
- 定时任务要用
Co::delay()或Co::sleep()在协程内完成，别用Timer::add() - 子进程通信改用
Co::process()创建的协程进程，而不是pcntl_fork() -
Co::stats()只统计当前 Worker 进程内由 Workerman 调度的协程，跨进程/跨线程无效
真正难的不是写 Co::xxx()，而是理解哪些代码路径天然不在协程上下文中 —— 比如 Composer 自动加载、异常处理器、日志写入钩子。这些地方一旦调用协程函数，就会崩得毫无征兆。
