CI/CD中必须用composer install而非update，因update会重写composer.lock导致依赖不可控；需校验lock与json匹配、缓存~/.composer/cache、部署加--no-dev等三参数、通过composer scripts标准化执行。
CI/CD里必须用 composer install，禁用 composer update —— 否则依赖树就不可控，线上出错时连回滚依据都没有。
为什么CI中死守 composer install 而不是 composer update
因为 composer update 会重写 composer.lock，哪怕只是 monolog/monolog:2.10.0 → 2.10.1 这种 patch 升级，也可能触发未覆盖的边界逻辑。测试通过，线上却报 Class not found 或 Method not found。
CI 的唯一职责是“还原”：用已提交的 composer.lock 精确复现本地和生产环境的依赖树。
-
composer install必须有composer.lock才能运行；没提交它，CI 直接失败 - CI 脚本开头加
composer validate --strict，校验composer.json和lock是否匹配 - 本地可配 pre-commit 钩子：
composer install --dry-run，提前发现 lock 过期
缓存 ~/.composer/cache 而不是 vendor/
缓存 vendor/ 看似快，实则危险：不同 PHP 版本、ext-apcu 开关状态、甚至大小写敏感系统生成的 autoload 文件不兼容，会导致随机 Cannot declare class 或 include(): Failed opening 错误。
真正安全的缓存对象是 Composer 自己的下载缓存目录，它只存 zip/dist 包，跟环境完全解耦。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- GitHub Actions 示例：
path: ~/.composer/cache，key中必须含${{ hashFiles('**/composer.lock') }} - GitLab CI 示例：
cache: paths: [~/.composer/cache]，别写vendor/ - 缓存失效最常见原因：本地手动生成了新
lock但没提交，导致 key 不匹配，CI 每次走冷安装
生产部署必加的三个参数：--no-dev、--optimize-autoloader、--classmap-authoritative
这三个不是性能“优化项”，而是 autoload 正常工作的底线。
不加的话，PHP 每次自动加载都要遍历 PSR-4 映射、执行 file_exists() 探测，IO 开销大，还容易因符号链接、大小写或 opcache 失效漏类。
-
--optimize-autoloader把命名空间映射编译成静态数组 -
--classmap-authoritative告诉 Autoloader：“不在 classmap 里的类，一律不存在”，跳过所有文件系统探测 -
--no-dev不只是提速，更是安全边界：dev 依赖（如phpunit、symfony/var-dumper）可能引入未审计的远程调用或调试后门
CI中调用自定义 scripts 的正确姿势
composer.json 里的 "scripts" 是 CI 命令标准化的核心，不是装饰项。
比如你写了 "test": "phpunit --configuration phpunit.xml"，CI 就该统一跑 composer test，而不是直接调 phpunit——这样既解耦工具路径，又能让所有环境共用同一套执行逻辑。
- 支持透传参数：
composer test -- --filter=TestLogin会完整传给 PHPUnit - 避免在 script 中硬编码路径（如
./vendor/bin/phpunit），应依赖 Composer 的 bin 自动发现机制 - 若需区分环境，可用
COMPOSER_NO_INTERACTION=1或COMPOSER_MEMORY_LIMIT=-1控制行为
最容易被忽略的是 COMPOSER_MEMORY_LIMIT：CI 环境（如 GitHub Actions 默认 7GB、GitLab Shared Runner 常为 4GB）容易因 Composer 加载依赖图时峰值内存占用高而被 kill，报 Killed 或 PHP Fatal error: Allowed memory size exhausted。这不是 PHP 配置问题，得在脚本开头显式设 export COMPOSER_MEMORY_LIMIT=-1 或 2G。
