reload只重载worker进程，不重启master/manager/task_worker；配置变更（如worker_num、ssl）必须restart，否则看似运行实则失效。
Reload 不等于 Restart，强行用 reload 应对配置变更，服务会“看似运行，实则失效”。
reload 只重载 worker 进程，master/manager/task_worker 全都不动
这是最常被误判的一点：你改了 worker_num、task_worker_num、max_request，甚至加了新扩展或定义了全局常量，然后执行 kill -USR1 $pid 或调用 $server->reload()——结果完全没变化。
原因很直接：Server::set() 的所有参数只在 new Swoole\HTTP\Server 实例化时读取一次；reload 不重建 master 进程，也就不会重新解析这些配置。
- 真正生效的 reload 行为：仅重新 require 当前 worker 进程加载的 PHP 文件（如控制器、服务类）
- 不生效的变更：端口、进程数、SSL 配置、opcache 相关设置、自定义进程启动逻辑
- Task Worker 虽属 worker 类型，但 EasySwoole 等框架中若用
addProcess自定义实现，reload默认不触及其代码重载
restart 必须彻底 stop + start，systemd 下容易卡死
用 systemctl restart swoole-server 却一直卡在 “activating” 或报 Failed to restart，大概率是 service 文件没配对。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
Swoole 默认以 daemon 模式后台运行，而 systemd 要求主进程前台驻留。一旦 daemonize = true（默认值），systemd 会认为进程“启动完就退出”，随即标记失败。
- 必须设
daemonize = false，且 PHP 脚本末尾不能有exit或die - service 文件里写
Type=simple（不是forking），并确保Restart=always - 常见残留问题：
Address already in use—— 上次进程没 clean exit，端口被占，得先killall php或查lsof -i :9501
reload_async 和 opcache 是两个隐形断点
看似 reload 成功，但用户请求开始报错或返回旧逻辑？检查这两处。
-
reload_async = true是默认值，但如果设成false，reload 会阻塞所有新请求，直到全部 worker 重载完成 —— 此时接口会明显变慢甚至超时 - PHP 启用了 opcache（尤其生产环境），即使 reload 了文件，opcache 缓存的 opcode 仍可能命中旧版本；必须显式调用
opcache_reset()，或在混用 php-fpm 的场景下重启 fpm - 某些 IDE 自动保存 + FTP 同步导致文件写入不完整，reload 加载到半截代码，报
ParseError却无日志 —— 建议用 rsync + --checksum 部署
真正难的不是知道 reload 和 restart 的区别，而是每次改完东西，得下意识问一句：“这个改动，到底走的是进程生命周期，还是代码加载路径？” 配置、扩展、常量、连接池初始化……全卡在 master 进程里，它们从不响应 USR1。
