CoroutineSystem::stat 返回 false 而非异常，主因是路径为不可靠的相对路径、文件系统不支持 stat 系统调用、SWOOLE_HOOK_FILE 启用但 SWOOLE_HOOK_STDIO 未启用，或使用 phar://、zip:// 等协程不支持的只读协议。
CoroutineSystem::stat 返回的是协程环境下的文件元信息，但和同步版 stat() 有本质区别：它不阻塞 worker，但只支持本地文件路径，且不触发 PHP 的 stream wrapper（如 php://、data:// 或自定义协议）。
为什么 CoroutineSystem::stat 会返回 false 而不是抛异常
这是最常被误读的一点——它失败时直接返回 false，不是因为权限或路径错误，而是因为：
• 路径是相对路径且当前工作目录在协程中不可靠（getcwd() 在协程中可能为空或错乱）
• 文件系统不支持 stat 系统调用（如某些 FUSE 挂载、NFSv3 无 getattr 缓存）
• 启用了 SWOOLE_HOOK_FILE 但未启用 SWOOLE_HOOK_STDIO，导致底层无法接管路径解析逻辑
• 使用了 phar:// 或 zip:// 等只读封装协议（协程 stat 不支持这些 wrapper）
CoroutineSystem::stat 和 stat() 的行为差异
二者返回的数组结构一致（含 dev、ino、mode、size 等字段），但关键区别在运行时表现：
• stat() 是同步阻塞调用，一个请求卡住，整个 worker 就停摆
• CoroutineSystem::stat 是非阻塞 I/O 封装，依赖底层 libuv 或 io_uring（视编译选项而定），实际走的是异步 stat syscall（Linux 5.6+）或线程池模拟（旧内核）
• CoroutineSystem::stat 不读取文件内容，只查 inode 元数据；而 filemtime() 这类封装函数即使加了 hook，底层仍可能触发一次 open()+fstat()，开销更大
• 若未调用 SwooleRuntime::enableCoroutine(SWOOLE_HOOK_FILE)，CoroutineSystem::stat 仍可用，但普通 file_exists()、is_file() 等不会自动协程化
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
哪些场景下必须用 CoroutineSystem::stat
当你在高频请求路径中需快速判断文件是否存在、是否更新、大小是否超限，又不能容忍同步阻塞时：
• API 网关根据 config.json 时间戳热加载路由规则
• 静态资源服务校验 etag 对应文件的 mtime 和 size
• 上传中间件在接收前预检磁盘配额（通过 statfs 需另用 CoroutineSystem::statvfs）
• 注意：它不等价于 opendir() + readdir()，目录遍历仍得用 CoroutineFs::opendir 或全量 hook 后的 scandir()
真正容易被忽略的是：即使开了 enable_coroutine => true，CoroutineSystem::stat 也**不会自动 fallback 到同步模式**。它要么成功返回数组，要么立刻返回 false——没有重试、没有日志、不触发 error handler。排查时得先确认路径是否绝对、文件系统是否支持、以及 SWOOLE_HOOK_FILE 是否已启用。
