doctrine延迟加载需显式声明fetch="lazy"、避免提前触发集合加载、用repository精准查询条件数据，并可结合symfony服务懒加载优化性能。
Doctrine延迟加载不是“打开开关就生效”的功能，它依赖你对实体关系的声明方式、访问时机的控制，以及底层集合或代理对象的行为逻辑。用对了，能省下大量数据库查询和内存；用错了，可能根本没触发，或者反而多查几次。
关联映射里明确设为 LAZY
这是最基础也最关键的一步。在实体类的 OneToMany、ManyToOne 等注解中，必须显式指定 fetch="LAZY"（虽然 Doctrine 默认就是 LAZY，但显式写出更安全、可读性更强）：
@ORM\OneToMany(targetEntity="Template", mappedBy="client", fetch="LAZY")@ORM\ManyToOne(targetEntity="User", fetch="LAZY")
别写 fetch="EAGER"——它会强制连表查出所有关联数据，一碰主实体就全拉进来，完全违背延迟加载本意。
别提前调用 count() 或遍历空集合
很多人发现 $client->getTemplates()->count() 没查库，但 $client->getTemplates()->first() 却查了。这不是 bug，是设计：Doctrine 的 PersistentCollection 在未初始化时，count() 可能走 SQL COUNT 查询（取决于配置），而 first()、toArray()、getIterator() 这类操作才会真正触发完整数据加载。
- 如果只关心数量，用
count()是合理的，但它本身也可能触发一次轻量查询 - 如果后续还要遍历或取字段，不如直接让集合初始化一次，避免重复加载
- 不要在 Twig 模板里反复调用
collection|length多次，Twig 会缓存结果，但逻辑上仍是多次访问
用自定义 Repository 方法精准加载
延迟加载适合“按需”，但不适合“按条件筛选后加载”。比如你想查 Client 的“已发布模板”，不建议先获取整个 templates 集合再 PHP 层 array_filter——数据早进内存了，延迟失效。
- 在
TemplateRepository中写方法：findByClientAndStatus(Client $client, string $status) - 该方法内部用 DQL 或 QueryBuilder 直接加 WHERE 条件，只查你要的数据
- 这样既保持延迟语义（不查就不执行），又避免把无用数据载入 PHP 内存
Symfony 服务层配合懒加载容器
除了 ORM 层，Symfony 容器本身也支持服务级别的懒加载。对那些启动慢、使用频率低的服务（如邮件发送器、第三方 API 客户端），可在服务定义中标记 lazy: true：
- YAML 配置：
App\Service\PaymentService: lazy: true - 效果是：容器不会立即实例化它，直到第一次
$container->get(PaymentService::class)或注入到其他服务时才创建 - 注意：这和 Doctrine 延迟加载无关，但属于同一性能优化思路——用到再动
