为何Moose框架中的lazy_build特性被强烈不推荐使用？

虽然官方文档未明确说明原因，但Moose社区经过实践积累，普遍认为该特性的问题集中在以下几点：

• 隐式逻辑大幅提升调试难度：lazy_build会自动触发一系列隐式行为——不仅启用lazy => 1，还会绑定_build_*构建方法的调用逻辑，同时默认生成clearer => '_clear_*'和predicate => 'has_*'方法。这些隐藏的规则在简单场景下看似省事，但在复杂类继承或依赖结构中，一旦出现属性加载异常、方法被意外调用的情况，开发者很难快速定位问题根源，因为关键逻辑并未显式写在代码里。

• 违背显式编程的核心原则：Moose的设计初衷是让代码意图清晰可见，但lazy_build用单个参数打包了多个独立配置。比如你仅需要属性懒加载，却被迫同时拥有清除器和断言方法，既造成了不必要的方法冗余，还让其他阅读代码的开发者必须额外记住lazy_build的所有隐式规则，提升了代码的认知门槛。

• 灵活性严重受限：当需要自定义懒加载相关行为时，lazy_build的默认配置会成为阻碍。比如你不想生成清除器方法，或者想给断言方法起个贴合业务的名字，lazy_build没有提供单独调整这些选项的空间，只能放弃该特性，转而手动配置lazy、builder、clearer等参数，反而增加了重构成本。

• 长期维护存在隐患：早期将其列为最佳实践是因为能减少重复代码，但随着社区实践深入，大家发现这种“一键式”特性带来的隐式问题，远大于它节省的代码量。现在Moose更推荐显式组合lazy、builder以及按需添加clearer/predicate的方式，既能实现相同功能，又能让代码逻辑一目了然，更利于项目的长期维护和演进。

内容的提问来源于stack exchange，提问作者Wouter Verhelst