使用 --no-scripts 参数可跳过 Composer 安装或更新后的所有脚本执行，适用于 CI/CD 或调试环境；若需精细控制，可通过临时 composer.json 或 composer run 显式调用指定脚本。
安装时跳过 post-install-cmd 等脚本执行
用过 Composer 的朋友都知道，它在执行完 install 或 update 命令后，总会自动触发 scripts 里定义的那些钩子，比如 post-install-cmd 和 post-update-cmd。这在持续集成（CI/CD）或者临时调试环境里，常常会带来意想不到的麻烦——要么构建失败，要么就是无谓地拖慢流程。怎么解决？最直接的办法就是加上 --no-scripts 这个参数。
composer install --no-scripts：这条命令会彻底跳过所有脚本的执行，无论是pre-还是post-开头的钩子，一个都不跑。composer update --no-scripts：同理，在更新依赖的场景下也适用。- 关键在于，这个参数只抑制脚本的调用，并不会影响依赖的解析和下载过程。所以，它非常适合用来快速验证 lock 文件，或者构建一个轻量级的运行环境。
composer.json 中禁用特定脚本的写法
那么问题来了，如果只想屏蔽某类特定的脚本呢？比如说，只想跳过 post-install-cmd，但保留 pre-install-cmd 的逻辑。遗憾的是，Composer 本身并不支持按脚本名称来选择性跳过。不过，我们完全可以换个思路，通过临时修改配置来达到目的。
- 一种方法是，在执行命令前，通过设置
COMPOSER环境变量，让它指向一个精简版的composer.json文件。在这个文件里，你可以直接删掉或者清空"scripts"字段。 - 另一种更彻底的做法，是同时使用
--no-plugins和--no-scripts参数，这样可以防止第三方插件再注入额外的脚本逻辑。 - 这里需要特别提醒一下：有些框架或包（比如 Lara vel 的
php artisan optimize）会把关键的初始化逻辑放在post-install-cmd里。如果你跳过了这些脚本，项目可能无法直接运行，后续需要手动补上相应的操作。
CI 环境中常见误用与兼容性问题
在 GitHub Actions、GitLab CI 这类自动化环境里，因为忽略了执行上下文而踩坑的情况并不少见。
- 首先，
--no-scripts参数不会影响autoload文件的生成。但麻烦在于，有些脚本的执行恰恰依赖于自动加载器。跳过了脚本，后续命令就可能报出Class not found的错误。 - 其次，在 Docker 分层构建中，如果只缓存了
vendor/目录，却没有缓存vendor/autoload.php的生成结果，那么使用--no-scripts可能会掩盖掉自动加载未被正确触发的问题。 - 再者，在 PHP 8.2 及更高版本中，某些脚本可能调用了已被废弃的函数（例如
create_function）。跳过脚本确实能暂时规避掉警告信息，但这终究是治标不治本。正确的做法，应该是推动上游修复这些兼容性问题。
替代方案：用 composer run 显式控制脚本
从 Composer 2.4 版本开始，社区更推荐一种更清晰、更可控的执行方式，那就是用显式调用来替代隐式的钩子触发。
- 具体做法是，把原来写在
post-install-cmd里的命令，移到自定义脚本中。例如，在composer.json里定义："scripts": {"build": "php build.php"}。 - 这样一来，安装时就可以放心使用
composer install --no-scripts。等到真正需要的时候，再通过composer run build来显式执行构建任务。 - 这种做法的好处显而易见：它把依赖安装和项目构建这两个步骤彻底解耦了。既能避免脚本在不该执行的时候被意外触发（比如本地开发时，可能根本不需要生成前端资源），也让整个流程的意图更加清晰。
说到底，跳过脚本执行本身并不复杂。真正的挑战在于，你得心里有数：哪些脚本会修改文件系统？哪些会变动配置？又有哪些依赖了外部服务？这些操作即使跳过了也不会立刻报错，但却很可能导致后续命令静默地失败。搞清楚这些，才是用好 --no-scripts 的关键。
