tf.function的 **多态性（Polymorphism）**------简单说就是：**一个被tf.function` 包装后的 Function 对象，会根据不同的输入"签名"，自动创建并管理多个独立的计算图**，每个图只适配特定类型/形状的输入，既保证兼容性又不牺牲性能。
我们用"通俗比喻+代码拆解"的方式，把每个概念和底层逻辑讲透：
先搞懂3个核心概念（比喻铺垫）
把 tf.function 想象成一个"万能厨师"：
| 概念 | 通俗比喻（厨师场景） | 技术定义 |
|---|---|---|
| Function（包装后） | 万能厨师本人：能处理多种食材，会自动选对应菜谱 | tf.function 包装后得到的 Python 可调用对象，管理多个 ConcreteFunction |
| 输入签名（Signature） | 食材规格：比如"1个苹果（圆形、红色）""2个香蕉（长条形、黄色）" | 输入张量的「类型（dtype）、形状（shape）、数据类型（如张量/列表）」的组合 |
| ConcreteFunction | 厨师的"专属分身+对应菜谱"：每个分身只做一种食材的菜，菜谱（计算图）是为该食材优化的 | 封装了单个 tf.Graph 的对象，每个都绑定一个唯一的输入签名，是实际执行计算的载体 |
| tf.Graph | 菜谱：步骤固定，只适配特定食材（比如"苹果派菜谱"不能做香蕉派） | 之前讲的计算图（运算流程+优化后），只能适配一种输入签名 |
核心逻辑：万能厨师（Function）接到订单（调用）时，先看食材规格（输入签名）：
- 若之前处理过这种规格，直接叫对应分身（ConcreteFunction）按菜谱（tf.Graph）做菜；
- 若没处理过，就新训练一个分身（创建新的 ConcreteFunction+tf.Graph），再做菜。
结合代码，拆解多态性的底层流程
我们以示例代码为线索，一步步看 tf.function 是如何创建和管理多个图的：
示例代码核心（ReLU函数）
python
@tf.function
def my_relu(x):
return tf.maximum(0., x) # 简单ReLU：小于0的数变成0，大于0的保留第一步：第一次调用不同输入→创建新图（新ConcreteFunction）
代码中3次不同输入的调用，都会触发"新图创建"：
python
# 调用1：输入是「标量、float32、张量」（签名1）
print(my_relu(tf.constant(5.5))) # 输出：5.5
# 底层：无对应签名→创建新ConcreteFunction1 + 图1（适配标量float32张量）
# 调用2：输入是「列表[1,-1]」（签名2）
print(my_relu([1, -1])) # 输出：[1. 0.]
# 底层：签名和之前不同→创建新ConcreteFunction2 + 图2（适配长度为2的整数列表）
# 调用3：输入是「形状(2,)、float32、张量」（签名3）
print(my_relu(tf.constant([3., -3.]))) # 输出：[3. 0.]
# 底层：签名和前两个都不同→创建新ConcreteFunction3 + 图3（适配(2,)形状的float32张量）为什么这3次会创建新图？因为它们的「输入签名不同」：
- 签名1：
x = 标量张量（shape=()）、dtype=float32 - 签名2：
x = 列表[1,-1]（非张量） - 签名3：
x = 2维张量（shape=(2,)）、dtype=float32
每个签名对应的计算图都是独立优化的：比如图1针对"标量运算"优化，图3针对"(2,)形状张量"优化，执行效率更高。
第二步：重复调用相同签名→复用已有图（不新建）
当输入签名和之前一致时，Function 会直接复用已有的 ConcreteFunction 和图：
python
# 调用4：输入是「标量、float32、张量」（和签名1一致）
print(my_relu(tf.constant(-2.5))) # 输出：0.0
# 底层：匹配签名1→复用ConcreteFunction1 + 图1，不新建
# 调用5：输入是「形状(2,)、float32、张量」（和签名3一致）
print(my_relu(tf.constant([-1., 1.]))) # 输出：[0. 1.]
# 底层：匹配签名3→复用ConcreteFunction3 + 图3，不新建这就是"一次构建、多次复用"的延伸------不仅单个图能复用，多个图也能被 Function 智能管理。
第三步：查看所有ConcreteFunction→验证多图存在
代码最后打印了 my_relu.pretty_printed_concrete_signatures()，输出了3个签名，正好对应前面3次"新创建"的场景：
# 签名1：对应调用1、4（标量float32张量）
Input Parameters: x → TensorSpec(shape=(), dtype=tf.float32)
Output Type: TensorSpec(shape=(), dtype=tf.float32)
# 签名2：对应调用2（列表[1,-1]）
Input Parameters: x → List[Literal[1], Literal[-1]]
Output Type: TensorSpec(shape=(2,), dtype=tf.float32)
# 签名3：对应调用3、5（(2,)形状float32张量）
Input Parameters: x → TensorSpec(shape=(2,), dtype=tf.float32)
Output Type: TensorSpec(shape=(2,), dtype=tf.float32)这证明：my_relu 这个 Function 底层管理了3个 ConcreteFunction，每个都绑定一个唯一签名和对应的计算图------这就是"一个Function，多个计算图"的本质。
为什么需要多态性？（核心价值）
如果 tf.function 只创建一个图，会有两个问题：
- 兼容性差：一个为"标量张量"优化的图，无法处理"列表"或"不同形状的张量"（比如标量图的运算逻辑和2维张量的运算逻辑不同）；
- 性能损失：如果强行用一个图适配所有输入，就无法针对特定输入做优化（比如列表需要先转张量，而专用图会提前优化这个转换步骤）。
多态性的解决方案：
- 对用户：不用关心输入类型/形状，像调用普通Python函数一样使用；
- 对底层：为每种输入签名创建专用图，既保证兼容性，又保留计算图的优化优势（提速、硬件适配）。
总结：这段内容到底在讲什么？
核心是解释 tf.function 的一个关键特性------多态性：
- 被
tf.function包装后的 Function 不是绑定一个图，而是一个"图管理器"； - 每次调用时，先判断输入的"签名"（类型、形状、数据类型）；
- 若签名已存在，复用对应的 ConcreteFunction（封装了专用图）；
- 若签名不存在，新建 ConcreteFunction 和专用图；
- 最终实现"一套代码，适配多种输入，且每种输入都有最优执行效率"。
简单说：tf.function 既想让你享受计算图的速度，又不想让你像TensorFlow 1.x那样手动管理图和占位符，多态性就是实现这个目标的核心机制。