引入懒加载模式

懒加载的本质

懒加载是一个时机问题。

对象何时创建？数据何时加载？资源何时分配？

传统做法是：提前准备好一切。应用启动时，初始化所有依赖。页面加载时，获取所有数据。构造函数执行时，创建所有对象。

懒加载反其道而行之——推迟到真正需要的那一刻。

延迟不是逃避，而是精确控制。你决定何时付出成本，而不是让系统替你决定。

为什么延迟初始化

提前初始化的问题在于：你为可能不会发生的事情付费。

应用启动时加载所有模块，但用户可能只使用其中 20%。页面渲染时获取所有数据，但大部分内容在首屏之外。构造对象时创建所有依赖，但某些依赖可能永远不会被调用。

资源不是免费的。 内存有限、CPU 时间有限、网络带宽有限。提前分配就是提前占用，占用就是浪费。

懒加载把成本分摊到真正需要的时刻。首次加载更快，内存占用更少，启动时间更短。

但这不是银弹。延迟创建意味着第一次调用会变慢。缓存逻辑增加了复杂度。线程安全需要额外处理。

懒加载的代价

延迟初始化带来三个成本：

复杂度成本。你需要检查资源是否已创建，需要缓存实例，需要处理并发情况。简单的 new Object() 变成了条件判断和状态管理。

首次调用成本。第一次访问时，用户会等待资源初始化。如果初始化很慢（比如连接数据库、加载大文件），这个延迟会很明显。

调试成本。错误不再发生在启动时，而是发生在运行时的某个随机时刻。初始化失败不会立即暴露，而是潜伏到第一次使用。

这些成本是真实的。但它们值得付出，如果初始化成本高，且使用频率低。

关键在于权衡：提前初始化的确定性成本，对比懒加载的条件性成本。

何时使用懒加载

懒加载适用于以下场景：

昂贵资源的延迟加载。数据库连接、大型配置文件、外部 API 客户端。这些资源初始化慢，但不是每次请求都需要。

条件性功能的延迟初始化。用户可能启用的功能、可选的插件、A/B 测试的变体。这些功能可能永远不会被使用。

分步加载的优化。首屏内容优先加载，其他内容按需加载。视口内的图片先加载,视口外的延迟加载。

并发控制的资源池。连接池、线程池、对象池。资源按需创建，达到上限时复用。

控制权的转移

懒加载改变的不只是时机，还有控制权。

提前初始化时，系统决定何时创建资源。懒加载时，调用方决定何时触发创建。

这个区别很微妙，但很重要。它意味着你可以测试、可以替换、可以控制。参考 依赖注入 中讨论的控制权转移原则。

懒加载让时机变得可控。你不再被动接受系统的默认行为，而是主动选择最优时刻。

这需要更多思考。你需要理解资源的使用模式，权衡提前和延迟的成本，设计合理的缓存策略。参考 编码前的思考 中的框架来分析这些问题。

但一旦建立了这种思维方式，你会发现：很多性能问题的根源，就是时机选择不当。

最后

懒加载不是技巧，是原则。

它教会你一件事：不是所有事情都需要立即完成。

资源可以延迟加载，对象可以延迟创建，决策可以延迟做出。延迟不是拖延，而是等待更多信息、更好时机。

系统设计的本质，就是在时间轴上分配成本。提前付出还是延迟付出，急切加载还是按需加载，这些选择定义了系统的效率和复杂度。

懒加载是众多选择中的一个。理解它，就理解了时机的价值。