根本原因是C++编译的.so未导出TF所需C风格符号，须用extern "C"包裹TF_InitOp；需加-fPIC、-static-libstdc++，GPU需单独注册kernel并链接CUDA库，SetShapeFn不可省略。
tf.load_op_library 加载失败：找不到符号或 undefined symbol
根本原因是 C++ 编译生成的 .so 文件没导出 TensorFlow 期望的注册函数，或者符号命名被 C++ 编译器修饰（mangling）了。TensorFlow 只认 C 风格符号，必须用 extern "C" 包裹注册逻辑。
- 确保在
REGISTER_OP和REGISTER_KERNEL_BUILDER外层，用extern "C"声明TF_InitOp函数（函数名固定，不能改） - 编译时禁用 PIC 冲突：
g++ -shared -fPIC -O2 -I${TF_INC} ... -o custom_op.so，漏掉-fPIC在多数 Linux 环境下直接报undefined symbol: _ZTVN10tensorflow8OpKernelE - 检查依赖是否干净：
ldd custom_op.so若显示not found，说明链接了本地高版本 GCC 的 libstdc++，需加-static-libstdc++或用与 TensorFlow 编译一致的 GCC 版本
Python 侧 import 后调用报错：No module named 'my_op'
不是 Python 模块导入问题，而是 tf.load_op_library 返回的是一个临时模块对象，里面没有 __name__，也不能用 import 直接引用算子名。所有算子都挂在返回模块的属性上，且名字严格匹配 REGISTER_OP("MyOp") 中的大写形式。
- 正确用法是：
my_module = tf.load_op_library("./custom_op.so"); result = my_module.MyOp(x, y) - 若注册名是
REGISTER_OP("AddV2")，就必须写my_module.AddV2(...)，大小写、下划线都不能错 - 调试时先打印
dir(my_module)，确认算子名是否真出现在输出里；如果为空，基本是TF_InitOp没被正确调用或符号名不匹配
GPU 算子加载后运行报错：Invalid argument: No registered 'MyOp' OpKernel for GPU
注册 CPU 和 GPU kernel 是两套独立逻辑，只写了一个，另一个设备就不可用。TensorFlow 不会自动 fallback，也不会提示“仅 CPU 实现”，只会静默失败或抛这个错。
- CPU kernel 必须带
.Device(DEVICE_CPU)，GPU kernel 必须明确写.Device(DEVICE_GPU).HostMemory("output")（如果输出是 host 内存） - GPU kernel 实现里不能直接用
cudaMemcpy，得通过context->eigen_device<gpudevice>()</gpudevice>获取 device handler，并用functor::封装核函数 - 编译 GPU 版本需额外链接
-lcudart -L${CUDA_PATH}/lib64，且.so文件名建议区分，比如custom_op_gpu.so，避免和 CPU 版本混淆
自定义 Op 输入/输出张量 shape 推导不生效
SetShapeFn 是可选但关键的一环。不设的话，TensorFlow 无法在图构建阶段推断下游 shape，导致 Unknown shape，进而让 tf.shape() 返回 [?, ?, ?]，甚至某些优化器或 XLA 编译直接失败。
立即学习“Python免费学习笔记（深入）”；
- 必须在
REGISTER_OP链式调用末尾加上.SetShapeFn([](::tensorflow::shape_inference::InferenceContext* c) { ... }) - 常见写法：
c->set_output(0, c->input(0));表示输出 shape 同第一个输入；若需动态计算，用c->Dim(c->input(0), 0)取维度值，再用c->MakeShape({h, w})构造新 shape - 注意：shape 推导函数在图构建期执行，拿不到 tensor 数据值，只能靠维度关系推理
TensorFlow 对自定义 Op 的加载和调度非常“守规矩”：符号名、注册时机、设备标记、shape 推导，每个环节缺一不可。最容易被跳过的其实是 extern "C" 和 SetShapeFn，而这俩恰恰是线上环境突然报错的高频原因。
