php-daemon无法通过composer require安装，因其未发布于Packagist、无composer.json、不兼容现代PHP与Composer 2.x；需手动集成并修复兼容性问题，或改用symfony/process、ReactPHP、RoadRunner等现代替代方案。
php-daemon 并不是一个由 Composer 官方包管理器直接支持的、开箱即用的标准 PHP 库。它没有发布在 Packagist 上，也没有维护 composer.json 文件，因此你无法通过 composer require 直接安装。
为什么 composer require php-daemon/php-daemon 会失败
尝试执行该命令时，Composer 会返回类似 Package php-daemon/php-daemon not found 或 Could not find package php-daemon/php-daemon 的错误。根本原因是该项目（通常指 kakserpom/phpdaemon）未注册到 Packagist，也未声明兼容 PSR-4 自动加载规则，且长期未更新（最后活跃约在 PHP 5.6 时代），与现代 PHP（8.0+）、Composer 2.x 及依赖约束机制存在多重不兼容。
替代方案：手动引入 + 兼容性补救
若你仍需基于该代码实现守护进程逻辑，必须绕过 Composer 安装流程，改为手动集成，并处理关键兼容问题：
- 克隆仓库：
git clone https://www.php.cn/link/f08458e1c0495cc433649fb97e2d4ba4.git到项目vendor/下某子目录（如vendor/php-daemon） - 手动注册自动加载：在
composer.json的autoload→psr-0或classmap中添加路径（注意它用的是旧式__autoload或文件名即类名规则，非 PSR-4） - PHP 版本降级适配：
php-daemon依赖pcntl、posix、sockets扩展，且大量使用goto、create_function（PHP 7.2+ 已移除），需打补丁或替换掉废弃语法 - 信号处理失效风险：PHP 7.4+ 对
pcntl_signal_dispatch()调用时机更严格，原代码中信号注册位置不当会导致SIGHUP/SIGTERM无法被捕获
更现实的选择：改用现代替代库
与其投入时间修复一个已事实弃更的项目，不如选用当前活跃、Composer 原生支持的方案：
立即学习“PHP免费学习笔记（深入）”；
-
symfony/process：适合简单启停子进程，但不提供完整 daemon 生命周期管理 -
reactphp/event-loop+reactphp/socket：构建异步守护服务（如长连接监听），天然支持后台运行 -
spiral/roadrunner：高性能 PHP 应用服务器，可作为守护进程托管 HTTP/GRPC/Queue 等服务 - 轻量封装脚本：用
nohup php your-script.php > /dev/null 2>&1 &启动，配合supervisord管理进程生死——这是生产中最常见、最可控的做法
真正棘手的不是“怎么装”，而是“装了能不能跑、出了问题有没有人修”。php-daemon 的代码里混着大量魔术方法调用、全局变量污染和无异常保护的系统调用，调试时 core dump 都可能没堆栈——这点比安装方式重要得多。
