必须用php --ini查CLI实际加载的php.ini路径，如/etc/php/8.2/cli/php.ini；若Loaded Configuration File为(none)，则memory_limit为编译默认值128M；修改时单位须大写（如2G）、不可加引号、禁用Xdebug并避免插件干扰。
确认 CLI 模式下真正生效的 php.ini 路径
很多人改了 /etc/php/8.2/apache2/php.ini 却发现 composer install 还是报错，根本原因是 Composer 用的是 PHP CLI 模式，和 Web 服务完全不共用配置文件。必须先定位对的文件，否则所有修改都白做。
运行以下命令查清当前 CLI 实际加载的配置：
-
php --ini—— 看 Loaded Configuration File 行，比如/etc/php/8.2/cli/php.ini - 如果该行显示
(none)或为空，说明 CLI 根本没加载任何php.ini，此时memory_limit是编译默认值（通常是128M） - 验证当前值：
php -r "echo ini_get('memory_limit');"，输出-1或128M才算准
修改 memory_limit 的安全写法与单位陷阱
在确认路径无误后，编辑对应 php.ini 文件，找到 memory_limit 行。这里有两个关键细节常被忽略：
- 单位必须大写：
2G有效，2g或2GB会被 PHP 忽略，退回到默认值 - 设为
-1表示不限制，但实际仍受系统物理内存和ulimit -v限制；生产环境建议设为2G或1536M，而非盲目填-1 - 不要写成
memory_limit = "2G"（加引号），PHP 解析器会把它当字符串处理，导致设置失效
改完不生效？重启终端或重载 shell 配置
Linux/macOS 下改完 php.ini 并保存后，当前终端会话不会自动读取新配置——它仍沿用启动时加载的旧值。必须手动刷新环境：
立即学习“PHP免费学习笔记（深入）”；
- 新开一个终端窗口（最保险）
- 或执行：
source ~/.zshrc（Zsh）或source ~/.bashrc（Bash） - 再运行
php -r "echo ini_get('memory_limit');"确认输出已更新 - Docker 容器内改完需重建容器，单纯
docker exec进去改无效
为什么有时设到 2G 还爆内存？这些坑比配置本身更致命
内存报错不等于“不够”，更多时候是 Composer 卡在低效环节，加内存只是拖延崩溃：
-
which composer返回/usr/bin/composer？那是 shell wrapper，php -d memory_limit=-1 composer install中的-d参数会被忽略；必须用php -d memory_limit=-1 /path/to/composer.phar install - Xdebug 已启用：会让内存占用翻倍，临时禁用更有效：
php -d extension= -d memory_limit=-1 composer install -
composer.lock文件过大（>5MB）：含大量 dev 包哈希和 autoload 映射，解析时全载入内存；CI 中应固定用composer install --no-dev --prefer-dist --no-progress - 旧插件干扰：如
hirak/prestissimo在新版 Composer 下反而引发循环扫描，可全局禁用：composer config -g disable-tls true不相关，真正有效的是删掉或禁用插件
真正要盯住的不是数字，而是 composer install 是否真在“安装”，还是偷偷触发了求解器——后者才是吃内存的大户。
