方法重写只认签名一致性，不检查参数微调；一旦参数类型、个数或顺序改变，即非重写而是新方法，导致父类调用仍执行旧逻辑，子类方法静默失效。

方法重写本身不检查参数微调——它只认签名是否一致。所谓“因参数微调导致逻辑失效”，本质是开发者误把方法重写当成参数适配机制，而忽略了重写必须严格保持方法签名（名称 + 参数类型与个数 + 返回类型）这一前提。一旦参数被“微调”（如增删参数、改类型、变顺序），就不再是重写，而是定义了新方法，父类调用点仍执行旧逻辑，子类新方法则可能完全未被触发，造成静默失效。

紧扣签名一致性：重写的唯一准入门槛

重写生效的前提是编译器/解释器能识别“这是同一个方法”。这依赖精确匹配：

• 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，比对是否等于父类对应方法的参数数量