必须显式配置 lazy: true 并安装 symfony/proxy-manager-bridge，否则重服务仍于容器初始化时构造；在 services.yaml 中需为具体实现类（非接口别名）声明 lazy: true，且依赖链中任一非 lazy 服务都会导致提前实例化。
必须显式配置 lazy: true，且安装 symfony/proxy-manager-bridge，否则服务仍会在容器初始化时被构造。
services.yaml 里怎么写 lazy 配置
懒加载不是默认行为，哪怕服务类本身很重，不加配置就等于没开。在 config/services.yaml 中为具体服务类添加 lazy: true：
services:
App\Service\HeavyProcessor:
class: App\Service\HeavyProcessor
lazy: true
如果用了接口绑定（比如 MailerInterface → SmtpMailer），lazy 必须加在实现类上，而不是接口别名上：
services:
App\Service\MailerInterface: '@App\Service\SmtpMailer'
App\Service\SmtpMailer:
class: App\Service\SmtpMailer
lazy: true
- 只写
autowire: true或autoconfigure: true不会触发懒加载 - 用
bind:绑定构造参数也不影响 lazy 行为，但若绑定的对象本身非 lazy，可能间接导致提前实例化 - 配置生效后，
bin/console debug:container --show-private | grep HeavyProcessor输出中应含lazy字样，且 class 显示为类似App\Service\HeavyProcessor\Proxy
为什么装了 lazy: true 还是立即初始化了
常见原因不是配置错，而是依赖链“拉爆”了懒加载：
- 该服务被另一个非 lazy服务的构造函数直接注入 —— 容器为满足依赖，必须立刻 new 出来
- 服务定义里用了
factory:或arguments:引用了@doctrine.orm.entity_manager、@cache.app等常驻服务，而这些服务本身无法 lazy，导致整个链路失效 - 代码里写了
$container->get('app.heavy_processor')—— 这会绕过代理，强制初始化；应改为依赖注入，或使用ServiceLocator+ 类型提示 - 在
Kernel::build()或Extension::load()中主动调用了$container->get()，属于编译期误触
proxy-manager-bridge 是不是可选的
不是可选，是必需的。Symfony 4+ 的 lazy 机制底层靠 ProxyManager 生成代理类，没有它，lazy: true 会被静默忽略（容器编译不报错，但实际不生效）。
执行以下命令安装并启用：
composer require symfony/proxy-manager-bridge
安装后检查：var/cache/dev/Container*/ 下是否有以 Proxy.php 结尾的文件；没有则说明桥接未生效，常见原因是 Composer 自动加载未刷新（可试 composer dump-autoload）。
注意：Symfony 7 默认已内置该桥接，但若项目从旧版本升级，仍需确认是否残留手动移除操作。
怎么验证懒加载真的起了作用
最可靠的方式是看构造函数是否延迟执行：
- 在服务类的
__construct()里加file_put_contents('/tmp/lazy.log', "init\n", FILE_APPEND) - 发起一个完全不涉及该服务的请求（如访问
/health路由），观察日志是否写入 —— 若写了，说明没 lazy - 再发起真正调用该服务的请求（如调用其某个方法），此时才应写入日志
另一个信号是容器编译后的代理类路径：如果看到 App\Service\HeavyProcessor\Proxy，说明代理已生成；如果还是原类名，要么没装 bridge，要么配置没落到正确服务 ID 上（比如写成了别名而非类名）。
容易被忽略的一点：即使所有配置都对，只要服务被任何非 lazy 服务的属性或构造函数引用，它就一定会提前加载 —— 懒加载不是“全局开关”，而是“按依赖链逐级生效”的机制。
