面向对象处理未核销坏账的核心是建模BadDebtEntity类封装识别与判断逻辑，结合WriteOffRuleStrategy策略解耦规则，报表层对象级过滤并记录日志，辅以BadDebtStateTracker保障状态一致性。
用面向对象思想跳过未核销坏账，关键不是“绕开数据”，而是把坏账识别、状态判断、过滤行为封装成可复用、可测试、可追溯的对象职责，让报表逻辑更清晰、更易维护。
把坏账定义为一个有行为的实体类
别再用零散字段拼条件（比如 if overdue_days > 360 and write_off_flag == 'N'）。应建模为 BadDebtEntity 类，自带业务语义和判断能力：
- 构造时传入原始应收明细行，自动解析账龄、核销标记、客户信用等级等关键属性
- 提供 isEligibleForWriteOff() 方法——返回 true 表示“当前符合核销条件”，false 才是“未核销且暂不参与报表汇总”
- 内置规则版本号（如 rule_v2.1），便于后续审计或回滚比对
用策略模式解耦不同核销判定逻辑
不同业务线（如电商应收、工程应收款）对“未核销”的定义可能不同。硬编码会导致报表模块越来越臃肿。引入 WriteOffRuleStrategy 接口：
- 实现类如 StandardARRule（按账龄+凭证状态）、BankruptcyARRule（强关联破产标识）
- 报表服务启动时根据账套配置动态注入对应策略，无需改代码即可切换规则
- 每个策略的 shouldSkipInReport() 方法返回布尔值，主循环直接调用，干净利落
在报表聚合层做“对象级过滤”，而非SQL级剔除
避免在数据库查询里写复杂 WHERE 条件，尤其当报表需支持多维钻取（如按客户、产品、期间下钻）时。正确做法是：
- 先查出全量应收明细（含已核销/未核销），转为 BadDebtEntity 列表
- 遍历列表，调用 entity.shouldBeExcludedFromFinancialReport()
- 仅将返回 false 的实体送入后续汇总引擎（如按客户求和、按期间分组）
- 被跳过的实体记录日志：ID、跳过原因、规则版本，供财务复核
配合状态管理器实现跨请求一致性
一笔坏账可能在报表生成中途被人工核销。为避免“边生成边失效”，需轻量状态协同：
- 引入 BadDebtStateTracker 单例，缓存最近1小时被判定为“未核销”的凭证ID及其快照时间
- 报表拉取数据前，先校验这些ID是否已在核心表中更新了 write_off_date；若已更新，则自动刷新该实体状态
- 确保同一份报表内，所有维度统计基于同一时刻的状态快照，不出现“有的行算、有的行不算”的矛盾
