composer 不支持按包过滤 –no-scripts，唯一可行方案是修改目标包的脚本逻辑，通过环境变量运行时判断是否执行；或临时删除 vendor 中该包 composer.json 的 scripts 字段。
composer install –no-scripts 会跳过所有包的脚本，没法按包过滤
Composer 原生不支持 --no-scripts 后再指定“只跳过某几个包”的语法。这个选项是全局开关，一旦启用，post-install-cmd、pre-autoload-dump 等所有脚本全被忽略，包括你其实想保留的那些。
常见错误现象是：加了 --no-scripts 后，某个依赖包的自动配置没生效（比如 laravel-mix 没触发 npm install），结果本地环境跑不起来，误以为“能单独关掉它”。
- 没有
--no-scripts-for vendor/package-name这种写法，也不存在 composer 插件能安全实现该行为 -
composer require --no-scripts和install行为一致，同样无法按包控制 - 试图在
composer.json的scripts里用条件判断跳过某包——不行，脚本执行时包已解压，且 Composer 不提供当前操作包名的上下文变量
真正可行的替代方案：改写脚本逻辑，加运行时判断
如果你控制的是那个“想跳过的包”，最稳妥的做法是在它的 composer.json 脚本里主动检查环境变量或文件标记，决定是否执行。这是唯一被 Composer 官方机制支持的“按包跳过”路径。
使用场景：你维护一个私有包 acme/legacy-tool，它的 post-install-cmd 会调用老旧 Python 脚本，在 CI 或 docker 构建时根本不需要，但开发机上又得留着。
- 在包的
composer.json中把脚本改成："post-install-cmd": "if [ -z "$SKIP_LEGACY_TOOL" ]; then python legacy-setup.py; fi" - 安装时通过环境变量控制：
SKIP_LEGACY_TOOL=1 composer install - 如果脚本是 PHP 写的，可用
getenv('SKIP_LEGACY_TOOL')判断，比 shell 更跨平台 - 注意：不要用
$_SERVER，CLI 环境下不可靠；优先用getenv()或$_ENV
临时绕过：删掉 vendor 里的脚本定义再装
适用于你**不维护该包**，但又必须跳过它的某个危险脚本（比如执行 rm -rf / 的第三方包——别笑，真有）。
原理是 Composer 只读取 vendor/{vendor}/{name}/composer.json 里的 scripts 字段，只要提前清空它，就等于“让这个包没脚本”。
- 先
composer install一次，让包下载到vendor - 手动编辑
vendor/some-vendor/bad-package/composer.json，删掉整个"scripts"字段（保留其他内容） - 再运行
composer install --no-dev（避免重装触发脚本），或直接composer dump-autoload - CI 中可写成脚本：
sed -i '/"scripts": {/,/},/d' vendor/some-vendor/bad-package/composer.json - 风险：下次
composer update bad-package会覆盖修改，需重复操作；不适用于 lock 文件锁定旧版但实际要更新的情况
为什么不能靠插件或钩子拦截特定包的脚本
Composer 的事件系统（如 ScriptEvents::POST_INSTALL_CMD）是广播式的：所有监听者都会收到通知，但**收不到“这次执行脚本的是哪个包”这个信息**。事件对象里只有全局参数，没有来源包标识。
有人试过用 debug_backtrace() 在监听函数里扒调用栈，想从中提取包名——理论上可能，但极其脆弱：
- Composer 版本一升级，内部调用链就变，解析逻辑立刻失效
- 不同命令（
installvsupdate）触发路径不同，兼容成本高 - PHP 错误处理、opcache、SAPI 差异都可能导致 backtrace 缺失关键帧
- 官方明确不承诺事件参数结构稳定，属于未公开 API
所以别碰这个方向。真要隔离，回到“改包自身脚本”或“删 vendor 里脚本定义”这两条路，虽然土，但稳。
最易被忽略的一点：很多团队以为 --no-scripts 是“跳过安装后脚本”，其实它也会跳过 pre-autoload-dump 这类影响 autoloader 生成的脚本——这会导致 class not found 错误，而且报错位置和原因完全对不上。务必确认你跳过的脚本是否参与 autoload 构建。