必须严格匹配模型输入输出的shape、dtype和name，否则易崩溃或输出全零；Ort::Env需显式构造并设日志级别为WARNING，SessionOptions须预设图优化、线程数及CUDA提供者，输入张量须用std::vector持久化内存并带batch维，输出名与shape须动态获取验证。
能直接用，但必须严格匹配模型输入输出的 shape、dtype 和 name，否则大概率崩溃或输出全零——这不是 API 用错了，是张量对不上。
Ort::Env 和 Ort::SessionOptions 怎么初始化才不踩坑
Ort::Env 必须显式构造，不能依赖全局静态对象；Ort::SessionOptions 必须在创建 Ort::Session 前完成所有关键配置。Windows 下链接失败八成是 onnxruntime.lib 没正确导入，或 ABI 不一致（比如项目用 /MD 而库是 /MT 编译的）。
-
Ort::Env env(ORT_LOGGING_LEVEL_WARNING, "my_app")—— 建议设为ORT_LOGGING_LEVEL_WARNING，避免调试日志刷屏 -
session_options.SetGraphOptimizationLevel(ORT_ENABLE_ALL)—— 图优化必须手动开启，否则默认不启用常量折叠、算子融合等关键优化 - CUDA 提供者注册必须在
Ort::Session构造前：调用OrtSessionOptionsAppendExecutionProvider_CUDA(options, 0) - Linux 下记得确保
LD_LIBRARY_PATH包含libonnxruntime.so所在路径
输入张量怎么构造才不会 crash
ONNX Runtime 不接管内存，Ort::Value::CreateTensor 的第四个参数（数据指针）必须在整个 Run() 调用期间有效。栈变量传指针、std::vector 临时对象取 .data() 后立刻析构，都会导致段错误。
- 用
std::vector<float></float>分配输入数据，再传.data()—— 安全且可控 - 输入 shape 必须带 batch 维度，哪怕只推一个样本：
{1, 3, 224, 224}，不是{3, 224, 224} - 图像默认排布是 NCHW；若模型导出为 NHWC，要么预处理时重排，要么用
Ort::MemoryInfo::CreateCpu(...)显式指定 layout 并自行保证内存布局 - 归一化参数顺序错（比如 BGR/RGB 颠倒、均值方差套错通道）会导致输出全零，不是报错，极难排查
怎么安全读取输出结果
别猜输出名、别硬编码 shape、别假设 dtype。ONNX 模型的输出节点名和结构由导出时决定，和 Python 端可能不一致。
立即学习“C++免费学习笔记（深入）”；
- 先用
output_values[0].GetTensorTypeAndShapeInfo().GetShape()拿真实 shape，比如分类任务常见{1, 1000}，生成任务可能是{1, 128} - 用
GetElementType()确认类型：ONNX_TENSOR_ELEMENT_DATA_TYPE_FLOAT对应.GetTensorData<float>()</float>，ONNX_TENSOR_ELEMENT_DATA_TYPE_INT64对应.GetTensorData<int64_t>()</int64_t> - 输出名不能写死为
"output"，得用session.GetOutputName(0, allocator)动态获取，或提前用netron查看模型结构 - 输出张量数据指针直接解引用前，务必确认长度：用
output_values[0].GetTensorTypeAndShapeInfo().GetElementCount()校验
最麻烦的从来不是加载模型，而是把输入数据从「看起来像」变成「完全匹配模型期望」——shape、dtype、layout、归一化、name，五者缺一不可。少查一项，就可能花半天在空输出或崩溃上兜圈子。
