内存超限时应运行 composer install –no-plugins –no-scripts –no-dev，它能跳过插件加载、脚本执行和开发依赖解析，显著降低内存占用，成功安装基础 vendor；后续需手动补全 autoload 或上传预构建资源。
内存超限时 composer install 直接崩溃怎么办
共享主机通常限制 PHP 内存为 128M 或更低，而 Composer 默认会加载插件、执行脚本、解析完整依赖图——这很容易触发 Fatal Error: Allowed memory size exhausted。最直接有效的缓解方式，是跳过非必需的运行时环节。
-
--no-plugins：禁用所有插件（包括composer/installers等），避免插件初始化和钩子调用带来的额外内存开销 -
--no-scripts：跳过post-install-cmd等脚本，防止执行php artisan optimize、npm run dev类操作——这些在共享主机上往往根本不可用或极耗资源 - 二者必须同时使用：
--no-plugins单独用仍可能因脚本触发 OOM；--no-scripts单独用则插件加载阶段就可能崩掉
composer install --no-plugins --no-scripts 能装出可用的 vendor 吗
能，但取决于你的项目是否真依赖插件或脚本完成关键构建。绝大多数纯 PHP 依赖（如 monolog/monolog、guzzlehttp/guzzle）仅需解压+自动加载即可工作。
- 安全前提：确认你没在
composer.json里靠插件修改安装路径（比如自定义installer-paths），否则--no-plugins会导致包被装到错误位置 - 常见踩坑：laravel 项目若启用了
laravel/framework的 post-autoload-dump 脚本，跳过它会导致vendor/autoload.php未刷新——此时需手动补跑composer dump-autoload --optimize（该命令内存占用低，通常能成功） - 注意
autoload部分仍会生效：类映射、PSR-4 自动加载规则照常写入vendor/autoload.php，不影响运行时加载
为什么不用 --no-dev？它和内存关系大吗
--no-dev 主要减少磁盘空间和依赖数量，对内存峰值影响很小——Composer 内存压力主要来自依赖解析、事件调度、插件实例化，而不是“多装几个包”。但它是合理搭配项：
- 开发依赖（如
phpunit/phpunit）通常体积大、依赖深，禁用后可缩短执行时间，间接降低超时风险 - 共享主机一般不跑测试，
--no-dev是安全且推荐的附加选项 - 最终推荐命令：
composer install --no-plugins --no-scripts --no-dev - 别用
--optimize-autoloader在这里：它需要遍历全部类文件生成静态映射，在内存紧张时反而容易失败
装完发现某些功能异常，先查哪几个地方
跳过插件和脚本后，最常出问题的是自动加载优化缺失、配置未生成、前端资源未编译——但这些都不是 Composer 本身的问题，而是你项目约定的构建步骤被跳过了。
- 报
class not found：先运行composer dump-autoload --optimize（轻量级，不触发插件/脚本） - 报
config/app.php缺失或缓存未生成：说明项目依赖php artisan config:cache这类脚本，得手动在本地生成好再上传，不能指望共享主机执行 - 前端报 404：
resources/assets到public的复制、webpack 编译等，必须在本地或 CI 完成，再把public/js等目录整体上传 - 永远别在共享主机上运行
composer update：解析整个 Packagist 索引极其吃内存，install才是部署唯一可行操作
真正麻烦的从来不是命令加什么参数，而是搞清哪些步骤本就不该发生在目标环境里——共享主机只负责运行，不负责构建。