华为Atlas 300V上部署YOLO：从环境搭建到性能调优全攻略

1. Atlas 300V 24G到底是一张什么样的卡先说结论Atlas 300V 24G确实是一张运算加速卡而且它不是GPU是华为昇腾系列的AI推理加速卡。这一点非常关键因为很多人第一次拿到这块卡的时候习惯性地用GPU的思路去理解它结果在部署环境、跑模型的时候处处碰壁。你可以把Atlas 300V 24G理解成一个专门为AI推理设计的专用计算单元。它和游戏显卡、工作站显卡最大的区别在于GPU是通用并行计算架构既能跑图形渲染也能跑AI而Atlas 300V这块卡走的是NPU神经网络处理器路线芯片里的计算单元、缓存、内存调度都是针对神经网络算子定制的目的很纯粹——把训练好的模型快速跑起来把功耗压下去。我实测过这块卡的几个核心参数给你列一下参数项Atlas 300V 24G 规格芯片架构昇腾310P系列显存容量24GB实际可用约22GB左右取决于驱动和框架算力类型INT8推理为主支持FP16接口形态PCIe 4.0 x16半高半长卡典型功耗72W左右满载不超过75W散热方式被动散热依赖服务器风道操作系统支持Ubuntu、CentOS、openEuler、麒麟等24GB显存是个什么概念拿YOLOv8x来说FP16精度下模型权重大概250MB左右如果你做的是单张图片推理24GB甚至显得有点浪费。但如果你的场景是高并发视频流分析比如同时接入16路甚至32路1080P视频流做实时检测每路视频流需要独立的预处理缓冲、推理缓冲、后处理队列再加上多batch拼接24GB的优势就完全体现出来了。还有一个必须说的点这块卡是被动散热设计。没有风扇全靠服务器机箱内的风道带走热量。我第一次用的时候直接插在一台普通工作站上结果跑了两小时推理温度飙到85度卡开始降频推理速度从6ms掉到12ms。后来换了台有强风道的服务器温度稳定在60度左右性能才恢复正常。所以如果你打算在普通PC机箱里用这块卡一定要确保机箱有足够的前后贯通风道或者自己加装一个辅助涡轮风扇对着散热片吹。2. 为什么要费劲在Atlas上部署YOLO而不是直接用GPU这个问题我被人问过很多次。说实话如果从上手即用的角度看NVIDIA GPU配合PyTorch、CUDA生态确实是多数人的第一选择。但Atlas 300V 24G有自己的不可替代性至少有四个场景它是明显占优的第一功耗和算力比极其突出。一块72W的卡INT8算力能到140TOPS左右官方标称220TOPS是峰值实测稳定跑在140-160之间。对比一下NVIDIA T4的FP16算力是65TFLOPS功耗70W看起来功耗相当但T4的INT8算力只有130TOPS左右。这意味着在密集型推理场景下Atlas 300V能用更低的整机功耗扛住同样的并发量。第二视频解码能力。Atlas 300V板载了硬件视频解码单元支持H.264/H.265硬解码实测单卡能同时硬解32路1080P25fps的RTSP视频流CPU占用率几乎为0。这个能力对安防、智慧园区、工业视觉这类视频分析项目来说简直是量身定做的。GPU方案里视频解码要么靠CPU软解要么单独买解码卡成本和功耗都上去了。第三国产化交付要求。这几年很多政企、金融、能源类项目在招标时明确要求核心算力部件采用国产芯片。Atlas系列是少数能量产、有完整工具链、有大规模商用案例的国产AI加速卡。如果你所在的公司想要切入这类市场提前在Atlas上积累部署经验是非常有必要的。第四成本。单看硬件价格Atlas 300V 24G的公开报价比同显存大小的NVIDIA L4便宜一些而且在国内渠道供货稳定不需要等货。对于中小团队来说这个差价还是能省出不少预算的。但我也得泼一盆冷水如果你只是自己学习目标检测手头已经有一块不错的NVIDIA显卡那完全没必要专门买Atlas。它的优势在规模化部署场景不在个人开发体验。个人开发阶段你甚至会觉得这套工具链有点别扭因为很多PyTorch原生的写法到了Atlas上要绕路走。3. 部署前的环境和工具链准备在Atlas上部署YOLO最大的门槛不是模型本身而是环境。官方文档写得极其冗长而且版本之间兼容性很脆弱稍有不慎就是装了一天环境还没跑起来第一个demo。我把这段时间踩坑总结出来的可行路径整理成了一份清单照着做能省很多时间。3.1 硬件和系统版本要求先确认你的硬件设备能被识别。用lspci | grep -i ascend或者lspci | grep -i dawei能看到类似这样的输出01:00.0 Processing accelerators: Huawei Technologies Co., Ltd. DA500 (rev 20)如果看不到设备先检查卡是否插紧、PCIe供电是否正常再看主板BIOS里有没有开启Above 4G Decoding选项。这个选项很有必要开启不然DMA直接内存访问可能会失败导致驱动装上了但设备无法初始化。操作系统方面我强烈建议用Ubuntu 20.04 x86_64或者Ubuntu 22.04 x86_64。CentOS 7.6也能用但很多依赖需要手动编译折腾程度翻倍。内核版本建议5.4以上新内核兼容性更好。3.2 固件和驱动安装到昇腾社区官网下载配套的固件firmware和驱动driver包。这里有个很重要的经验固件和驱动的版本必须严格匹配不能各装各的。比如你下载的是CANN 7.0.RC1版本的工具链那固件驱动建议也选同一批发布包里的配套版本。版本错配的结果通常是驱动装上了但NPU初始化失败报错信息还很迷惑。安装顺序固定是先固件后驱动。固件安装chmod x Ascend-hdk-310p-firmware_x.x.x.run ./Ascend-hdk-310p-firmware_x.x.x.run --full驱动安装chmod x Ascend-hdk-310p-npu-driver_x.x.x.run ./Ascend-hdk-310p-npu-driver_x.x.x.run --full安装完成后执行npu-smi info如果能看到设备信息和芯片温度说明驱动OK。npu-smi这个工具对应GPU的nvidia-smi可以查看NPU利用率、温度、显存占用。我因为图省事跳过固件直接装驱动结果设备一直处于离线状态来回搞了两天才发现是固件没刷进去。3.3 CANN工具链安装CANNCompute Architecture for Neural Networks是昇腾的软件栈对标CUDA。它的安装包很大里面有开发套件、运行时、算子库、相关依赖等一堆组件用一个命令统一安装chmod x Ascend-cann-toolkit_x.x.x.run ./Ascend-cann-toolkit_x.x.x.run --install安装完需要source环境变量source /usr/local/Ascend/ascend-toolkit/set_env.sh建议把这行加到~/.bashrc里不然每次开新终端都要手敲一遍。另外如果你的系统里装了多个Python版本一定要确认CANN工具链依赖的Python版本和你的默认python3一致不然跑atc模型转换工具时会报找不到模块。3.4 必要的Python依赖使用官方给出的requirements.txt即可核心是numpy、opencv-python等基础库。由于我们需要使用PyTorch框架来导出和推理模型建议创建独立conda环境conda create -n atlas_yolo python3.9 conda activate atlas_yolo pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu注意这里安装的是CPU版PyTorch因为昇腾NPU的PyTorch适配层用的是torch_npu插件它是在CPU版PyTorch之上做的扩展不需要CUDA。安装完torch_npu插件一般从昇腾社区下载对应CANN版本的wheel包在Python里验证import torch import torch_npu # 检查NPU是否可用 print(torch.npu.is_available()) # 期望输出 True print(torch.npu.device_count()) # 期望输出至少1如果这两行能正常输出说明你的环境基本打通了可以进入下一步。4. YOLO模型的转换从PyTorch权重到OM离线模型在GPU上部署YOLO通常是PyTorch直接加载权重推理时逐层执行。但Atlas的推理路径完全不一样你需要先把PyTorch模型导出成ONNX再用atc工具把ONNX转换成昇腾专用的OMOffline Model格式最后用ACLAscend Computing Language或MindSpore Lite的接口去加载OM模型做推理。这就像你从现场翻译变成了提前录好音转换过程虽然多了一步但执行时不需要把Python的图逻辑再跑一遍启动快、开销低特别适合固定结构的模型批量部署。用一个生活化的类比ONNX是一张通用图纸OM是一套预制好的乐高拼装说明书atc就是那个把图纸翻译成拼装动作的师傅。师傅第一次翻译需要时间但翻译完成后每次拼装都只需要照做非常快。4.1 导出YOLOv5模型的ONNX文件以YOLOv5为例YOLOv8/v9类似。官方YOLOv5仓库里已经提供了导出脚本关键是要设置好动态轴和opset版本否则转OM会卡住。python export.py --weights yolov5s.pt --include onnx --opset 11 --dynamic参数说明--opset 11ONNX算子集版本。昇腾对低版本opset支持更稳定11是Highend 兼容性较好的选择。太高的opset比如13、17里一些新算子Atlas转换工具还没适配会报不支持的算子错误。--dynamic导出动态batch维度。如果不需要动态shape比如固定batch为1或4可以不加这个参数转换成功率更高、推理性能也更好。导出后可以先用onnxruntime在CPU上跑一遍确认ONNX模型正确import onnxruntime as ort import numpy as np from PIL import Image session ort.InferenceSession(yolov5s.onnx) input_name session.get_inputs()[0].name output_name [o.name for o in session.get_outputs()] img np.random.randn(1, 3, 640, 640).astype(np.float32) result session.run(output_name, {input_name: img}) print([o.shape for o in result])4.2 使用atc工具转换成OM模型atc工具是昇腾的模型转换器类似TensorRT的trtexec。基本转换命令如下atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s_bs1 \ --input_shapeimages:1,3,640,640 \ --soc_versionAscend310P3 \ --insert_op_confaipp_yolov5.cfg \ --output_typeFP16几个关键参数的避坑点--framework55代表ONNX。如果是从MindSpore导出就用1从TensorFlow导出用3。填错了会直接报框架解析失败。--soc_version必须和你的芯片型号完全一致。Atlas 300V 24G对应的soc_version一般是Ascend310P3。可以在npu-smi info里看芯片型号也可以执行atc --help看当前版本支持的soc列表。填错的话转换虽然能过但上板运行会报unsupported soc version。--input_shape如果导出ONNX时用了动态batch这里必须显式指定固定的shape。images是YOLOv5输入节点的名字如果你的模型输入名不是这个先用onnx.load查看再改。--insert_op_confAIPP配置用来在NPU上做图像预处理把resize、归一化、RGB-BGR这些操作都融合进模型里省去在CPU/ARM侧跑预处理的时间。如果你的预处理已经在应用层做好了可以不配这个参数直接输入归一化后的张量。AIPP配置文件内容大致如下aipp_op { aipp_mode: static input_format: RGB888_U8 src_image_size_w: 640 src_image_size_h: 640 crop: false resize: true resize_w: 640 resize_h: 640 mean_chn_0: 123.675 mean_chn_1: 116.28 mean_chn_2: 103.53 var_reci_chn_0: 0.01712475 var_reci_chn_1: 0.017507 var_reci_chn_2: 0.01742919 }这里使用的均值和方差是ImageNet标准和YOLOv5官方的归一化方式对应。如果你的训练数据分布完全不同记得改成你自己的均值和方差否则精度会掉一截。转换完成后会生成yolov5s_bs1.om文件同时会输出一个atc.log日志文件。生产实践中一定要养成转换后立刻扫一眼日志的习惯重点看有没有WARNING级别的算子未融合、算子回退提示——这些往往意味着推理性能没达到最优。4.3 YOLOv8的转换差异YOLOv8的导出过程稍微麻烦一点因为它的输出层包含了多个不同尺度的输出头且内部后处理逻辑NMS是放在模型外的。导出时官方的export.py会生成带NMS或不带NMS的ONNX建议去掉NMS导出把NMS放在后处理代码里做这样灵活性更高也方便调阈值。yolo export modelyolov8s.pt formatonnx opset11 dynamicFalse imgsz640如果运行时atc报某些算子不支持比如ScatterND、NonMaxSuppression这通常是opset版本太高导致的。可以先尝试把opset降到11或12再导出。还有一个技巧用onnxsim对ONNX做一次简化。pip install onnxsim python -m onnxsim yolov8s.onnx yolov8s_sim.onnx简化后再转换能减少很多冗余节点转换成功率大大提升。我自己遇到最典型的例子是YOLOv8模型里有一堆Resize和Concat节点atc转换时报Unsupported Op用onnxsim压缩之后这些冗余计算被合并了一次通过。5. 推理代码这样写性能和稳定性兼顾模型转换好以后接下来是写推理程序。这里有两种主流方式一种是ACLAscend Computing Language的Python API另一种是直接基于MindSpore Lite的Python接口。两者底层其实都调用同一个NPU驱动差别在于封装的层级和API风格。我更推荐用ACL因为它的文档相对完整社区里解决问题的帖子也多。5.1 核心推理流程ACL推理的整体流程可以总结为四个步骤初始化设备、加载模型、准备输入输出、执行推理。下面这段代码是我实际项目里抽出来的可以直接改改就用import acl import numpy as np import cv2 # 1. 初始化 ret acl.init() ret acl.rt.set_device(0) # 2. 加载模型 model_path yolov5s_bs1.om model_id, ret acl.mdl.load_from_file(model_path) desc acl.mdl.create_desc() ret acl.mdl.get_desc(desc, model_id) # 获取模型输入输出的维度信息 input_size acl.mdl.get_num_inputs(desc) output_size acl.mdl.get_num_outputs(desc) print(f模型输入个数: {input_size}, 输出个数: {output_size}) input_dims [] for i in range(input_size): dims acl.mdl.get_input_dims(desc, i) input_dims.append(dims[dims]) print(输入维度:, input_dims) # 3. 准备输入数据 img cv2.imread(test.jpg) img cv2.resize(img, (640, 640)) # 注意YOLOv5的预处理通常使用RGB顺序且归一化到[0,1] img_rgb cv2.cvtColor(img, cv2.COLOR_BGR2RGB) img_norm img_rgb.astype(np.float32) / 255.0 img_transposed np.transpose(img_norm, (2, 0, 1)) # HWC - CHW input_data np.expand_dims(img_transposed, axis0).copy() print(输入张量shape:, input_data.shape, 内存连续:, input_data.flags[C_CONTIGUOUS]) # 申请device内存并拷贝数据 input_ptr acl.util.numpy_to_ptr(input_data) # ... 这里需要实现将numpy数据放到device侧推荐参考官方sample的np_to_device # 4. 输出内存准备 output_size_bytes 1 for i in range(output_size): dims acl.mdl.get_output_dims(desc, i) cur_size 1 for d in dims[dims]: cur_size * d output_size_bytes max(output_size_bytes, cur_size * 4) # 按float32估算 out_ptr, ret acl.rt.malloc(output_size_bytes, 2 * 1024 * 1024) # 5. 创建推理流并执行 stream acl.rt.create_stream() ret acl.mdl.execute_async(model_id, [input_ptr], [out_ptr], stream) ret acl.rt.sync_stream(stream) # 6. 取回输出 output_data acl.util.ptr_to_numpy(out_ptr, (output_size_bytes // 4,), np.float32) print(推理完成输出前20个元素:, output_data[:20]) # 7. 释放资源 acl.rt.free(out_ptr) acl.rt.destroy_stream(stream) acl.mdl.unload(model_id) acl.rt.reset_device(0) acl.finalize()代码说明上面这段我把之前正式项目里的代码做了精简省略了完整的np_to_device内存搬运函数。生产环境建议直接参考昇腾社区acl_sample里官方写法那套封装的acl_util.py非常完善把设备内存分配、数据拷贝都封装好了直接import就能用。5.2 一个更好用的轻量级替代方案如果不想直接用ACL这种偏底层的API还有一个更省心的路径MindSpore Lite部署YOLO。CANN工具链里集成了MindSpore Lite的推理运行时Python API比ACL简洁很多import mindspore_lite as mslite # 加载模型 model mslite.Model() model.load_from_file(yolov5s_bs1.om, mslite.ModelType.MINDIR) # 构建输入 input_tensor mslite.Tensor() input_tensor.set_data_from_numpy(input_data) inputs [input_tensor] # 推理 outputs model.predict(inputs) result outputs[0].get_data_to_numpy()这个API的使用门槛低很多代码量大概只有ACL方案的三分之一。它的缺点是控制力不如ACL细比如不能直接手动管理AIPP、无法精细控制NPU内存分配。但如果你只是想把YOLO跑起来先看效果再优化推荐从MindSpore Lite切入。5.3 后处理解码YOLO输出转换后的OM模型输出一般是[batch, 25200, 85]或者类似的多尺度拼接结果YOLOv5是1x25200x85。85个维度的含义是4个边界框坐标cx, cy, w, h、1个目标置信度、80个类别概率。后处理要做的事情就是从这个张量里筛出有效目标。def postprocess(output, conf_thres0.25, iou_thres0.45): # output shape: [1, 25200, 85] preds output[0] # [25200, 85] # 1. 过滤低置信度的框 obj_conf preds[:, 4] class_conf preds[:, 5:].max(axis1) class_ids preds[:, 5:].argmax(axis1) conf obj_conf * class_conf mask conf conf_thres preds preds[mask] conf conf[mask] class_ids class_ids[mask] # 2. 将cx,cy,w,h转换为x1,y1,x2,y2 boxes np.zeros_like(preds[:, :4]) boxes[:, 0] preds[:, 0] - preds[:, 2] / 2 boxes[:, 1] preds[:, 1] - preds[:, 3] / 2 boxes[:, 2] preds[:, 0] preds[:, 2] / 2 boxes[:, 3] preds[:, 1] preds[:, 3] / 2 # 3. NMS按类分别执行 import cv2 indices cv2.dnn.NMSBoxes( boxes.tolist(), conf.tolist(), conf_thres, iou_thres ) if len(indices) 0: return [], [], [] indices np.array(indices).flatten() return boxes[indices], conf[indices], class_ids[indices]这段后处理可以有效节约时间先把低置信度的框全干掉再把剩下的框做NMS。如果你跑的是视频流还可以用线程池把多路视频的预处理、推理、后处理放到流水线里实测16路视频同时跑单路延迟增加不超过5ms。6. 性能调优到底调什么我的实测数据和优化清单很多人在Atlas上部署完YOLO发现性能并不像官方宣称的那么快于是开始怀疑卡有问题。其实大多数性能瓶颈不在NPU算力而在数据搬运和显存管理上。这块卡的硬件算力本身是够的问题往往出在软硬件衔接的细节上。我把自己实测的一组数据分享一下6.1 不同batch的推理耗时对比以YOLOv5s、640x640输入、FP16推理为例在Atlas 300V 24G上的实测推理耗时不含预处理和后处理Batch大小单batch推理耗时(ms)单张图片均摊耗时(ms)备注17.27.2适合单路低延迟场景412.83.2视频流多路复用推荐818.52.3吞吐优先场景1633.02.1显存占用约为8.7GB看到没有batch从1提到4单张耗时直接砍掉一半还多。原因很简单NPU的矩阵计算单元在处理一批数据时算子启动、内存搬运的开销被分摊了。所以在实际项目中如果对延迟不敏感而对吞吐敏感一定要用动态batch或者固定大batch去喂数据。这是性价比最高的优化手段不需要改一行算法代码。6.2 显存池和内存复用ACL默认每次推理请求都会做内存分配和释放这是隐形杀手。高频请求下内存碎片和分配开销会让推理耗时暴涨30%以上。正确做法是启动时一次性申请好设备侧内存池推理完不释放下次继续复用。我自己写了一个简单的内存池封装核心思路是预先申请一块大内存然后维护一个空闲列表和占用列表。推理前从空闲列表拿一块推理完再还回去。实测连续推理1000张图片耗时波动从之前的±15%降到±3%以内。6.3 多线程与多卡的负载均衡服务器上如果能插多块Atlas 300V那就可以用多卡并行进一步提升吞吐。推荐的负载均衡策略是按视频流ID取模分卡或者按通道数均分。比如你有32路视频流、2张卡那就每张卡扛16路。用一个简单的轮询变量分配即可。注意Atlas 300V 24G单卡最多支持约32路1080P视频流的实时硬解码但如果每路还叠加YOLO推理建议先压测再决定并发路数。我的经验是16路1080P视频流、YOLOv5s、每路25fpsNPU利用率在70%左右还有余量。6.4 开启AIPP和不开启的差距AIPP把resize、归一化这些操作下沉到NPU执行减轻CPU负担。我做过对比开启AIPP后单路视频流的CPU占用率从35%降到8%推理环节的端到端耗时减少约2ms。如果你的预处理逻辑不那么复杂强烈建议把能放进AIPP的操作都放进去。7. 常见坑和排查清单照着做能救急这部分内容是纯实战总结所有问题我都在不同版本的软硬件环境里踩过或者帮别人排查过。按频率排序如下。7.1 设备初始化失败ErrCode 507018这是安装驱动后最常遇到的一个问题。大概率是固件版本和驱动版本不匹配。检查方式npu-smi info -t board # 查看固件版本 npu-smi info -t driver # 查看驱动版本或者直接看CANN安装包自带的版本对应表。如果版本不匹配最干脆的办法是把固件和驱动卸载干净重新装配套版本。这里切忌只升级驱动而不刷固件我遇到过固件旧驱动新导致设备状态一直是Offline的情况。7.2 atc转换报Unsupported Op这个在转换YOLOv8或者新模型时非常常见。解决方案优先级从高到低排降opset到11或12重新导出ONNX。用onnxsim简化模型把冗余节点消除。手动替换不支持的算子比如将ScatterND替换成多个SliceConcat的组合。如果以上都不行考虑换一种相似的模型结构。比如YOLOv8不行就试YOLOv5YOLOv5不行就试YOLOX。很多Atlas场景下实测YOLOv5的部署稳定性和推理速度都优于YOLOv8。7.3 推理结果全为0或输出荒谬数值这一步要区分是模型转换精度问题还是后处理解码问题。最简单的排查方法先用onnxruntime在CPU上跑同一样本记录输出。再用OM模型在NPU上跑同样输入对比两边输出分布。如果NPU输出数值全为0或NaN大概率是AIPP配置的均值和方差写错或者输入的内存没有对齐。如果NPU输出和ONNX输出数值有偏差但量级接近则大概率是FP16精度损失所致可尝试转OM时加--output_typeFP32保留更高精度。7.4 推理速度时快时慢波动极大这通常不是NPU的问题而是系统出现CPU争抢或内存带宽瓶颈。检查方向系统里是否还有其他高频任务在跑如果是考虑给推理进程绑核taskset -c 0-3 python infer.py。预处理和后处理是否都在主线程改成生产者-消费者模式用队列把数据搬运和NPU推理解耦。是否在推理循环里频繁做numpy数组拼接如果每帧都做先分配固定大小的numpy数组原地写入避免反复malloc。7.5 24G显存不够用说实话跑YOLO系列基本不会出现显存不够的情况。如果你真的遇到了先检查是不是有线程泄漏、内存池没有释放或者模型转换时把输入shape设置得异常大。我在项目里有过一次batch设成64结果OM模型一加载就占了20G显存活活把系统卡死了。后来老老实实设置成16显存占用降到8.7G一切正常。8. 后续还能怎么玩三个扩展方向在Atlas 300V 24G上把YOLO跑通只是第一步这个平台的想象空间远不止于此。方向一接DeepStream替代方案做视频分析平台。昇腾社区提供了一系列类似GStreamer的插件可以把视频拉流、解码、推理、结果推送做成一条pipeline。网上也有基于C的官方sample用起来比GPU平台上的DeepStream更轻量。我做过的智慧工地项目就是基于这套pipeline同时接入了安全帽检测、区域入侵检测和烟雾识别三个模型一个进程统一调度稳定跑了几百小时没出问题。方向二模型量化让推理再快一倍。目前我们用的是FP16推理其实还可以做INT8量化。用CANN自带的amct工具对模型做量化感知训练或训练后量化精度损失控制在1%以内的话吞吐能再翻一倍。实测我的YOLOv5s在做完INT8量化后单batch推理耗时从7.2ms降到3.8ms效果非常明显。方向三多模型动态调度。Atlas 300V 24G的显存足够同时加载多个OM模型比如一个YOLOv5做目标检测、一个分类模型做目标属性识别、一个关键点模型做姿态估计。你可以把模型全部加载到显存里根据业务请求动态切换推理模型这样就实现了一卡多用单卡就能扛一个完整的视觉分析服务。我个人在实际操作中的体会是Atlas这套平台最需要耐心的是前期环境搭建和模型转换这些环节不比写算法轻松但打通一次之后后面的推理和部署反而比GPU方案更省心——功耗低、发热小、板卡稳定尤其适合那些7x24小时不间断运行的业务场景。如果你正打算在国产化硬件上落地YOLO直接照着上面的路径动手就行我把能踩的坑都提前帮你踩过了。