Composer本身不支持Swoole热更新，因其仅管理依赖和生成自动加载文件，不监听文件变更、不发送信号、不重启Worker进程；真正生效需配合opcache配置调整、Swoole进程重载（如SIGUSR1）及PHP层文件重载机制协同实现。
composer 本身不能实现 Swoole 下的代码热更新，它不监听文件、不发送信号、不重启进程——所有“热更新”效果都得靠你手动补全或外部工具兜底。
composer install 和 composer update 为什么改了代码也不生效
Swoole 是常驻内存模型，PHP 文件在 Worker 启动时被一次性加载并编译（opcode 缓存），后续请求不再读取磁盘文件
composer install只更新vendor/目录和autoload.php，不会通知正在运行的 Worker 进程重新加载类或刷新配置即使你用
path类型仓库让本地包变成符号链接，改完代码也仅是文件变了，Worker 还在跑旧 opcode常见错误现象：改了
app/Service/UserService.php，curl <a href="https://www.php.cn/link/64a2ced1a3bc35f45f1c3bdb0c8b256f">https://www.php.cn/link/64a2ced1a3bc35f45f1c3bdb0c8b256f</a>依然返回旧逻辑-
必须配合以下至少一项才可能“看到变化”：
Discussion Composer下载围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 手动触发
$server->reload()或发送SIGUSR1 - 设置
'max_request' => 50让 Worker 自动退出换新 - 关闭
opcache.enable，或设opcache.validate_timestamps=1且opcache.revalidate_freq=0 - 确保没在
static属性或全局变量里缓存过旧实例
- 手动触发
composer dump-autoload 的真实作用和陷阱
- 它只是重写
vendor/composer/autoload_*.php映射文件，让新类能被自动加载器找到 - 不等于“热重载”：类文件路径变了、命名空间改了、新增了 PSR-4 映射，必须执行它，否则
Class not found - 开发期用默认命令即可：
composer dump-autoload - 上线前必须加
-o：composer dump-autoload -o，否则在--classmap-authoritative模式下新类直接不可见 - 如果启用了
apcu缓存 autoload 数据，还得加--apcu，且确保 APCu 缓存已清空或 PHP 进程重启过
Swoole 环境下真正起效的“热更新链路”
要让 Composer 安装的新代码在 Swoole 中生效，实际依赖的是三层协作：
Composer 层：负责把正确版本的代码拉到
vendor/或项目目录，生成准确的 autoload 映射PHP 层：关闭
opcache.enable或调低opcache.revalidate_freq，避免 opcode 错过文件变更Swoole 层：通过信号（
SIGUSR1）、$server->reload()、或max_request触发 Worker 进程替换，加载新代码-
推荐最小可行组合：
- 开发时设
'max_request' => 1（极端调试用）或100（平衡体验） - 配合
inotifywait -m ./app -e modify | while read ...; do kill -USR1 $(cat swoole.pid); done - 在
php.ini中明确禁用 opcache：opcache.enable=0 - 不依赖任何框架封装的“热重载”，先验证裸 Swoole 能否 reload 成功
- 开发时设
真正的难点不在 Composer，而在你是否意识到：Swoole 的热更新本质是进程替换，不是文件重载。哪怕 composer.json 写得再规范，只要没让 Worker 进程真正退出再拉起，改再多行代码也白搭。
