post-autoload-dump 在 Composer 重新生成自动加载映射文件（如 vendor/autoload.php）完成之后立即执行，与类是否被加载无关，仅由 autoload 配置变更或手动执行 dump-autoload 触发。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

post-autoload-dump 是什么时机触发的 它不是“类加载成功后”才执行，而是每次 Composer 重新生成自动加载映射文件（vendor/autoload.php 及其底层 autoload_psr4.php、autoload_classmap.php 等）**完成之后**立即运行。 这个事件和你有没有 new 出对象、有没有 require 文件完全无关——它只和 Composer 的 autoload 配置变更或手动刷新动作挂钩。

• 运行 composer install 或 composer update 会触发（因为要重建 autoload）
• 手动执行 composer dump-autoload 也会触发
• 但修改了 PHP 类文件、改了命名空间、加了新类，却没运行 dump-autoload？那它压根不会跑
• post-root-package-install 和 post-create-project-cmd 完全不在此列——它们只在 create-project 场景下生效，普通项目里写进去也不会执行

怎么在 composer.json 里正确注册脚本 直接往 scripts 字段里加 post-autoload-dump 键就行，值可以是字符串或数组：

"scripts": {
  "post-autoload-dump": [
    "echo '✅ 自动加载已更新'",
    "php scripts/Cleanup.php",
    "rm -f storage/framework/cache/*.php"
  ]
}

• 数组形式更安全：避免 shell 解析歧义（比如命令含空格、重定向、管道时）
• PHP 脚本必须能被当前环境加载：要么放在 src/ 下并已配置 PSR-4，要么用绝对路径 + php 显式调用
• 别写 ./scripts/clean.sh 就完事——Linux/macOS 下缺执行权限会报 Permission denied；加 chmod +x 或统一用 bash scripts/clean.sh 更稳
• 环境变量如 $COMPOSER_HOME 可用，但 $PWD 不可靠，建议用 __DIR__ 或 getcwd() 在 PHP 脚本里获取项目根目录

哪些事适合放在这里做 这个钩子的核心价值在于：**它知道“类结构可能变了”，且“autoload 映射刚刷完”，是清理、重建、验证的最佳窗口**。

• 清除框架缓存：Laravel 的 bootstrap/cache/config.php、Symfony 的 var/cache/dev，这些缓存依赖旧类名，不删会导致 Class not found 却死活查不出原因
• 生成代理类或 DTO stubs：Doctrine、ApiPlatform、自研 ORM 常需根据接口/注解生成实现类，此时 PSR-4 映射已确定，路径可预测
• 复制迁移文件：包作者可在 post-autoload-dump 中检查自己包是否被安装/更新，再把 migrations/ 文件拷进主项目对应目录
• 校验 autoload 完整性：扫描 src/ 下所有 .php 文件，比对命名空间与实际路径是否匹配，提前暴露 App\User 写在 src/Models/User.php 却没配 "App\Models\": "src/Models/" 这类低级错误

容易踩的坑和性能陷阱 很多人以为写了 post-autoload-dump 就万事大吉，结果部署失败、本地跑不通、CI 报错，问题往往出在细节上。

• 用了 composer dump-autoload -o（即 --optimize），但脚本里又去删 autoload_classmap.php？别删——它就是优化后生成的，删了 autoload 就直接崩
• 在脚本里调用 Artisan::call('migrate')，却没确认 Laravel 是否已启动：CLI 下 app() 可能未初始化，得先 require vendor/autoload.php 并启动容器
• 误把 files 加载的辅助函数塞进 PSR-4 目录，或反过来——files 列表改了却不跑 dump-autoload，新加的 helpers.php 就永远不会被 require_once
• 开发中滥用 -o：改一个类就得重跑 dump-autoload -o，否则新类进不了 classmap，Class not found 报错还查不到原因——日常开发建议只用默认模式，上线再加 -o

真正难的不是写几行脚本，而是想清楚：这个动作是否真的必须在这个时间点做？有没有更稳定、更可测试的替代方式？比如把缓存清理挪到部署脚本里，把迁移交给 CI 流水线，反而更可控。