直接原因是PHP默认内存限制过低，应优先用php -d memory_limit=1G等运行时覆盖方式，避免改php.ini或bin/console硬编码；禁用调试、分页处理、检查APCu干扰及代码冗余操作。
symfony console 命令报 Allowed memory size exhausted
直接原因是 PHP 默认内存限制太低，而 Symfony 控制台命令（尤其是处理大量数据、加载完整容器或执行数据库迁移/缓存清理时）容易突破 128M 或 256M 的默认上限。
别改 php.ini 全局配置——你很可能没权限，而且会影响其他项目。优先用运行时覆盖方式：
- 在命令前加
php -d memory_limit=1G：例如php -d memory_limit=1G bin/console doctrine:migrations:migrate - 如果用的是 Docker，进容器后执行命令前设环境变量：
PHP_MEMORY_LIMIT=1G php bin/console ...（前提是入口脚本支持该变量） - Windows PowerShell 用户注意：不能用单引号包裹参数，要写成
php -d "memory_limit=1G" bin/console ...
bin/console 脚本里硬编码了 memory_limit 吗？
Symfony 5.4+ 的 bin/console 默认不设内存限制，但有些团队会手动加 ini_set('memory_limit', '512M'); —— 这种写法危险：它在 CLI 模式下可能被后续 ini_set 覆盖，或与 -d 参数冲突，导致实际生效值不可预期。
检查 bin/console 开头几行，删掉任何类似 ini_set('memory_limit', ...) 的代码。运行时控制比脚本内硬编码更可靠。
立即学习“PHP免费学习笔记（深入）”；
为什么 php -d memory_limit=-1 不推荐？
-1 表示无限制，看似一劳永逸，但实际会掩盖内存泄漏问题。比如某个命令本该用 256M，结果因对象未释放一路涨到 4G 才崩，你根本发现不了瓶颈在哪。
- 先用
--no-debug关闭调试模式（bin/console cache:clear --no-debug），能省掉一半内存 - 对 Doctrine 相关命令，加
--env=prod避免开发环境的额外监听器和日志收集 - 批量操作时，用
chunkSize分页（如doctrine:fixtures:load --group=large --batch-size=100）
内存够了还是崩？可能是 APCu 或 OPcache 缓存干扰
某些生产环境启用了 apcu.enable_cli=1，而 APCu 在 CLI 下未清理旧缓存，会导致内存碎片化严重，memory_limit 没超但分配失败。
临时验证方法：加 -d apc.enable_cli=0 再跑命令，例如 php -d memory_limit=1G -d apc.enable_cli=0 bin/console ...。如果不再溢出，说明是 APCu 的 CLI 缓存机制问题，需调整 apc.shm_size 或禁用 CLI 下的 APCu。
真正难搞的不是调数字，而是命令本身是否做了不必要的全量实体加载、是否在循环里反复 new 容器服务、是否用了 var_dump() 或 dump() —— 这些比内存参数更值得先盯住。
