Workerman 不能放入 ThinkPHP 的 command 目录，因其常驻多进程模型与 Symfony Console 同步命令冲突；应独立为根目录脚本（如 start_worker.php），手动初始化 ThinkPHP 配置与容器，所有初始化逻辑须置于 onWorkerStart 中。
Workerman 启动脚本不能直接放 ThinkPHP 的 command 目录里
ThinkPHP 的命令行命令（php think xxx）本质是基于 Symfony Console 封装的同步执行逻辑，而 Workerman 是常驻内存、多进程管理的异步服务，两者生命周期和进程模型完全冲突。硬塞进 Command 类里，启动后立刻退出或报 Cannot use 'exit' in a command 错误很常见。
正确做法是把 Workerman 服务脚本独立出来，和 ThinkPHP 项目共存但不耦合——它不是 ThinkPHP 的“命令”，而是同级的“服务进程”。
- 脚本建议放在项目根目录下，比如
start_worker.php，而非app/command/ - 不要用
think命令调用它（php think start:worker这类封装纯属误导） - 启动时必须显式指定运行用户（尤其生产环境），避免因权限问题导致
Worker::reload()失败或端口绑定被拒
如何让 Workerman 正确加载 ThinkPHP 的配置和模型
Workerman 不走 ThinkPHP 的入口流程（public/index.php），所以 Config、Db、Model 等类默认不可用。必须手动初始化核心容器和配置，但切忌直接 require index.php —— 它会触发 HTTP 请求相关组件，引发 Undefined index: SERVER_NAME 或 headers already sent。
推荐最小化引导方式：
立即学习“PHP免费学习笔记（深入）”；
<?php
require __DIR__ . '/vendor/autoload.php';
// 手动加载 ThinkPHP 核心配置（不走完整框架）
$config = include __DIR__ . '/config/app.php';
$config['root_path'] = __DIR__ . '/';
// 初始化基础容器（仅需 Config 和 Db）
think\Container::getInstance()->bind('config', function () use ($config) {
return new think\Config($config);
});
think\Container::getInstance()->bind('db', function () {
return think\Db::connect(config('database'));
});
// 后续即可正常使用 think\Model 或 Db::table()
use app\model\User;
$user = User::find(1); // ✅ 可用
- 别加载
think\App或调用App::run()，那是为 HTTP 请求设计的 - 如果要用 Redis 缓存，需单独实例化
think\Cache并传入配置，不能依赖Cache::store()的自动解析 - 日志写入建议用
think\facade\Log+ 自定义日志驱动，避免和 ThinkPHP 的请求日志通道混用
守护进程启动时常见的 Permission denied 和 Address already in use
Workerman 默认以当前用户身份启动，开发时用 php start_worker.php start -d 很方便，但上线后若用 root 启动再切用户，容易因 socket 文件残留或端口未释放导致失败。错误信息通常长这样：PHP Warning: stream_socket_server(): unable to connect to tcp://0.0.0.0:2345: Address already in use 或 failed to open stream: Permission denied。
- 每次修改代码后，先执行
php start_worker.php stop，再start -d；别跳过 stop 步骤 - 生产环境务必用非 root 用户运行，例如
www-data，并确保该用户对runtime/和日志路径有读写权限 - 端口冲突时，用
lsof -i :2345（macOS/Linux）或netstat -ano | findstr :2345（Windows）查 PID，再kill -9清理 - Workerman 的
status命令有时不准，最可靠的方式是看ps aux | grep start_worker的进程树
热更新 reload 不生效？检查是否用了 onWorkerStart 而非 onConnect
很多人改完业务逻辑后执行 php start_worker.php reload，发现新代码没跑。根本原因是：Workerman 的 reload 只重启 worker 进程，不会重新执行 onWorkerStart 之外的初始化逻辑。如果你把模型加载、配置读取写在 onConnect 或 onMessage 里，那每次 reload 都不会刷新。
- 所有一次性初始化操作（如数据库连接池预热、全局缓存加载）必须放在
onWorkerStart回调中 - 避免在
onMessage中 new Model() 或反复 require 配置文件，这会拖慢性能且无法利用 reload 机制 - 如果真需要运行时重载配置，得自己实现监听文件变更 +
think\Config::set()，Workerman 本身不提供配置热更能力
Workerman 和 ThinkPHP 整合的关键，从来不在“怎么启动”，而在于“谁负责初始化、谁负责销毁、谁该持有单例”。跨进程共享状态这件事，没有银弹，只有边界划清楚了，才不容易半夜被 Segmentation fault 惊醒。
