方法重写只认签名一致性，不检查参数微调；一旦参数类型、个数或顺序改变，即非重写而是新方法，导致父类调用仍执行旧逻辑，子类方法静默失效。
方法重写本身不检查参数微调——它只认签名是否一致。所谓“因参数微调导致逻辑失效”，本质是开发者误把方法重写当成参数适配机制，而忽略了重写必须严格保持方法签名（名称 + 参数类型与个数 + 返回类型）这一前提。一旦参数被“微调”（如增删参数、改类型、变顺序），就不再是重写，而是定义了新方法，父类调用点仍执行旧逻辑，子类新方法则可能完全未被触发，造成静默失效。
紧扣签名一致性：重写的唯一准入门槛
重写生效的前提是编译器/解释器能识别“这是同一个方法”。这依赖精确匹配：
- Java中必须满足：方法名相同、参数列表（类型+顺序+个数）完全一致、返回类型相同或协变；哪怕只把 int 改成 long，就是重载或新方法，不是重写
- MicroPython中虽无编译期校验，但运行时按MRO查找同名键；若子类方法参数不同，
obj.method(x)仍会沿MRO找到父类版本，子类“看似重写”的方法根本不会被调用 - 常见陷阱：为适配硬件加一个超时参数
read(timeout_ms=100)，却未在父类中声明该参数 → 子类方法不参与重写，父类无参read()照常执行，timeout被忽略
用抽象层隔离可变参数，而非在重写中硬塞
参数差异应由更高层结构承载，而非破坏重写契约：
- 在父类定义通用接口（如
read_register(addr)），子类严格重写它；将硬件特有参数（DMA通道、采样精度、中断优先级）移至构造函数或配置属性中 - 示例：ESP32_UART2子类在初始化时传入
tx_fifo_size=128，send()重写体内直接使用该属性，不改变方法签名 - 避免在重写方法中引入条件分支处理“是否有timeout参数”，那会混淆职责，也掩盖签名不一致问题
运行时主动验证重写是否真正生效
不能依赖IDE提示或主观判断，需实测确认调用链：
- 在子类重写方法第一行插入日志或断点：
print("[DEBUG] ESP32_UART2.send() called") - 通过父类引用调用：
uart: UARTDevice = ESP32_UART2(...); uart.send(b'hello')，观察是否打印——若没输出，说明重写失败，需检查签名或MRO - MicroPython中可检查
uart.send.__func__.__qualname__，确认其归属类是否为子类名
用类型注解+静态检查工具提前拦截签名漂移
人工核对易疏漏，工具可守住底线：
- Java项目启用
-Xlint:overrides编译选项，对非@Override标注但实际覆盖的方法发出警告，反向验证是否真被识别为重写 - Python/MicroPython项目配合
mypy，为父类方法添加完整类型注解（如def read_register(self, addr: int) -> bytes:），子类重写时注解不匹配会报错 - 关键驱动类可增加单元测试：反射获取子类方法的
__code__.co_argcount，比对是否等于父类对应方法的参数数量
