workerman 5.2.3 安装易因旧版残留、依赖冲突、环境不兼容或多框架 autoload 污染导致类找不到或方法不存在；需清理旧包、锁定版本、验证 php 扩展、分离运行模式。
Workerman 5.2.3 是一个相对稳定的版本，但安装时若项目中已存在旧版 Workerman、Webman、GatewayWorker 或其他依赖它的组件（如 workerman/mqtt、workerman/webman-framework），就容易触发版本冲突——表现为 Composer 报错“could not resolve”、类加载失败、或启动时报 “Class not found” “Method not exist” 等。
检查并清理已有 Workerman 相关包
很多冲突源于残留的低版本或手动引入的非 Composer 包。执行以下操作可快速识别和清除干扰项：
- 运行
composer show workerman/workerman查看当前安装版本；若输出为空或显示低于 5.2.3 的版本（如 4.x），说明需升级 - 检查
vendor/workerman/目录是否存在非标准结构（例如直接复制的源码、无 composer.json 的子目录），这类手动安装会绕过 Composer 版本约束，必须删除 - 搜索项目中是否硬编码引用了旧版路径，例如
require 'Workerman/Worker.php'或use WorkermanConnectionAsyncTcpConnection;—— 这些在 5.2.3 中可能已重构或移除
锁定依赖版本并禁用自动降级
Workerman 5.2.3 对 PHP 和扩展有明确要求，不兼容旧版依赖会导致 Composer 自动回退到低版本。应在 composer.json 中显式约束：
- 添加或确认
"workerman/workerman": "^5.2.3"，注意使用^而非~，避免误升到 6.x（尚未发布） - 若同时使用
webman-framework，确保其版本 ≥ 2.2.0（已适配 Workerman 5.2.x）；可指定"workerman/webman-framework": "^2.2.0" - 执行
composer update workerman/workerman --with-dependencies，强制更新其所有直系依赖，避免中间包卡在旧版
验证 PHP 环境与扩展兼容性
Workerman 5.2.3 在 PHP 8.0–8.2 下运行良好，但部分扩展行为变化会引发“伪冲突”——比如 Composer 认为环境不满足而拒绝安装：
- 确认
pcntl和posix已启用：php -m | grep -E "pcntl|posix"；Windows 下无法使用 pcntl，只能降级到单进程模式（不推荐生产） - 检查
disable_functions是否禁用了stream_socket_server、pcntl_fork等核心函数（可通过php -i | grep disable_functions查看） - 若项目还用到
event扩展（如高并发场景），需确保其版本 ≥ 3.0.0，否则与 Workerman 5.2.3 的事件循环存在兼容问题
避免多框架共存时的自动加载污染
当 Workerman 与 ThinkPHP、Laravel 等框架混用时，各自的 autoload 配置可能互相覆盖，导致类找不到或方法签名错误：
- 不要在 Web 框架的入口（如
public/index.php）里启动 Worker；Workerman 必须以 CLI 模式独立运行 - 若需复用框架模型，应通过 CLI 调用方式（如
php think worker:start）或消息队列解耦，而非直接require框架启动文件 - 检查
composer.json的autoload段，移除重复映射（如同时定义了"Workerman\"和"workerman\workerman\"）
