需修改 CLI 模式下的 php.ini 或用 php -d memory_limit 临时指定内存；Composer 运行于 CLI，与宝塔面板中网站 PHP 配置无关，应通过 php --ini 确认实际加载的配置路径，并优先采用 php -d 方式安全覆盖。
宝塔面板里跑 composer install 报 Allowed memory size exhausted，不是改宝塔界面里的 PHP 设置就能解决的——它根本没动到 CLI 模式用的 PHP 配置。
确认你改的是 CLI 的 php.ini，不是网站的
宝塔面板默认给 Web 服务（如 Nginx + PHP-FPM）和终端命令行（CLI）配了两套独立的 php.ini。Composer 走的是 CLI，所以改网站设置页里的“PHP 配置”完全无效。
- 在 SSH 里运行
php --ini，看 “Loaded Configuration File” 指向哪——通常是/www/server/php/82/etc/php.ini这类路径（数字 82 表示 PHP 8.2 版本） - 别直接改
/etc/php/8.2/cli/php.ini，宝塔管理的 PHP 版本不会读那个 - 改完记得不用重启任何服务，CLI 下次执行就生效
临时加内存最稳：用 php -d memory_limit 直接覆盖
比起改配置文件，命令行临时指定更可靠，也避免误伤其他脚本：
- 进项目目录，运行：
php -d memory_limit=2G /www/server/php/82/bin/php /www/server/php/composer.phar install - 注意路径要对：
/www/server/php/82/bin/php是宝塔 PHP CLI 的真实路径，/www/server/php/composer.phar是宝塔内置 Composer 的位置 - 别写
1536M，某些 PHP 版本对M单位解析异常，统一用G - 如果还报错，说明不是内存问题，而是锁文件损坏或插件冲突，先试
composer clear-cache和删vendor再重来
COMPOSER_MEMORY_LIMIT 在宝塔里基本没用
这个环境变量是 Composer 自己读的，但它只控制依赖求解阶段；而宝塔环境下，内存爆掉最多见于解压 zip 或生成 autoload 映射——这部分由 PHP 进程扛，不受该变量约束。
- 设了
COMPOSER_MEMORY_LIMIT=-1但依然报错？正常。这不是变量失效，是它本来就不管那部分 - 宝塔计划任务或面板内“一键部署”里填命令时，环境变量容易丢失，
php -d方式更可控 - 如果你非要用环境变量，得在 shell 启动前注入，比如在计划任务命令前加：
export COMPOSER_MEMORY_LIMIT=2G && php /www/server/php/composer.phar install
CI 式部署建议：加 --no-dev -o 组合拳
宝塔常用于上线部署，这时根本不需要 require-dev 和调试用的 autoload 映射：
- 命令写成：
php -d memory_limit=1G /www/server/php/composer.phar install --no-dev -o -
--no-dev跳过所有开发依赖，省下几百 MB 内存 -
-o（即--optimize-autoloader）跳过动态 classmap 生成，改用静态映射，速度快、内存低 - 这两项加起来，常能把峰值内存从 1.8G 压到 600MB 以内
真正卡住你的，往往不是内存数字本身，而是宝塔把 PHP CLI 配置和 Web 配置混在一起管，让人误以为改了面板就等于改了命令行。盯住 php --ini 输出的路径，其它都是干扰。
