--no-scripts 是跳过所有 Composer 脚本执行的开关，用于规避因环境缺失、权限不足或交互导致的安装失败，与静默日志无关；必须加的情况包括：脚本含系统调用但环境不支持、只读文件系统、CI 中需避免交互、本地测试需禁用副作用操作。
加 --no-scripts 不是为了“更安静”，而是为了跳过那些可能卡住、报错或破坏环境的自定义命令——它和静默无关，只管执行逻辑。
什么时候必须加 --no-scripts
你遇到这些情况之一，就该加：
-
post-install-cmd或pre-autoload-dump里写了exec('npm install')、system('chmod +x bin/*')这类系统调用，而目标环境没装 npm / 没权限 / 路径不对，导致composer install直接失败 - 项目用了 Laravel 的
php artisan storage:link作为post-install-cmd，但部署机是只读文件系统，脚本一跑就报错退出 - CI 流水线里要先拉代码、再构建镜像，但
post-root-package-install里有readline()或交互式初始化（哪怕加了--no-interaction，它也不检查这个） - 本地开发时想快速装依赖测兼容性，但某个脚本会自动清缓存、重启服务甚至发 Slack 通知——你根本不想触发它
--no-scripts 和 --quiet 完全不是一回事
--quiet 只压日志；--no-scripts 是直接跳过整个脚本段落，连执行都不执行。常见误解：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 以为加了
--quiet就能屏蔽脚本里的echo—— 错，echo是直接写 stdout，--quiet管不了 - 以为
--no-interaction能让脚本不卡住 —— 错，它只影响 Composer 自己的交互逻辑，脚本里自己调QuestionHelper::ask()，照样停住 - 在 Docker 构建阶段加
--no-scripts后发现autoload没生成 —— 因为有些脚本负责写vendor/autoload.php，跳过之后得手动补composer dump-autoload --optimize
CI/CD 里怎么安全用 --no-scripts
它不该是默认开关，而应是有条件启用：
- 构建镜像时用：
composer install --no-interaction --no-scripts --prefer-dist --optimize-autoloader，等镜像启动后再进容器手动跑关键脚本 - 部署到生产前校验阶段，用
--no-scripts快速验证依赖能否解析+下载，避免被某个坏脚本拖垮整条流水线 - 如果项目脚本确实必要（比如生成配置、编译前端），那就别跳过，改用环境变量控制行为：
if (getenv('COMPOSER_NO_SCRIPTS') !== '1') { ... }，CI 里设COMPOSER_NO_SCRIPTS=1 - 注意：某些框架（如 Symfony Flex）的插件会在
post-install-cmd注入关键逻辑，盲目加--no-scripts可能导致 bundle 未注册、路由加载失败
真正容易被忽略的是：脚本是否被跳过，不会在日志里提醒你——它就静默地没执行。如果你依赖某个脚本做的事（比如写 env 文件、建符号链接），又没意识到它被跳过了，问题会延后爆发，而且很难定位。
