post-install-cmd是composer在composer install成功且vendor/新建或重建时自动触发的生命周期事件，需在composer.json根级scripts中严格命名为"post-install-cmd"并配置为数组或字符串命令，否则静默不执行。
post-install-cmd 不是命令，是 Composer 在 composer install 成功后自动触发的生命周期事件点；它本身不干活，得你往 composer.json 的 scripts 里填具体操作，否则全程静默。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
为什么你的 post-install-cmd 总是“没反应”
脚本没执行，90% 是因为名字写错了或位置放错了：
- 钩子名必须严格为 post-install-cmd（不能是 postinstall-cmd、after-install 或 post-install）
- scripts 字段必须在项目根目录的 composer.json 顶层，不能塞进 extra 或 config 里
- 执行时加了 --no-scripts（CI 环境默认常开），所有钩子直接跳过
- vendor/ 已存在且 composer.lock 没变，Composer 会跳过安装流程，自然也不触发 post-install-cmd
post-install-cmd 和 post-create-project-cmd 的关键区别
post-create-project-cmd 只在 composer create-project 场景下生效，且只认被安装包（比如 topthink/think）自己 composer.json 里声明的脚本——你在本地项目里加了它，再跑 composer install 完全无效。
而 post-install-cmd 是通用钩子：只要运行 composer install 触发了依赖安装（首次或 composer.lock 变更），它就执行。
常见误用：
- 把初始化逻辑（如复制 .env.example）全塞给 post-create-project-cmd，结果 git clone + install 就失效
- 想让新同事拉代码后一键就绪，却漏配 post-install-cmd，只能靠文档喊“记得手动 cp .env”
怎么写才真正跨平台、可维护
别用单字符串写法，容易在 Windows 或 CI 上因空格/引号崩掉：
- ✅ 推荐数组形式："post-install-cmd": ["@php -r \"file_put_contents('.env', file_get_contents('.env.example'));\"", "php artisan key:generate"]
- ✅ 用 @php 而不是裸 php，避免 PHP 版本或 ini 配置错乱
- ✅ 复杂逻辑抽成独立 PHP 脚本（如 scripts/init-env.php），再通过 "@php scripts/init-env.php" 调用，便于调试和单元测试
- ❌ 避免 shell 片段直接写 cp .env.example .env——Windows 下失败，也绕不开权限问题
- ❌ 别在脚本里调 exec('composer install')，会递归死锁
最容易被忽略的执行上下文细节
Composer 执行脚本时，当前工作目录（getcwd()）是 composer.json 所在目录，但：
- vendor/autoload.php 已加载完成，可放心 require 第三方类
- $_SERVER['COMPOSER_DEV_MODE'] 可用，但 $_ENV 未注入，环境变量要用 getenv() 或 $_SERVER
- 若需读配置，从 __DIR__.'/../composer.json' 解析最稳，别依赖 extra 以外的字段
- 命令失败（非零退出码）会中断后续所有脚本，别用 || true 掩盖问题，应前置判断（如 if [ ! -f .env ];）
