CI 中不应自动执行 post-install-cmd，需加 --no-scripts 禁用；其操作应拆为独立脚本（如 ci:check、deploy:migrate），由对应阶段按需显式调用，避免上下文错乱与环境风险。
CI 中直接用 composer install 是可行的，但不等于“集成完成”——它只是依赖安装环节，后续构建、校验、推送、远程执行等步骤必须显式编排，否则 CI 产出的产物不可部署、不可复现、权限或环境错乱。
CI 流程里该不该跑 post-install-cmd？
默认会跑，但生产 CI 环境中往往不该让它自动触发：
-
post-install-cmd在composer install成功后执行，但它面向的是本地开发上下文：比如清缓存、生成配置、运行迁移——这些操作在 CI 构建阶段执行毫无意义，还可能因缺少数据库连接或 Web 用户权限而失败 - CI 阶段应加
--no-scripts显式禁用钩子，把真正需要的动作（如php artisan config:cache）拆成独立脚本，由部署阶段按需调用 - 若某些校验逻辑（如 PHPStan 分析、文件权限检查）必须在 CI 中跑，应定义为自定义脚本名（如
ci:check），再通过composer run ci:check显式触发，避免和部署钩子耦合
CI 构建产物怎么传给部署机？
别传 vendor/ 目录，也别传整个项目压缩包后在目标机解压——这绕过了 Composer 的 autoloader 优化机制，且极易因路径、PHP 版本、扩展差异导致类加载失败。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- CI 中只保留源码 +
composer.lock，构建完打个轻量 tag 或 artifact（如myapp-1.2.3.tar.gz），内容不含vendor/ - 部署时用
rsync -avz --delete --exclude="vendor/" ./ user@host:/path/release/同步代码，再远程执行cd /path/release && composer install --no-dev --optimize-autoloader --classmap-authoritative - 如果 CI 和目标机网络隔离，可提前把
composer.phar打包进 artifact，部署脚本中用{{bin/php}} composer.phar install而非系统composer，避免环境不一致
如何防止 CI 中误执行数据库迁移？
这是最常踩的坑：脚本写在 post-update-cmd 里，CI 每次 composer update 就连上生产库跑 migrate，后果严重。
- 迁移命令必须从生命周期钩子里移出，定义为独立脚本，例如：
"deploy:migrate": "php artisan migrate --force --no-interaction" - CI 流水线中完全不调用该脚本；只在人工确认或发布门禁（如 prod 分支合并、手动 approval）之后，由 Deployer 或 Ansible 触发
- 在迁移脚本开头加防护判断：
if [ "$(php -r "echo getenv('APP_ENV') ?: 'local';")" != "prod" ]; then echo "Not in production, exit."; exit 1; fi
真正难的不是让命令在 CI 里跑起来，而是厘清每个动作该在哪一环发生、以谁的身份、在什么上下文里执行——漏掉一次 --no-dev，多传一个 vendor/，少做一次用户权限同步，都可能让上线后的第一个请求就 500。
