不能边跑FPM边启Hyperf服务，因二者生命周期模型根本冲突：Hyperf常驻内存、协程共享进程状态，FPM每次请求新建独立进程；混用将导致协程污染、连接泄漏、全局变量错乱、DI容器与AOP失效等问题。
不能直接“平滑”切换，必须分阶段推进——FPM 和 Hyperf 是两种完全不同的生命周期模型，强行共存会引发协程污染、连接泄漏、全局状态错乱等隐性问题。
为什么不能边跑 FPM 边启 Hyperf 服务？
Hyperf 是常驻内存的协程服务器，所有请求在同一个进程内多个协程中并发执行；而 FPM 每个请求都是全新进程，无共享上下文。两者混用时：
-
$_SESSION、$_COOKIE、static变量、global变量在协程间会互相污染 - 数据库连接池（如
Hyperf\Database\Pool）无法被 FPM 进程复用，反而可能因未关闭连接导致Too many connections - Hyperf 的注解扫描、AOP 切面、依赖注入容器只在启动时初始化一次，FPM 请求无法触发或感知这些机制
- 路由、中间件、事件监听器等运行时结构在 FPM 中完全失效
如何真正实现「平滑过渡」？
核心是「功能拆分 + 流量灰度 + 状态隔离」，而非代码共存：
- 先将新功能模块（如 WebSocket 客服、实时通知、RPC 接口）用 Hyperf 单独开发部署，走独立域名或子路径（如
/api/v2/或wss://ws.example.com），不触碰原有 FPM 逻辑 - 对存量接口做「双写适配」：FPM 侧保留业务主流程，Hyperf 侧仅承接高并发、低延迟、长连接类请求（比如订单状态推送、聊天消息广播）
- 共享数据层必须无状态：MySQL 使用读写分离+连接池，Redis 用
Hyperf\Redis\Redis客户端（非phpredis），避免协程间资源竞争 - 会话状态不要依赖 PHP 内置 session，改用 Redis 存储 + 自定义 token 验证（
Hyperf\Session\Handler\RedisHandler），确保 FPM 和 Hyperf 能读写同一份会话数据
迁移过程中最容易被忽略的三个点
不是语法或配置，而是运行时契约的断裂：
立即学习“PHP免费学习笔记（深入）”；
-
date_default_timezone_set()在 Hyperf 启动时调用一次即可，FPM 每次请求都设——若旧代码里反复调用，会导致协程间时区错乱 -
ini_set('memory_limit', ...)对协程无效，Hyperf 进程内存由 Swoole 启动参数控制（--memory-limit），硬编码会掩盖真实内存瓶颈 -
register_shutdown_function()在协程中不可靠，清理逻辑必须改用Hyperf\Contract\OnCloseInterface或Co::defer()，否则连接断开后资源不释放
真正的平滑不在代码兼容，而在流量和状态的可控移交；一旦开始启用 Hyperf，就该默认它是一个新服务，而不是旧系统的“升级补丁”。
