不推荐直接修改 php.ini，因 Composer CLI 可能未加载该配置，常见于 CLI 与 Web 配置分离、Docker 容器隔离、一键环境多 PHP 实例等场景；应优先使用 php -d memory_limit=-1 composer install 或 COMPOSER_MEMORY_LIMIT=2G 等临时精准方案。
不推荐直接修改 php.ini 解决 Composer install 内存不足问题。它看似一劳永逸，实则容易掩盖真实配置路径、干扰其他 CLI 工具、且在 Docker/CI 等多环境场景下完全失效。
为什么改了 php.ini 还报 Allowed memory size exhausted
Composer 命令由 PHP CLI 执行，但它未必读你改的那个 php.ini。常见断层点：
-
php --ini输出的Loaded Configuration File路径为空，说明 CLI 没加载任何配置文件 - 你改的是 Apache 或 Nginx 下的
php.ini（比如/etc/php/8.2/apache2/php.ini），而 CLI 默认用/etc/php/8.2/cli/php.ini - Docker 容器里运行
composer install，宿主机改了没用，得进容器执行docker exec -it app php --ini查真正路径 - 某些一键环境（MAMP、XAMPP）为 CLI 单独维护一份
php.ini，which php和php -v的路径必须和php --ini对得上
php.ini 修改后必须重启什么服务
只对 CLI 有效：不需要重启 Web 服务器（Apache/Nginx），但要确保终端新开一个 shell 或重新登录，否则旧进程仍缓存旧配置。若你在 IDE 终端或 CI 脚本中调用 Composer，需确认该环境是否继承新配置——多数 CI（如 GitHub Actions）默认不继承用户级 php.ini 变更。
- Linux/macOS：改完
/etc/php/*/cli/php.ini后，直接运行php -r "echo ini_get('memory_limit');"验证输出是否为新值 - Windows + WSL：注意 Windows 和 WSL 可能共存两套 PHP，优先用 WSL 内的
php --ini - 改
memory_limit = 2G，别写2048M—— PHP 8.1+ 某些小版本对单位解析不一致，G更可靠
改 php.ini 的替代方案（更安全、更可控）
临时加参数比永久改配置更符合实际协作与部署逻辑：
- 开发机上跑
php -d memory_limit=-1 composer install：-1 表示不限制，跳过所有 PHP 层内存拦截 - CI 脚本中写
COMPOSER_MEMORY_LIMIT=2G composer install：Composer 自身识别该变量，不依赖 PHP 配置 - Dockerfile 中加
ENV COMPOSER_MEMORY_LIMIT=2G：比改容器内php.ini更轻量，且不会影响其他 PHP CLI 命令 - 生产部署脚本里避免
-1，用php -d memory_limit=2G显式限定，防止 OOM killer 杀进程
真正容易被忽略的是：即使 php.ini 改对了，如果项目启用了 opcache.preload，Composer 在生成 autoload 时可能提前加载大量类定义，导致内存峰值翻倍——这种情况下，php -d opcache.enable=0 -d memory_limit=2G composer install 才是实际生效的组合。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
