--no-scripts是唯一可靠方式，因scripts字段仅声明钩子，执行由命令参数控制；删空字段、设环境变量或用其他参数均无效，且composer.lock更新或composer update会恢复脚本。

直接加 --no-scripts 参数，这是唯一可靠方式。 其他任何操作（删 scripts 字段、设环境变量、改配置）都不能真正阻止脚本在 composer install 时执行。

为什么必须用 --no-scripts？

Composer 的脚本执行逻辑和配置解析是解耦的：scripts 字段只是声明钩子，是否运行完全由命令参数控制。删空该字段、设为 {} 或 []，只会让 Composer “没东西可跑”，但不等于“跳过执行”——一旦别人提交了带脚本的 composer.lock，或你后续执行 composer update，脚本就自动回来了。

官方只识别 --no-scripts 这个原生命令行开关（Composer 2.2+），它被文档明确支持，且等效于不存在的 COMPOSER_NO_SCRIPTS=1 环境变量（该变量实际不被识别）。

• --no-dev、--no-interaction、--quiet 对脚本零影响
• --no-autoloader 会彻底跳过 vendor/autoload.php 生成，通常不该和 --no-scripts 同时用，否则运行时报 Class not found
• composer run-script 不受 --no-scripts 影响——它本来就是专为执行脚本设计的命令

composer install --no-scripts 实际效果

它跳过所有 scripts 中定义的命令，包括：

• post-install-cmd
• pre-autoload-dump
• post-autoload-dump
• 任何自定义脚本名（如 build-assets）

但以下核心行为照常发生：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 依赖下载与安装
• vendor/autoload.php 生成（这是 Composer 自身流程，非脚本）
• composer.lock 文件更新（如果需要）

常见误操作：在 Docker 构建中同时加 --no-scripts --no-autoloader，结果运行时报 Class not found。

想只禁用某一个脚本怎么办？

Composer 原生不支持按名称禁用单个脚本，--no-scripts 是全局开关。若需精细控制，只能临时修改 composer.json 的 scripts 段落：

• 手动注释或删除目标脚本行，例如删掉 "post-install-cmd": "php artisan optimize"
• 自动化场景可用 jq 临时 patch：jq 'del(.scripts."post-install-cmd")' composer.json > composer.json.tmp && mv composer.json.tmp composer.json
• 某些包（如 Laravel）依赖 post-autoload-dump 生成优化 classmap，禁用后可能导致类加载变慢或失败

注意：disabled-plugins 和 --no-plugins 管的是插件，不是 scripts，两者完全无关。

最易被忽略的一点：脚本禁用只解决“谁执行”的问题，不解决“执行什么”。即使加了 --no-scripts，如果项目逻辑依赖某个脚本生成的文件（比如前端打包产物），后续运行仍可能报错。