根本原因是TensorFlow版本不一致或自定义对象未正确注册：跨大版本时算子被移除或重命名；使用自定义层、@tf.function函数、非标准激活函数时未传custom_objects；SavedModel加载应优先用tf.saved_model.load()而非load_model()。
为什么 tf.keras.models.load_model() 会报 “Op type not registered”？
根本原因是模型保存时用的 TensorFlow 版本，和加载时的版本不一致，尤其是跨大版本（如 2.8 → 2.12 或 2.15 → 2.16）时，部分算子被移除、重命名或行为变更。典型错误信息长这样：Op type not registered 'StatefulPartitionedCall' 或 'ResourceScatterAdd' —— 这些不是你代码写错了，而是运行时找不到对应 C++ 算子实现。
更隐蔽的情况是：模型里用了自定义层或 tf.function 装饰的函数，但加载时没正确传入 custom_objects，也会退化成算子注册失败的报错。
- 检查当前环境 TF 版本：
import tensorflow as tf; print(tf.__version__) - 确认模型原始训练/保存环境的 TF 版本（最好翻记录或
pip list快照） - 若版本差 ≥1 个小版本（如 2.11 vs 2.13），优先考虑降级加载环境，而非硬改模型
用 tf.keras.models.load_model() 加载前必须传 custom_objects 的三种情况
只要模型里出现以下任一成分，不传 custom_objects 就大概率触发算子错误或 NameError：
- 继承
tf.keras.layers.Layer的自定义类（哪怕只重写了call()） - 用
@tf.function包裹并作为层逻辑调用的函数（例如在call()中调用了带@tf.function的辅助函数） - 使用了非标准激活函数（如
tf.keras.activations.swish在旧版 TF 中未注册为字符串别名）
正确做法是显式映射名称到类/函数：
model = tf.keras.models.load_model(
"my_model.h5",
custom_objects={
"MyCustomLayer": MyCustomLayer,
"swish": tf.keras.activations.swish
}
)
注意：custom_objects 键名必须和模型保存时序列化用的字符串完全一致（可通过打开 .h5 文件用 h5py 查 model_config 验证）。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
从 SavedModel 格式加载时，tf.saved_model.load() 和 load_model() 的关键区别
tf.saved_model.load() 不走 Keras 模型重建流程，而是直接恢复计算图和变量，因此它对算子兼容性更敏感，但对自定义对象反而“不挑”——因为它不尝试反序列化 Python 类结构，只加载底层 op 和权重。
- 如果模型是用
model.save("path", save_format="tf")保存的，优先用tf.saved_model.load("path")加载，再手动包装成 Keras 模型（如果需要调用predict()等接口） - 它不会解析
custom_objects，所以即使漏传也不会报错，但后续调用可能因输入签名不匹配而失败 - 加载后得到的是
ConcreteFunction或AutoTrackable对象，需用loaded.signatures["serving_default"]显式调用，不能直接.predict()
简单包装示例：
loaded = tf.saved_model.load("my_model_savedmodel")
infer = loaded.signatures["serving_default"]
# 输入需严格匹配 signature 定义，比如：
result = infer(inputs=tf.constant([[1.0, 2.0]]))
TensorFlow 2.16+ 加载旧模型时最常踩的坑：TF_KERAS 环境变量与 eager 模式冲突
2.16 开始默认禁用部分旧版 eager 执行路径，导致某些动态图模型（尤其含 tf.while_loop 或条件控制流的）加载后运行时报 Op type not registered，实际是 eager fallback 机制失效。
- 临时解法：启动 Python 前设环境变量
TF_KERAS=1（Linux/macOS：TF_KERAS=1 python script.py；Windows：set TF_KERAS=1 && python script.py） - 更稳妥的方式是，在加载前强制启用兼容模式：
tf.config.experimental.enable_tensor_float_32_execution(False)并关闭 v2 behavior：tf.compat.v1.disable_v2_behavior()（仅限必须支持老模型的场景） - 不要在加载后才调
tf.compat.v1.enable_v2_behavior()—— 此时图已构建失败，补救无效
这类问题往往没有明确报错指向环境变量，而是表现为“模型能加载成功，但第一次 predict() 就崩”，容易误判为数据格式问题。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
