post-root-package-install 是 Composer 钩子，仅首次 composer install 于根目录时触发一次，无法自动初始化环境；它不生成 autoload.php，仅适合纯 shell 文件操作，业务初始化应使用 composer run init。
post-root-package-install 是什么，它真能自动初始化环境？
不能。Composer 的 post-root-package-install 钩子只在 首次安装根项目依赖时触发一次，且仅当执行的是 composer install（非 update）且当前目录是 root package（即项目根目录）时才生效。它不保证所有开发机都能触发——比如同事用 git clone 后直接 composer install 可能触发，但若先 composer update 或在子目录运行，就完全不会执行。
更关键的是：这个钩子运行时，vendor/autoload.php 还未生成（因为 autoload 是 install 最后一步），所以你无法在钩子里 require 自定义 PHP 脚本或调用项目内类——会报 Class not found 或 Failed opening required 'vendor/autoload.php'。
- 它适合做极轻量、纯 shell 级的准备（如
mkdir -p storage/logs） - 不适合执行数据库迁移、配置生成、前端构建等依赖已加载代码的逻辑
- 不适用于 CI/CD 流水线中多次重跑的场景（只触发一次）
真正可靠的一键初始化该用什么？
用 composer run + 自定义脚本命令，配合清晰的 README 入口。把初始化逻辑拆成可重复执行、有明确依赖关系的步骤，并统一入口。
在 composer.json 的 scripts 段里定义：
"scripts": {
"init": [
"@setup-env",
"@install-deps",
"@build-assets",
"@setup-db"
],
"setup-env": "cp .env.example .env || echo '.env already exists'",
"install-deps": "composer install && npm ci",
"build-assets": "npm run build",
"setup-db": "php artisan key:generate && php artisan migrate:fresh --seed"
}这样新同事只需执行一条命令：composer run init（Composer 2.4+）或 composer run-script init（旧版）。每步失败会中断，且可单独重试（如 composer run setup-db）。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 所有命令都在完整环境（autoload 已加载、node_modules 已装）下运行
- 支持跨平台（Windows 用户可用 Git Bash 或 WSL 执行，避免 PowerShell 权限陷阱）
- 可加条件判断，例如
"setup-db": "[ -f .env ] && php artisan migrate:fresh --seed || echo 'Please run setup-env first'"
如何防止同事漏掉关键步骤？
靠文档不如靠机制。在 composer.json 的 scripts.pre-install-cmd 和 scripts.pre-update-cmd 中加入守门检查：
"scripts": {
"pre-install-cmd": [
"if [ ! -f .env ]; then echo '❌ Missing .env — run \"composer run setup-env\" first'; exit 1; fi"
],
"pre-update-cmd": [
"if [ ! -f vendor/autoload.php ]; then echo '⚠️ vendor/autoload.php missing — run \"composer install\" first'; exit 1; fi"
]
}这样只要同事执行 composer install 或 update，就会被强制校验前置条件。错误信息直白，还带 emoji 提高识别度（终端兼容）。
- 注意：pre-* 钩子在 Windows CMD 下可能因 shell 语法报错，建议在 README 里注明「推荐使用 Git Bash / WSL / macOS/Linux 终端」
- 不要在 pre-* 钩子里尝试自动修复（如自动生成 .env），容易掩盖真实问题
- 检查项要轻量，避免拖慢正常流程（比如别在这里跑
npm ls）
为什么还要保留 post-root-package-install？
它唯一不可替代的用途是：在 vendor 目录创建后、但 autoload 还没生成前，做 纯文件系统操作。比如：
- 确保日志/缓存目录存在：
mkdir -p storage/logs storage/framework/{cache,views,sessions} - 设置本地调试配置（不依赖 PHP）：
echo 'xdebug.mode=debug' >> .phpunit.php - 生成基础 git hook 模板（不执行 hook）：
cp .githooks/pre-commit .git/hooks/pre-commit && chmod +x .git/hooks/pre-commit
这些操作不依赖任何 PHP 类或 node 模块，失败也不会阻断后续流程，只是提升开箱体验。把它当作“物理层初始化”，而把业务逻辑全交给 composer run init。
最常被忽略的是：很多团队把数据库配置写死在 .env.example 里，却忘了告诉新人改哪几行。与其靠脚本猜，不如在 setup-env 命令末尾加一句 echo "✅ Now edit .env: set DB_HOST, DB_USERNAME, DB_PASSWORD" —— 人眼确认比机器猜准得多。
