核心区别在于模型结构是否动态：torch.jit.script支持动态控制流，需静态可分析；torch.jit.trace仅记录单次执行路径，遇输入变化易出错。
导出模型时 torch.jit.script 和 torch.jit.trace 怎么选
核心区别不在“能不能用”，而在“模型结构是否动态”。torch.jit.script 要求模型所有控制流（如 if、for、while）能被静态分析，适合含条件逻辑的自定义模块；torch.jit.trace 只记录一次前向执行路径，遇到输入 shape 或分支变化就可能出错——比如 if x.size(0) > 16: 这类依赖输入值的判断，在 trace 中会被固化为常量分支，换小 batch 就崩溃。
实操建议：
- 模型里有
if或循环且逻辑随输入变化 → 优先用torch.jit.script，并确保所有分支都能被类型推断覆盖（比如给forward加类型注解或用@torch.jit.export标记可导出方法） - 纯 CNN/Transformer 无条件分支 →
torch.jit.trace更快更稳，但必须用跟部署时一致的inputshape 和 dtype trace（例如部署用torch.float16，trace 时别用float32） - 混合情况（如 backbone 是 trace，head 有 if）→ 先
scripthead，再用torch.jit.script包整个模型，避免 trace “漏掉”动态部分
导出后模型在 C++ 中加载失败的常见原因
不是模型没导出成功，而是加载环境没对齐。最典型的是 torch::jit::load() 报 version mismatch 或 Unknown type name，本质是 PyTorch 版本/编译选项不一致。
关键检查点：
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- C++ API 的 PyTorch 版本必须与导出时 Python 环境的
torch.__version__完全一致（包括+cpu/+cu118后缀） - 如果模型用了自定义算子（
torch.ops.mylib.custom_op），C++ 侧必须先调用torch::jit::setCustomClassRegistrar(...)注册，否则加载直接 abort - 导出时若用了
torch.jit.save(model, "m.pt", _use_new_zipfile_serialization=True)（PyTorch 1.6+ 默认），C++ 侧需链接libtorch.so而非旧版libcaffe2.so - 模型含
torch.nn.BatchNorm2d且训练态未设model.eval()→ C++ 加载后推理会因 running_mean/std 未初始化而 nan
torch.jit.optimize_for_inference 真的能提速吗
能，但只对特定模式有效。它本质是启用 TorchScript 内置的图优化 Pass（如算子融合、dead code elimination），但效果高度依赖模型结构和输入配置。
实测经验：
- 对 ResNet、MobileNet 类静态图模型，开启后 CPU 推理快 10%–25%，GPU 上收益不明显（CUDA kernel 已高度优化）
- 若模型含大量
torch.where或torch.gather，优化可能把稀疏访存转成密集计算，反而变慢 - 必须在
torch.jit.load()后、to(torch::kCUDA)前调用，否则 GPU 设备迁移会重置图结构，优化失效 - 别跟
torch.compile混用：后者作用于 Python 层图，optimize_for_inference作用于已序列化的 TorchScript 图，叠用无意义
脱离 Python 运行时，如何传入图像等非 tensor 数据
TorchScript 模型只认 torch::IValue（对应 Python 的 torch.Tensor、int、bool、tuple、dict），不支持 PIL.Image 或 NumPy array。C++ 侧必须自己完成预处理流水线。
典型做法：
- 用 OpenCV 读图 →
cv::cvtColor转 RGB →cv::resize→cv::Mat::convertScaleAbs归一化到 [0,1] →torch::from_blob构造torch::Tensor - 注意内存布局：OpenCV 默认 BGR/HWC，模型通常要 RGB/CHW，必须显式 transpose（
permute({2,0,1})）且 clone()，否则from_blob的 Tensor 会引用 Mat 内存，Mat 析构后访问越界 - 若预处理含随机增强（如
RandomHorizontalFlip），不能放 C++ 侧——TorchScript 不支持 random state，必须在导出前固定为确定性逻辑（如用torch.randint替代random.choice）
真正麻烦的从来不是导出这一步，而是预处理和后处理链条能否完全脱离 Python 生态——OpenCV 可以，但像 Albumentations、Timm 的 transforms 就得重写 C++ 版本。
