鸭子类型是一种设计哲学而非语法机制，核心在于关注对象行为而非类型，只要具备所需方法或属性即可使用，支持运行时协议验证与隐式接口表达。
Python 中的鸭子类型（Duck Typing）不是一种语法机制，而是一种设计哲学：只要对象“走起来像鸭子、叫起来像鸭子”，它就是鸭子——换句话说，不看类型，只看行为。它让协议编程更灵活、更轻量，也是 Python “接口隐式化”的核心体现。
鸭子类型到底在“型”什么？
它不关心对象属于哪个类，只关心它有没有你需要的方法或属性。比如你写一个函数要调用 .read() 和 .close()，那任何实现了这两个方法的对象（文件、StringIO、自定义网络流）都能传进来——无需继承某个基类，也不用实现某个 interface。
- 类型检查发生在运行时，而非定义时
- 没有显式的接口声明，协议靠文档或约定隐含表达
- 错误通常在调用缺失方法时才抛出（AttributeError），而不是提前拒绝
协议编程：用结构代替继承
协议（Protocol）是鸭子类型的规范化表达。从 Python 3.8 开始，typing.Protocol 允许你明确定义一组需要的方法和属性，作为“结构类型”的契约：
from typing import Protocol class Readable(Protocol): def read(self) -> str: ... def close(self) -> None: ... def process_stream(stream: Readable) -> str: data = stream.read() stream.close() return data这个
process_stream函数接受任何满足Readable协议的对象——静态类型检查器（如 mypy）能据此验证，但运行时仍完全依赖鸭子类型，不强制继承或注册。立即学习“Python免费学习笔记（深入）”；
常见协议与实际用途
Python 标准库和第三方包大量使用协议思想，很多内置操作其实都在“按协议工作”：
__len__→ 支持len(obj)__iter__或__getitem__→ 支持for x in obj:__add__→ 支持a + b__str__→ 支持str(obj)你不需要让类继承
collections.abc.Iterable，只要实现了__iter__，它就“是”可迭代对象。这就是协议在底层默默起作用。什么时候该用 Protocol？什么时候保持朴素鸭子类型？
小脚本或快速原型中，直接依赖鸭子类型足够简洁；但在中大型项目里，显式 Protocol 能提升可读性、支持静态检查、辅助 IDE 补全，并让协作更清晰：
- 当多个类需满足同一组行为，且这些行为跨模块复用时，定义 Protocol
- 当想让类型提示既准确又不引入强继承耦合时，用 Protocol 替代 ABC
- 避免为每个小操作都定义 Protocol——过度设计反而掩盖意图
