多态旨在消除重复的isinstance类型判断，通过统一方法名（如speak()）实现运行时动态分发；鸭子类型无需继承，只要具备对应方法即可；应避免在业务逻辑中做类型检查，而用Protocol或抽象基类在入口约束。
多态不是为了炫技，而是当你发现代码里反复出现 if isinstance(obj, Cat)、elif isinstance(obj, Dog) 这类判断时，它就能直接帮你删掉这些分支。
用多态替代 type-checking 分支
硬编码类型判断不仅难维护，还会在新增类时被迫修改原有函数。多态把“是什么类型”交给运行时决定，你只管调用方法名。
- 常见错误现象：写一个
process_animal()函数，里面堆满if/elif/else判断对象类型，再分别调用不同逻辑 - 正确做法：让所有动物类都实现同名方法（如
speak()），函数只写animal.speak() - 鸭子类型允许连继承都不需要——只要对象有
speak()方法，就能传进去 - 如果后续加了
Parrot类，只需定义自己的speak()，不用动任何已有函数
为什么 isinstance() 不是首选
它把类型检查提前到调用前，破坏了扩展性，也违背 Python 的“请求原谅而非许可”（EAFP）原则。
-
isinstance(obj, Animal)强制要求继承关系，但现实中很多类天然无关（比如Robot也能speak()） - 一旦用
isinstance，你就得同步维护类型列表和分支逻辑，容易漏改 - 性能上无优势：动态分发的开销远小于反复做类型检查 + 分支跳转
- 真正需要类型校验时，应放在初始化或输入入口（如用
typing.Protocol或抽象基类约束），而不是业务逻辑中
带参数的多态函数怎么写才安全
统一接口不等于忽略差异；关键是在方法内部处理各自逻辑，而不是在调用侧做适配。
立即学习“Python免费学习笔记（深入）”；
- 避免函数里写
if hasattr(obj, 'volume')再分支——这仍是伪多态 - 推荐模式：每个类的
play()方法自己解析参数，比如Dog.play(self, loud=True)和Flute.play(self, tempo='allegro') - 若参数差异过大，说明接口设计过宽，应拆成更专注的方法（如
play_sound()vsplay_melody()） - 可以配合
**kwargs接收可选参数，但类内必须做明确的默认值或缺失处理，不能靠调用方记住传什么
最容易被忽略的一点：多态的有效性完全依赖于开发者自觉遵守“同名同职责”契约。没有编译器强制，也没有运行时报错提醒——一旦某个类的 draw() 实际做了保存文件操作，整个多态链条就悄然崩坏。
