抽象方法通过强制子类实现校验契约构建“契约式防线”，在编译期或运行初期暴露非法替换；结合构造器中调用、异常中断、final不可变设计及混淆/jni/签名等工程化手段形成纵深防护。
抽象方法本身不直接防范篡改，但它能构建一道“契约式防线”：强制所有具体数据源实现统一的校验入口，让非法替换或绕过校验的行为在编译期或运行初期就暴露出来。
用抽象方法定义校验契约
在基类中声明抽象校验方法，不提供实现，只规定子类必须提供自己的校验逻辑：
- 例如定义 abstract boolean validateDataSource(); —— 所有继承该基类的数据源（如 DatabaseSource、FileSource、RemoteApiSource）都必须重写它
- 这样即使攻击者替换了某个具体实现类，只要没实现该方法，JVM 就拒绝加载或实例化，直接报 java.lang.InstantiationError 或 AbstractMethodError
- 相比硬编码校验逻辑，抽象方法把“是否校验”和“由谁校验”解耦，校验细节下沉到子类，更易适配不同数据源特性（如数据库连接串签名、文件哈希比对、API 响应头验签）
结合初始化时机增强防护效果
校验不能只靠方法存在，还要确保它被真正执行：
- 在基类构造器末尾或静态块中调用 this.validateDataSource() —— 这样只要子类被 new 出来或首次访问，校验就自动触发
- 若校验失败（如签名不匹配、证书过期、响应不可信），直接抛出 unchecked exception（如 SecurityException），中断对象创建流程
- 避免放在懒加载方法里——攻击者可能跳过调用，导致校验形同虚设
配合 final + 不可变设计封堵运行时篡改
光有校验还不够，要防止校验通过后关键字段被反射修改：
- 将数据源地址、密钥、开关标志等声明为 public static final，并在抽象方法校验通过后才赋值（利用静态块或构造器条件赋值）
- 敏感字符串做运行时解密，密钥由校验结果派生（如用合法签名 SHA-256 的前8位生成 AES 密钥），避免明文硬编码
- 对关键 setter 方法加 @Deprecated 或直接删掉，只保留只读 getter，切断外部修改通道
与工程化手段协同落地
抽象方法是设计骨架，实战中需搭配其他技术才能形成有效防护：
- 混淆类名/方法名（ProGuard/R8），让反编译后难以识别校验入口
- 核心校验逻辑下沉到 JNI 层，Java 层只留抽象方法调用和异常兜底
- 对数据源配置做数字签名或 HMAC 校验，签名密钥存于安全模块（如 Android Keystore、iOS Secure Enclave）
