关键在于命名即线索，子类名须体现业务语义与继承关系，采用“功能+角色+类型”结构并保留父类关键词，包结构与类名严格对齐，辅以运行时追溯和构建期自动校验。
关键不是“查得快”，而是让名字本身就能告诉你它是什么、属于哪一层、从哪来——命名即线索，不靠猜、不翻源码、不碰运气。
子类名必须带业务语义和继承痕迹
别用 PaymentHandler、OrderProcessorImpl 这类模糊词。每个子类名要一眼看出“干啥的”+“谁的”+“什么类型”：
- ✅ 支付场景：AlipayPaymentProcessor、WechatRefundStrategy
- ✅ 状态处理：ShippedOrderStateValidator、PendingInvoiceStatusUpdater
- ❌ 避免：Handler、Impl、V2、Base 单独出现；更忌用 PaymentXXX、OrderXXX 这种泛前缀
- 所有子类名结尾保留父类关键词（如 Processor、Strategy、Validator），方便 IDE 全局搜 xxxProcessor
包结构和类名必须严格对齐
Java 的包路径不是装饰，是逻辑归属的强制声明：
- 所有 PaymentProcessor 实现类，统一放在 com.example.payment.processor 下，不许散落在 impl、v2、core 里
- 版本演进靠包名区分：processor.v1 和 processor.v2，而不是类名加 V1 后缀
- 禁止混放：UserValidator 和 OrderValidator 不能同在 validator 包下，除非它们真继承自同一抽象基类
运行时主动暴露真实类型
调试时别只看变量声明类型，要让它“自报家门”：
- 关键日志点打印 obj.getClass().getName()，而不是 obj.toString()
- 在抽象父类加标准方法 getImplementationKey()（如返回 "alipay-v3"），便于监控归类
- IDE 快捷键直接跳转：IntelliJ 用 Ctrl+Alt+B，Eclipse 用 F4，点一下就到真实子类
构建期自动拦截不合规命名
靠人守规矩容易漏，用工具卡住入口：
- Maven 项目接入 maven-enforcer-plugin，校验子类是否全在约定包路径下
- 写个简单单元测试：反射扫描指定包，断言类名符合正则（如 ^[A-Z][a-zA-Z0-9]*Processor$）
- CI 流程中跑 jdeps 或 javap -s，识别意外引入的非标实现
