post-install-cmd失败并非依赖未安装，而是包自带钩子执行出错，常见于Laravel/Symfony项目；需用composer install -vvv定位真实报错，检查autoload是否生效、二进制权限、PHP扩展及版本兼容性，并确认vendor/composer/autoload_classmap.php生成正确。
composer install 后 post-install-cmd 脚本失败
这不是依赖没装上，而是 vendor 里包自带的安装后钩子（post-install-cmd）执行出错。常见于 Laravel、Symfony 等框架项目，比如 php artisan package:discover 或 IlluminateFoundationComposerScripts::postAutoloadDump 报错。
这类错误不会阻止 vendor/ 目录生成，但会导致后续命令（如 php artisan）直接失败，且错误堆栈常被淹没在大量“Discovered Package”日志里。
- 先加
-vvv重跑：composer install -vvv，定位最后一行实际报错（不是“Discovered Package…”那几行） - 检查是否因
autoload未生效导致类找不到：运行php -d display_errors=1 -d error_reporting=-1 vendor/autoload.php，看是否抛出Class not found - 确认
vendor/bin下的二进制文件（如phpunit、phpcs）权限是否可执行（Linux/macOS 下可能因 git clone 丢失 x 权限） - 若报错含
Call to undefined function，大概率是扩展缺失（如mbstring、xml），而非脚本本身问题——用php -m核对
composer.json 里 script 引用了未安装的全局命令
有些项目在 "scripts" 里写了 "post-install-cmd": ["npm install", "yarn build"] 这类前端命令，但宿主机根本没装 npm 或 yarn。Composer 不校验这些命令是否存在，直到执行时才崩。
错误现象通常是：sh: 1: npm: not found 或 /bin/sh: yarn: command not found，但提示位置藏在 verbose 日志深处。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用
composer run-script --list查看所有定义的 script，人工扫一遍有没有非 PHP 命令 - 检查 CI/CD 脚本是否漏装基础工具链（Node.js、yarn、pnpm 等）
- 生产环境部署时，应禁用含前端构建的 script：加
--no-scripts参数，后续单独处理静态资源 - 若必须保留，改用
if command -v npm >/dev/null 2>&1; then npm install; fi包一层防御逻辑
autoload_classmap.php 生成失败或路径映射错位
post-install-cmd 中的 @php artisan package:discover 本质是靠自动加载机制找到服务提供者。一旦 vendor/composer/autoload_classmap.php 没生成、为空，或 composer.json 里 "autoload" 配置有误（比如路径写成 app/Providers 却实际是 app/providers），就会卡在这一步。
- 手动触发 autoload 重建：
composer dump-autoload -o，观察是否报路径不存在 - 检查
composer.json的"autoload"和"autoload-dev"是否混用 psr-4 与 classmap，尤其注意大小写和斜杠方向（Windows 下\可能被误解析） - 确认
vendor/composer/installed.json存在且非空——如果它为空，说明install实际中途失败，只是没报错 - Laravel 项目要额外验证
bootstrap/autoload.php是否仍引用vendor/autoload.php，旧版骨架可能残留自定义加载逻辑
PHP 版本或扩展不满足脚本运行时要求
脚本本身能跑，但依赖的某个类在当前 PHP 环境下不可用。例如 symfony/console v6 要求 PHP >=8.0，而你用 PHP 7.4 执行 php artisan，报错却显示在 post-install-cmd 阶段。
这种错最隐蔽：Composer 安装成功了，lock 文件也匹配，但脚本一执行就跪，错误信息里往往只有 Fatal error: Uncaught Error: Call to undefined function 或 PHP Parse error。
- 别只看
composer install输出，一定要单独跑一遍触发脚本的命令，比如php artisan list或vendor/bin/phpunit --version - 用
php -v和php -m对照composer.lock里每个包的"platform"字段（如有）和"require"中的 PHP/扩展约束 - 若项目用了
"config": {"platform": {"php": "8.2.10"}}，而你本地是 8.1，即使加了--ignore-platform-reqs，脚本运行时仍会因语言特性缺失而崩溃 - 某些扩展（如
intl）在 CLI 和 Web SAPI 下启用状态可能不同，用php -i | grep intl确认 CLI 模式已加载
