工厂方法模式定义创建对象的接口，由子类决定实例化哪个类，将实例化延迟到子类；它仅负责对象构建，不执行业务计算，核心价值在于解耦与扩展。
工厂方法本身不触发计算，它只负责返回一个对象实例；真正的计算发生在你调用该对象的某个方法时。所谓“调用时才真正触发内部计算”，不是工厂方法的特性，而是对象行为设计的结果——关键在对象是否做了延迟计算（lazy evaluation）、状态是否封装得当、逻辑是否被推到了行为方法里。
工厂方法只是对象的“快递员”，不干计算的活
工厂方法的核心职责是解耦创建逻辑：你告诉它要什么类型，它返回对应的具体对象。这个过程通常只涉及 new、参数校验、简单组装，几乎没有业务计算。比如：
- 不耗时：new ConcreteOrderService() 只是分配内存、调用构造器，没查库、没校验规则、没生成单号；
- 不决策：它不判断“这笔订单能不能支付”，那是 Order.pay() 方法该干的事；
- 不延迟：工厂本身不会把计算“藏起来等你调用才算”，除非你刻意在构造器里写延迟加载，但这已超出工厂方法本意。
真正“调用时才算”的源头在对象内部设计
性能真相藏在被创建出来的对象里。如果这个对象把计算逻辑封在 public 方法中，并且不做预加载，那确实会“第一次调用才执行”：
宝塔Linux面板11.3.0
下载
宝塔面板11.3.0是一款针对Linux服务器设计的可视化管理工具，通过重构核心模块实现资源占用显著降低，尤其适合低配置服务器环境。它将复杂的命令行操作转化为直观的图形界面，帮助开发者快速完成网站部署、环境配置及日常运维工作，无需专业技术背景即可高效管理服务器。
- 订单对象的 calculateTotal() 方法里才去遍历商品、查优惠券、累加税费；
- 报表服务的 exportExcel() 方法里才拉取数据库、组装数据、生成流；
- 这些方法没被调用前，对象只是个空壳，连数据库连接都可能没建。
怎么验证是不是真延迟？看三处代码
别猜，直接翻被工厂返回的对象源码：
- 构造器里有没有 heavy logic？如果有 new HttpClient()、loadConfigFromDB()、initCache()，那就不是“调用时才算”，而是“一造就卡”；
- 关键方法有没有 @PostConstruct 或 static 块提前执行？有就说明计算被提前了；
- 方法体内是否包含 I/O、循环、复杂条件分支？这才是真实耗时点，和工厂完全无关。
优化方向不在工厂，而在对象职责划分
如果你发现“一调用就慢”，问题不在工厂方法，而在于对象把太多事堆在一个方法里。改进方式是：
- 把可缓存的中间结果做成 private final 字段，在构造时或首次访问时计算并缓存；
- 把大计算拆成小步骤，暴露 checkEligible()、estimateCost() 等轻量接口，让用户按需调用；
- 用 Supplier 或 CompletableFuture 封装延迟动作，明确标出“此处将触发实际计算”。
