Composer本身不支持热重载，因PHP类加载后驻留内存无法覆盖，重复require autoload.php仅返回单例且不刷新已加载类；真正生效需进程重启、OPcache失效及映射更新三者协同。
Composer 本身不支持热重载，所谓“热重载”是靠外部工具 + 手动干预加载器行为拼凑出来的开发时妥协方案。
为什么 require 'vendor/autoload.php' 不能重复执行实现热重载
这行代码本质是调用 ClassLoader::getLoader() 并绑定多个 spl_autoload_register() 回调；它只注册一次 autoload 队列，不会刷新已加载的类定义。PHP 类一旦被 include 或 require 解析进内存，就无法被覆盖——$loader->unregister() 和 $loader->register() 只是开关回调注册状态，并不 reload 类文件。
- 重复
require 'vendor/autoload.php'不会重建ClassLoader实例，只会返回已有单例 - 即使你手动
unset($loader)，也无法让 PHP 卸载已定义的类（这是语言层硬限制） - 真正生效的“重载”，必须重启 PHP 进程（如 CLI 下 kill + restart，或 Web Server reload）
开发环境里能“假装热重载”的三个必要动作
要在请求级看到新类/改名类生效，得同时满足：映射表更新、OPcache 失效、类未被提前加载。缺一不可。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 执行
composer dump-autoload—— 否则vendor/composer/autoload_psr4.php里的映射还是旧的，新类路径根本查不到 - 调用
opcache_invalidate('path/to/changed.php', true)或整个清空 OPcache（opcache_reset()），否则即使文件变了，PHP 还在跑旧字节码 - 确保该类在当前请求中尚未被加载过：如果上一个请求已触发
new App\Service\Logger()，那这个类定义就锁死在内存里，本请求再怎么刷新 autoload 也无用
$loader->setClassMapAuthoritative(false) 的真实作用
这个设置不是为了“支持热重载”，而是关闭 classmap 的权威模式，让 autoload 器在找不到 classmap 记录时，继续走 PSR-4 路径查找——这对开发阶段新增类有用，但对已加载类无效。
- 设为
true（默认生产环境）时，classmap 里没记录的类直接报Class not found，跳过 PSR-4 查找，性能高但不灵活 - 设为
false后，autoload 器会老老实实按 PSR-4 规则拼路径、检查文件是否存在，适合开发时频繁增删类 - 它不解决类重定义问题，也不影响已加载类的行为，只是改变“找不到时是否放弃”的策略
Swoole 等常驻进程里热重载为何更难
Worker 进程 fork 自 Master，所有 autoload 相关状态（注册的 spl_autoload_register 回调、ClassLoader 实例、OPcache 缓存）都是进程私有且不随 dump-autoload 自动更新的。
- 在
onWorkerStart里require_once 'vendor/autoload.php'是无效的——只是重复注册已存在的回调 - 真正有效的预热，只能在 Master 进程启动前完成：
require_once+class_exists()强制加载关键类 - 修改了
composer.json的autoload.psr-4？必须重启整个 Swoole 进程，否则新映射永远不会生效
热重载不是 Composer 的能力边界，而是 PHP 运行模型本身的限制。所有“热”方案，本质都是绕过限制的权宜之计：靠进程重启换上下文，靠缓存失效换字节码，靠映射刷新换路径逻辑。任何指望在同一个 PHP 请求里无缝替换类定义的做法，都会撞上语言层的墙。
