composer install --no-scripts 的核心作用是只安装依赖并生成自动加载文件，但完全跳过 composer.json 中 scripts 字段定义的所有钩子命令。
跳过脚本执行：它到底干了什么？
composer install --no-scripts 的核心作用是：只安装依赖、生成自动加载文件（vendor/autoload.php），但**完全跳过 composer.json 中 scripts 字段定义的所有钩子命令**，比如 post-install-cmd、pre-autoload-dump、post-update-cmd 等。
它不是“禁用所有自动化”，而是精准切断脚本链——插件仍会加载（除非加 --no-plugins），autoloader 仍会生成（除非加 --no-autoloader），只是那些写在 "scripts" 里的 PHP 命令、Shell 脚本、Artisan 调用等，统统不跑。
哪些场景下必须用它？
这不是“可选优化”，而是特定环境下的必要控制手段：
- CI/CD 流水线中分步执行：先
composer install --no-scripts下依赖，再手动运行php artisan key:generate、npm run build、php artisan migrate:fresh --seed等，确保顺序可控、失败可定位 - 生产部署时规避副作用：避免
post-install-cmd自动清缓存导致线上请求短暂 500，或尝试写入不可写的storage/logs目录而中断部署 - 调试安装失败原因：当
composer install卡在某个脚本报错（如 “Class not found in post-install-cmd”），加--no-scripts能快速验证是否纯依赖问题 - 安全受限环境：在沙箱、只读容器或审计阶段，禁止任何非必需的代码执行，降低攻击面
不加它可能踩哪些坑？
看似省事的默认行为，常在上线前突然暴雷：
-
.env没生成 → Laravel 启动直接报Application key not set - 前端资源未编译 → 页面 CSS/JS 404，功能残缺
-
storage和bootstrap/cache目录权限没设 → 日志写入失败、配置缓存无法生成 - 数据库迁移被跳过 → 表结构缺失，API 返回 500 或空数据
- 脚本里调用了本地开发工具（如
php-cs-fixer）→ 生产环境无此命令，安装直接中断
这些都不是 Composer 的 bug，而是项目把“初始化逻辑”耦合进了脚本。用 --no-scripts 就等于主动解耦——但解耦之后，你得自己补上那几步。
生产环境推荐组合参数
单用 --no-scripts 还不够。真实部署应搭配其他关键开关：
composer install --no-dev --prefer-dist --no-scripts --optimize-autoloader --no-progress
-
--no-dev：不装require-dev里的包（如 PHPUnit、PHPStan），减小体积、消除安全隐患 -
--prefer-dist：优先从压缩包安装，比 Git clone 快且稳定 -
--optimize-autoloader：生成更高效的类映射，提升运行时性能 -
--no-progress：避免 CI 日志刷屏，也防止某些终端解析进度条出错
记住：跳过脚本不是偷懒，而是把“谁在什么时候做什么”这件事，从黑盒交给你自己画线。漏掉哪一步，应用就卡在哪一步——尤其是密钥生成、目录权限、资产构建这三类操作，几乎每个 PHP 项目都依赖脚本完成，却最容易被 --no-scripts 静默绕过。
