容器执行 composer install 必须加 --no-scripts，因容器常缺 node.js、数据库连接、写权限或 stdin，导致 post-install-cmd 等钩子报错退出；该参数跳过所有 scripts 定义的钩子，但保留 autoload.php 生成等核心流程。
容器里执行 composer install 为什么必须加 --no-scripts
因为容器环境通常缺少脚本依赖的运行条件，比如未安装 Node.js、无数据库连接、无写入权限或 stdin 不可用，导致 post-install-cmd 等钩子直接报错退出（常见错误：Script handling the post-install-cmd event returned with error code 1）。这不是脚本本身有问题，而是执行上下文缺失。
加 --no-scripts 是唯一能绕过这类失败的可靠方式——它不修改配置、不依赖环境变量，也不受 composer.lock 中已声明脚本的影响。
-
--no-scripts对composer install、composer update、composer require均生效（Composer 2.2+） - 它跳过所有
scripts字段定义的钩子：包括pre-install-cmd、post-autoload-dump、post-root-package-install等 - 注意：
--no-scripts不影响vendor/autoload.php生成，那是 Composer 自身流程，不是脚本
为什么删 scripts 字段或设为空数组在容器里依然危险
删掉 "scripts" 或写成 "scripts": {} / "scripts": [] 在容器构建中看似“干净”，实则无效且易被覆盖。
原因在于：composer.lock 文件可能保留了原始脚本声明；一旦运行 composer update（哪怕只更新一个 patch 版本），Composer 就会从远程包的 composer.json 重新读取并还原 scripts 字段——而你根本没机会审核。
- 空对象或空数组会被 Composer 忽略，但执行开关仍处于“开启”状态，只是找不到对应命令，可能静默失败或报错
- 某些框架（如 Laravel）的包依赖
post-autoload-dump生成优化映射，清空后若未手动补上composer dump-autoload --optimize，会导致运行时类加载变慢甚至失败 - CI/CD 流水线中若混用本地开发与容器构建，容易出现“本地能跑，容器挂掉”的不一致问题
容器安全加固：--no-scripts 和 --no-plugins 必须同时用
仅禁用脚本还不够。插件（plugin）和脚本是两套独立机制：--no-scripts 不影响插件事件监听器，而某些恶意插件可在安装阶段执行任意代码（例如篡改 autoloader、注入 loader 钩子）。
真正隔离第三方包行为，需组合使用：
-
composer install --no-scripts --no-plugins：彻底跳过所有用户定义脚本 + 所有插件生命周期事件 -
--no-plugins不删除vendor/中的插件代码，只是本次不激活；不影响依赖下载和 autoload 生成 - 两者缺一不可：单独用
--no-scripts时，插件仍可能触发PluginInterface::activate()并执行危险逻辑
Dockerfile 中容易漏掉的关键细节
在 Dockerfile 里写 RUN composer install --no-scripts 是基础操作，但以下三点常被忽略：
- 必须显式指定
--no-dev（除非你真需要 dev 包），否则require-dev下的包及其脚本也会被拉取并可能触发 - 不要顺手加上
--no-autoloader：它会跳过vendor/autoload.php生成，导致后续 PHP 运行时报Class not found - 如果项目依赖
post-autoload-dump生成的vendor/composer/autoload_classmap.php（如 Laravel 的优化映射），禁用脚本后需手动补一句composer dump-autoload --optimize，否则性能下降明显
最简健壮写法通常是：composer install --no-scripts --no-plugins --no-dev --optimize-autoloader，再根据是否需要 classmap 补充 dump 命令。
