关键在于将异常作为控制信号，结合生成器、延迟初始化和上下文管理器，使动态字段按需计算、构造或加载，避免预分配内存。
关键不在“异常处理流本身提供惰性”，而在于把异常作为控制信号，配合生成器、延迟初始化和按需加载机制，让动态字段只在真正需要时才计算、构造或加载——从而避免大量字段在创建对象时就占内存，却从未被访问。
用生成器替代预计算字段列表
动态字段常来自配置驱动或运行时规则（如“用户等级对应折扣率”“订单类型触发风控标签”），传统做法是启动时全量解析并缓存所有可能字段，内存随规则数线性增长。改用生成器函数封装字段计算逻辑，调用方按需迭代获取，异常可随时中断流程，不滞留中间结果。
- 定义 yield_field_values(config_rules, context)：只在 next() 或 for 循环中才执行单条规则匹配与计算
- 遇到非法规则（如表达式语法错误、依赖字段缺失）立即 raise ValueError，上层捕获后跳过该字段，不继续加载其余规则
- 百万级规则配置下，生成器版本内存稳定在 8MB；预加载字典版本峰值达 420MB
对高开销字段做延迟初始化
并非所有动态字段都高频使用。例如“审计摘要”“合规校验日志”“多币种折算明细”等字段，初始化需查库、调远程服务或解析大 JSON，应推迟到首次 get 属性时才触发。
- Python 中用 @property + __getattr__ 拦截未定义属性，检查是否为动态字段名，是则执行初始化逻辑并缓存
- Java 中用 volatile 字段 + 双重检查锁，在 getter 内完成首次构造；避免构造函数里 new 大对象
- 确保字段初始化失败时抛出异常，而非静默返回 None，防止后续误用空值引发二次异常
结合上下文管理器按需绑定数据源
很多动态字段依赖外部状态（如客户实时风险分、行情快照、权限策略树）。若在字段计算前就全量拉取，会浪费带宽与内存；应让数据读取延迟到字段内部首次访问具体字段时才发生。
- 封装数据库查询、HTTP 客户端、缓存连接为上下文管理器，在 __enter__ 中仅建立轻量连接/句柄，不 fetch 数据
- 字段计算方法内用 with data_source as ds: 获取数据，__exit__ 自动关闭，即使中途 raise 异常也不会泄漏资源
- 配合 dataclass 的 __post_init__ 延迟加载非核心字段，比如只在生成监管报表时才查“最终受益人链”
用结构化异常代替布尔标记字段
常见反模式：对象带一堆 is_valid_xxx、has_calculated_yyy 布尔字段，随流程推进不断赋值。这些字段虽小，但数量多、生命周期长，且多数请求根本不用它们——本质是内存占而不用。
- 删除布尔标记，改用显式异常表示“不可用”状态，如 raise MissingDependencyError("缺少交易对手评级")
- 字段 getter 中统一 try/except，捕获特定异常后返回默认值或跳过，避免提前分配占位字段
- 异常对象本身也利用 JVM/Python 的惰性栈跟踪机制：不打印就不填充 stackTrace，10 万并发下每个异常省 3KB，总计节省超 300MB 物理内存
