Workerman在ThinkPHP中启动失败主因是自动加载未打通，需手动引入vendor/autoload.php；守护模式无热重载，需重启生效；进程数应按IO/CPU特性调优；日志须加锁或统一由主进程处理；数据库连接需进程隔离。
Workerman在ThinkPHP中启动失败的常见原因
直接在ThinkPHP项目里执行 php start.php start 报错“Class not found”或“require(): failed to open stream”，基本是自动加载路径没对上。Workerman默认不走Composer的autoload，而ThinkPHP 6+ 的核心类（如think\App）依赖PSR-4自动加载，两者不打通就会断。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在
start.php顶部手动引入ThinkPHP的自动加载器：require __DIR__ . '/vendor/autoload.php'; - 避免在
Worker::runAll()前调用任何ThinkPHP容器实例（如app()），否则可能因进程未初始化导致异常 - 确认
start.php文件权限为可执行（Linux下chmod +x start.php），且PHP CLI版本与Web服务器一致（尤其注意OpenSSL、sockets扩展是否启用）
守护进程模式下无法热重载配置或代码
用start.php start -d后台运行后，修改事件回调逻辑或配置文件，Workerman不会自动重新加载——它不是像Swoole那样内置reload机制的协程服务器，而是靠进程重启生效。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 开发阶段别用
-d，改完直接php start.php restart；生产环境才启用守护模式 - 若需模拟热更新，可在
onMessage或onWorkerStart里加filemtime()判断配置文件变更，再include重载（仅限简单配置，不推荐用于数据库连接等有状态资源） - 注意
restart命令本质是先stop再start，期间会有短暂服务中断，高可用场景需配合Nginx做健康检查和上游切换
多进程Worker数量设置不当导致CPU打满或空转
ThinkPHP集成Workerman时，常把Worker::$processCount设成CPU核数的2倍甚至更高，结果IO密集型任务（如HTTP请求、Redis调用）反而因上下文切换过多拖慢整体吞吐。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 纯CPU计算任务：设为
cpu_count；混合IO任务（如API网关）：从cpu_count * 1.5开始压测，观察top里%wa（IO等待）和%sy（系统调用）占比 - 避免在
onWorkerStart里初始化大对象（如new \think\App()），每个子进程都会复制一份，内存占用翻倍 - 使用
Worker::setEventLoopClass()切换到Swoole\Event（需装swoole扩展）可提升高并发下事件循环效率，但会失去原生Workerman的跨平台性
日志写入冲突与进程间文件锁遗漏
多个Worker进程同时往同一个runtime/log/workerman.log里写，会出现日志错行、覆盖、甚至文件损坏，因为PHP的file_put_contents(..., FILE_APPEND)不是原子操作。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 改用
file_put_contents($file, $log, FILE_APPEND | LOCK_EX)强制加锁，但会降低写入性能 - 更稳妥的方式是让主进程（pid=master）统一接管日志，Worker通过
Worker::sendToWorker()把日志消息发给指定Worker处理写入 - ThinkPHP的
Log::write()默认不兼容多进程，必须禁用其内置日志驱动，改用Workerman原生日志或Monolog的RotatingFileHandler（支持进程安全轮转）
Workerman和ThinkPHP的耦合点其实就卡在生命周期管理上——前者靠pcntl_fork拉起子进程，后者依赖单次请求生命周期。最容易被忽略的是数据库连接：每个Worker进程都该有自己的PDO实例，不能复用ThinkPHP的全局连接池，否则会出现连接超时或事务混乱。
