PHP 的 memory_limit 实际生效位置在 PHP-FPM 容器内的 /usr/local/etc/php/php.ini 或 /usr/local/etc/php-fpm.d/www.conf 中，需通过 volume 挂载自定义 conf.d 配置并重启容器验证。
trae 中 PHP 的 memory_limit 实际生效位置在哪
trae 是基于 Docker 的本地开发环境，PHP 配置不直接读取宿主机的 php.ini，而是由 traefik + PHP-FPM 容器联合控制。关键点在于：你改的配置必须落在 PHP-FPM 容器内生效的 php.ini 或 www.conf 中，而非 traefik 侧或宿主机任意位置。
常见误操作是编辑了项目根目录下的 .env 或 traefik 的 docker-compose.yml，但这些地方对 PHP 内存限制完全无效。
- PHP-FPM 容器中默认加载的主配置路径通常是
/usr/local/etc/php/php.ini - trae 的 PHP 服务名一般为
php或php-fpm（查看docker-compose.yml中 service 名） - 修改后必须重启该容器：
docker-compose restart php，仅 reload 不生效
如何在 trae 中安全调高 memory_limit
直接改容器内文件不可持续（重建镜像即丢失），正确做法是通过 trae 支持的配置挂载机制注入自定义 ini 片段。
在你的项目目录下创建 trae/php/conf.d/memory.ini（路径需与 traefik 的 volume 挂载一致），内容写成：
立即学习“PHP免费学习笔记（深入）”；
memory_limit = 512M
然后确认 docker-compose.yml 中 php 服务有类似这样的挂载：
volumes: - ./trae/php/conf.d/:/usr/local/etc/php/conf.d/
- 值建议用
M后缀（如512M），避免写-1（禁用限制）——某些扩展（如 xdebug）在-1下会崩溃 - 若同时启用了 OPcache，
memory_limit还要大于opcache.memory_consumption，否则 OPcache 初始化失败 - 改完务必执行
docker-compose exec php php -i | grep memory_limit验证是否真生效
为什么 ini_set('memory_limit', '512M') 在 trae 里常失效
这是运行时设置，受 PHP-FPM 的 php_admin_flag 和 php_admin_value 限制。trae 默认会在 www.conf 中锁定关键参数：
php_admin_value[memory_limit] = 256M
一旦用了 php_admin_value，任何脚本里的 ini_set() 或 .htaccess 都会被忽略。
- 不要试图在代码里覆盖，优先改容器配置
- 若必须动态调整，需先注释掉
www.conf中对应行（通过挂载覆盖该文件） -
phpinfo()页面里看 “Master Value” 和 “Local Value” 是否一致，不一致说明被 admin 设置覆盖了
trae 环境下内存不足的典型错误信号
不是所有 OOM 都报 Allowed memory size exhausted，trae 因容器资源隔离，更常出现的是静默失败或代理超时：
- 浏览器返回
502 Bad Gateway，而docker-compose logs php显示 worker process exited - PHP-FPM 日志里出现
[ERROR] unable to allocate shared memory segment - 执行
docker stats发现php容器内存使用长期 >90%，且 RSS 持续上涨 - 开启 xdebug 时，哪怕设了
512M仍报错——xdebug 3.x 默认额外吃 200MB+，需同步调高
trae 的 PHP 容器默认内存限制较保守，实际业务中常需配合 docker-compose.yml 给 php 服务加 mem_limit（如 512m），否则即使 php.ini 设再大也会被 cgroup 截断。
