根本原因是代理类生成失败或配置未真正启用：缺少symfony/proxy-manager-bridge扩展、PHP ext-reflection未启用、服务设为shared: false，或调试时toString等方法触发提前加载。
延迟加载（lazy）没生效，服务还是启动就实例化了
根本原因通常是代理类生成失败或配置未真正启用。Symfony 的 lazy: true 依赖 symfony/proxy-manager-bridge 扩展和 PHP 的 ext-reflection，缺一不可。若项目里没装这个桥接包，即使写了 lazy: true，容器也会静默降级为普通服务。
检查方式：运行 php bin/console debug:container --show-private，找目标服务，看 “Lazy” 列是否为 “yes”。不是？那就得回退排查：
- 确认已执行
composer require symfony/proxy-manager-bridge - 确保服务定义中没有同时设置
shared: false—— 非共享服务无法被代理，lazy 自动失效 - 避免在构造函数里做重操作（如连接数据库、读大文件），因为代理对象首次调用任意 public 方法时仍会触发完整初始化
预加载翻译资源反而拖慢首请求
翻译预加载本身没错，但时机和范围不对就会适得其反。比如在 Kernel::boot() 里调用 $translator->addResource() 加载全部语言包，等于把所有 XLIFF 文件一次性解析进内存，而多数请求只用其中一种语言。
更合理的方式是按需+缓存：
- 只预加载默认语言（如
en）和当前请求语言（从Request::getPreferredLanguage()拿） - 用
translation.loader的缓存机制，而不是手动 addResource —— Symfony 默认已启用cache.translation，确保它指向 APCu 或 Redis - 禁用开发环境的冗余加载：在
config/packages/dev/translation.yaml中设enabled: false，避免调试时反复解析
容器 warmup 后仍出现编译耗时，说明缓存没命中
执行了 cache:warmup 却发现下次请求还是慢，大概率是容器缓存被绕过了。常见原因有：
-
APP_DEBUG=1没关 —— 调试模式下容器永不使用预编译缓存，强制动态构建 - 服务定义里用了闭包（
factory: ['App\Service\Foo', 'create']改成factory: [Foo::class, 'create']更安全）或运行时参数（如%env(APP_ENV)%在某些场景下会阻止缓存固化） - 修改了
services.yaml但没清缓存：warmup 不会自动检测变更，必须先cache:clear
验证缓存是否真生效：查看 var/cache/prod/srcApp_KernelProdContainer.php 是否存在且修改时间早于 warmup 命令执行时间。
延迟加载 + 预加载组合使用时的内存陷阱
这两个策略方向相反：lazy 减少启动内存，预加载增加初始内存换后续速度。混用时容易误判效果。比如给一个本该 lazy 的日志服务配上预加载，既浪费内存又失去 lazy 意义。
关键判断点：
- 高频、必用、轻量服务（如
router、request_stack）适合预热，不 lazy - 低频、重型、可选服务（如 PDF 生成器、邮件批量发送器）必须 lazy，禁止预加载
- 翻译、验证规则这类元数据服务，应走
cache.translation/cache.validator缓存，而非靠 lazy 或预加载硬扛
真正影响性能的，往往不是单个配置开关，而是它们之间的冲突与叠加效应。上线前务必用 XHProf 或 Blackfire 抓一次完整请求，看服务实例化发生在哪一毫秒、占多少内存——纸上谈兵不如真实火焰图。
