生产环境不该运行 composer install，根本原因是PHP-FPM以低权限用户（如www-data）运行，无法安全写入vendor/和缓存目录，易触发Permission denied或超时；必须在构建阶段用composer install --no-dev --no-plugins --optimize-autoloader --classmap-authoritative生成vendor/并同步上线，同时禁用opcache时间戳校验并重置opcache。
生产环境不该运行 composer install，报错只是表象，根本问题是权限、超时和执行链失控——必须在构建阶段完成依赖安装并同步 vendor/ 目录。
为什么生产机上运行 composer install 必然出问题
PHP-FPM 进程以 www-data 或类似低权限用户运行，但 composer install 默认要写缓存、生成 autoload_static.php、执行 post-autoload-dump 脚本——这些操作需要写入 vendor/ 和 composer/ 缓存目录，极易触发 Permission denied 或 max_execution_time 超时。更危险的是：若用 root 执行，vendor/ 下文件所有者变成 root，PHP-FPM 读取时可能因 umask 或 SELinux 策略失败；若用 web 用户执行，又可能因临时目录不可写而崩溃。
- 常见错误现象：
file_put_contents(/var/www/app/vendor/composer/autoload_classmap.php): Failed to open stream: Permission denied - CI/CD 中误用
composer install而非composer install --no-dev --optimize-autoloader，导致线上加载慢或类找不到 - 漏加
--no-dev，结果把phpunit、laravel/pint一起装上去，引发Class 'Tests\TestCase' not found
composer install 必须带的三个安全参数
这些不是“可选优化”，而是防止生产环境意外行为的硬性要求。它们影响 autoload 性能、依赖范围和 opcode 缓存有效性。
-
--no-dev：跳过require-dev中所有包，避免引入测试、Linter、IDE Helper 等非运行时依赖 -
--optimize-autoloader：生成vendor/composer/autoload_classmap.php，让类加载走数组查表而非文件系统扫描，显著降低 I/O 开销 -
--classmap-authoritative：告诉 autoloader “所有类都在 classmap 里”，彻底禁用PSR-4文件查找逻辑，防误加载同名但路径错误的类
三者合用命令是：composer install --no-dev --optimize-autoloader --classmap-authoritative。它应在 CI 构建机或本地干净环境中执行，产出完整 vendor/ 后整体同步到生产机。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
部署后必须重置 opcache，否则新类不生效
即使 vendor/ 已同步、参数全对，若 PHP 的 opcache.validate_timestamps=1（默认值），PHP-FPM 仍会缓存旧的 opcode，导致新增类或修改后的类映射无法加载。这不是 Composer 的问题，但常被归咎于它。
- 确认配置：
opcache.enable=1且opcache.validate_timestamps=0（上线后必须关掉时间戳校验） - 部署脚本末尾必须调用
opcache_reset()（通过 CLI 或 HTTP 触发），或重启 PHP-FPM - 若用 Docker，可在部署后执行
docker exec -it php-fpm php -r 'opcache_reset();'
--no-plugins 是防止插件静默执行的关键开关
很多团队以为只要没显式 require 插件就安全，但 composer install 会自动扫描 vendor/ 下所有包的 composer.json，只要含 "type": "composer-plugin" 就尝试激活——哪怕你没开 allow-plugins 白名单，只要漏了 --no-plugins，恶意插件就能在 PackageEvents::PRE_PACKAGE_INSTALL 阶段注入代码。
- 正确写法：
composer install --no-dev --no-plugins --optimize-autoloader（--no-plugins必须紧跟install，不能写成composer --no-plugins install） - 验证是否生效：检查
vendor/composer/autoload_plugins.php是否为空文件；或运行composer diagnose --verbose | grep "Loading plugin"，无输出才表示真正禁用 - CI 脚本中若封装了
bin/composer，需确认它未默认注入--plugins参数
真正麻烦的从来不是报错本身，而是你以为它只是权限问题，却忽略了插件可能已悄悄执行、签名验证没开、opcache 没清、甚至 vendor/ 被复制到了 Web 可访问路径下——这些点串起来，才是生产环境 Composer 安全的完整防线。
