企业官网建设流程全解析

如果你也和我一样，在某鱼或渠道商手里收到一张 Atlas 300V 24G，准备拿来部署 YOLO 跑目标检测，那第一晚大概率心情不会太好。包装盒挺像模像样，卡插上去之后 npu-smi 也能识别，但顺着教程一跑，不是驱动版本对不上，就是 ATC 转换报算子不支持，再不然就是模型能推理但输出全乱码。网上问"Atlas 300V 24G 是运算加速卡吗"的特别多，问"Atlas 部署 YOLO"的也不少，但能把这两个问题一次讲透、还愿意把坑都摊开说的文章，基本找不到。

这篇文章就是我做这件事的完整复盘：从确认这张卡的定位、搞懂它到底是不是"运算加速卡"，到装好环境、把 PyTorch 的 YOLO 模型转到离线 OM 格式，再到写出第一版能跑的推理代码，最后做性能调优踩过的所有坑。如果你正准备在昇腾平台部署 YOLOv5/YOLOv8/YOLOv10，或者只是想弄明白这张卡到底能不能买，这篇应该能帮你省下不少冤枉时间。

1. 先把"运算加速卡"这个问题掰扯清楚：Atlas 300V 24G 的真实定位

1.1 它确实是加速卡，但加的是"推理"这条赛道

华为官方的产品定义里，Atlas 300V 系列属于 AI 推理卡，这个分类本身就说明问题。很多人习惯把"加速卡"等同于 NVIDIA 的 GPU，觉得能跑 CUDA、能训练、能推理、能做通用计算，才叫加速卡。但昇腾这张卡不一样，它上面不是 GPU，而是基于达芬奇架构的 NPU，核心是 AI Core。AI Core 的设计目标很纯粹：大量并行的矩阵乘、卷积运算，规格上主要面向 INT8 和 FP16 精度，FP32 算力非常有限。

所以，如果你问"Atlas 300V 24G 是运算加速卡吗"，我的回答是：它是加速卡，但是一条腿的加速卡。它擅长的是把训练好的模型"跑起来"，而且是高吞吐、低功耗地跑，而不是在卡上做模型训练、做科学计算、跑 CUDA 生态的各种库。你要是拿它跑 PyTorch 里的张量操作，会发现很多算子压根不支持；但拿它跑 YOLO 推理、跑 Stable Diffusion 的推理加速，它反而很有优势。想清楚这一点，后面遇到算子不支持、API 和 CUDA 完全不同的情况时，心态会好很多。

还要注意，Atlas 300V 系列里还分 300V 和 300V Pro，硬件规格不一样，对应 SoC 版本也不同。300V Pro 通常采用昇腾 310P 系列芯片，支持最大 24GB 显存，功耗控制在几十瓦级别，不需要外接供电。这张卡在边缘侧视觉推理场景里，确实是对标 NVIDIA 入门级推理卡（比如 T4、A2）的存在。

1.2 24GB 显存到底能装下多少东西

单看"24GB"这个数字，很多人第一反应是"这卡很强"。但我要泼一盆冷水：显存大不等于速度快。Atlas 300V 用的显存是 LPDDR4X，不是 NVIDIA 那样的 GDDR6 或者 HBM，带宽上限差着数量级。你可以把算力想象成工厂的流水线速度，把显存带宽想象成原材料运输的卡车数量，流水线再快，卡车拉不过来也是白搭。

那 24GB 在实际 YOLO 部署里有什么用？作用在于你能同时塞下更多模型、跑更大的 batch。比如 YOLOv5s 的 FP16 权重只有 14MB 左右，YOLOv8s 是 22MB 左右，YOLOv10s 也在这个量级。一张 24GB 的卡，同时加载几个模型做服务化部署完全没压力，甚至 batch 放到 8、16 也不会爆显存。如果跑的是 YOLOv5x 或者大输入尺寸的变体，24GB 也足够你在 batch 上做文章。

我给自己列过一个简单参考表，方便后续选 batch 用：

注意，表格里的时延是我在实际环境里的量级参考，不是官方 benchmark。因为时延受固件版本、输入尺寸、是否开 AIPP、芯片温度影响很大，不同板卡之间差个两三倍都正常。但至少你有个概念：这卡跑常规 YOLO 系列是绰绰有余的，瓶颈通常不在显存容量，而在算子融合和内存带宽。

1.3 什么场景该选它，什么场景别碰

这是我被问过最多的问题："我该买 Atlas 300V 还是买块 NVIDIA 显卡？"我的建议很简单，分场景看。

适合选 Atlas 300V 的场景：

• 边缘盒子、工控机、产线视觉设备：功率低、尺寸小、不需要外接供电，比插一块 200W 的大 GPU 友好太多。
• 多路视频流并行分析：24GB 显存可以同时跑多个模型或多个 batch，适合 8 路、16 路摄像头实时检测。
• 软件栈可控、不需要随便装第三方库的封闭项目：昇腾的 CNM（CANN）生态虽然不比 CUDA 丰富，但只要你按官方版本来，稳定性反而高。
• 成本和采购渠道敏感的项目：二手或渠道市场的 300V 价格通常比同等显存的 NVIDIA 卡便宜，功耗也低。

不适合的场景也很明确：

• 你需要训模型：在 300V 上跑训练是自讨苦吃，哪怕能跑，性能和精度管理都是一团糟。训练还是老老实实用 GPU 或者昇腾 910 那种训练卡。
• 你的推理链路依赖 TensorRT 插件、OpenCV 的 CUDA 加速、numpy 生态：昇腾的算子库是另一套体系，很多熟悉的优化手段无效。
• 你只有 CUDA 经验、没有精力学新东西：昇腾的 ACL（AscendCL）接口和 CUDA Runtime 差别很大，学习曲线是实打实存在的。

一句话总结：如果你只想插上卡、pip install 一下就跑 YOLO，Atlas 300V 会给你上一课；如果你愿意花半天时间把环境搞通，它的回报很值。

2. 部署前最容易翻车的环境工程：驱动、固件与 CANN 版本三角恋

2.1 拿到卡第一件事先确认芯片型号和固件

我收到这张卡后做的第一件事，不是急着装驱动，而是先拿放大镜看铭牌、然后插到机器上用 npu-smi 探测。因为 Atlas 300V 这个系列头绪太多，光看外包装识别不出来具体规格，而后面 ATC 转换模型时，--soc_version参数必须和芯片严格对应，填错了转换出来的 OM 模型根本加载不了。

插好卡、开机之后，先在终端跑一下：

npu-smi info

正常情况下能看到设备列表、芯片型号、固件版本、显存总量。如果设备不在线，先查供电和 PCIe 插槽；如果显示 Abnormal，大概率是固件和驱动不匹配，这时候继续装环境就是浪费生命。

这里有个容易踩的坑：npu-smi 能看到设备不代表环境就绪。设备健康只是第一层，后面 ACL 初始化能否成功，完全取决于驱动、固件、CANN 三者的版本对不对得上。

2.2 三件套版本怎么对（驱动 + 固件 + CANN）

昇腾这套软件栈和 NVIDIA 最大的不同，是"牵一发动全身"。NVIDIA 你换驱动版本，顶多影响 CUDA 版本匹配；昇腾这边驱动、固件、CANN 是严格绑定的一套体系，乱装的话轻则警告，重则设备直接进保护状态。

通常的做法是：从华为昇腾官网上找到对应硬件型号的"驱动程序 + 固件"包，再选一个官方兼容列表里能对应的 CANN toolkit 版本。以我用的 CANN 6.3.RC3 为例，官方配套的是 23.0.RC3 系列的 driver 和 firmware，三者版本号要能对应上。

安装顺序也有讲究：

1. 先装固件（firmware），再装驱动（driver）。顺序反了偶尔也能装上，但重启后容易出诡异问题。
2. 驱动装完先npu-smi info确认设备正常。
3. 再解压 CANN toolkit，运行./install.sh安装。
4. 添加环境变量，主要是/usr/local/Ascend/ascend-toolkit/latest/bin和set_env.sh。

版本不匹配时我遇到过的典型报错是 ACL 初始化返回 507033，还有个是aclmdlLoadFromFile加载 OM 模型时直接返回 145000。这种错误看官方文档往往只告诉你"设备错误"或"模型加载失败"，很难想到根因其实是驱动版本太老、CANN 期望的新版本接口不存在。排查方法就是比对三件套版本。

2.3 容器化部署还是物理机裸跑

生产环境我建议容器化，但个人测试阶段别急着上容器。为什么？容器化部署昇腾的场景，要求宿主机先装好驱动和固件，容器内部只需要挂载 CANN 的 toolkit 目录，然后用 Ascend Docker Runtime 把 NPU 设备映射进容器。这套东西配置好了当然可移植性高、环境隔离好，但配置过程本身也是坑——device 映射、用户组权限、挂载目录对不上，都会让你怀疑人生。

我个人的经验是：第一遍先在物理机上裸跑通全部流程，把驱动、固件、CANN、ATC、ACL 都搞明白，确认模型能正常推理出图，再去考虑 Dockerfile、镜像、多副本部署的事。物理机上只要注意别在 root 之外的用户上被文件权限卡住就好。

2.4 装完怎么看设备是否正常

环境装完，别急着跑 YOLO，先用三组命令和一个小脚本做健康检查。

# 查看设备基本信息和芯片状态 npu-smi info # 查看板卡电源、温度等硬件健康状态 npu-smi info -t board # 查看当前跑在 NPU 上的进程 npu-smi info -t proc

然后写一个最小的 Python ACL 初始化脚本，能过这关基本就说明环境没问题：

import acl def check_device(): ret = acl.init() assert ret == 0, f"acl.init failed: {ret}" ret = acl.rt.set_device(0) assert ret == 0, f"set_device failed: {ret}" ret = acl.rt.create_context(0) assert ret == 0, f"create_context failed: {ret}" print("Device check passed") acl.rt.reset_device(0) acl.finalize() if __name__ == "__main__": check_device()

这里要是报acl.rt.set_device失败，优先检查权限和是否有其他进程占用了 NPU。用普通用户跑的话，需要把用户加进HwHiAiUser用户组，否则即使是初始化这一步都可能被权限挡住。

3. YOLO 模型到达 Atlas 的必经之路：PyTorch 到 ONNX 再到 OM

3.1 导出 ONNX 时的几个关键开关

昇腾的部署链路和 TensorRT 很像：你不能直接拿 PyTorch 模型丢给 ATC，PyTorch 训练好的权重要先导出成 ONNX，再用 ATC 转成昇腾的离线模型 OM。导出 ONNX 这一步看起来简单，实际上埋了很多雷，尤其是你打算后续在昇腾上部署时。

第一个关键点是 opset 版本。我一开始用默认的 opset 17 导出，ATC 转换时直接报不支持的算子类型，后来换到 opset 11 才顺利通过。不同版本 CANN 对 ONNX 算子支持范围不一样，官方文档会列一张支持算子表，但我更推荐的做法是：先用 opset 11 试，不行再降或升，找到当前 CANN 版本下的稳定区间。我用的 CANN 6.3.RC3 对 opset 11 支持最好，这是社区里很多人验证过的。

第二个关键点是：导出时别带 NMS。YOLOv5 的export.py里有个--end2end参数，可以导出带 NMS 的端到端模型；YOLOv8 的官方导出也支持指定nms=True。但昇腾的 ATC 对内置 NMS 的支持一直不算友好，融合不好时会掉精度，而且出了问题极难调试。我更建议导出纯检测头输出，把 NMS 后处理放在 Host CPU 侧做，这样排查问题方便，换 NMS 算法也灵活。

导出命令参考：

python export.py --weights yolov5s.pt --include onnx --opset 11 --img 640 --batch 1

注意--batch 1。如果你有 batch 并发的需求，可以导出 batch=4 甚至更大的固定 batch 模型，但导出的输入 shape 就要固定下来。昇腾对动态 shape 的支持很不理想，要么性能下降，要么干脆转换失败，能固定就固定。

3.2 ATC 转换参数逐项说明

拿到 ONNX 模型后，下一步是 ATC 转换。ATC 全称 Ascend Tensor Compiler，在 CANN toolkit 安装目录下，通常路径是/usr/local/Ascend/ascend-toolkit/latest/bin/atc。

这是我实际使用、验证过能成功转换 YOLOv5s 的命令：

/usr/local/Ascend/ascend-toolkit/latest/bin/atc \ --model=yolov5s.onnx \ --framework=5 \ --output=yolov5s_bs1 \ --input_shape="images:1,3,640,640" \ --input_format=NCHW \ --soc_version=Ascend310P3 \ --precision_mode=allow_mix_precision \ --insert_op_conf=aipp.cfg \ --output_type=FP16

逐个解释这几个参数，因为它们决定了你后面能不能跑、跑得快不快：

• --framework=5：5 表示 ONNX 模型，这个值是固定的。
• --input_shape="images:1,3,640,640"：这里的images是 ONNX 模型输入节点的名称，得先用onnx.load或netron看一下真实名字。YOLOv5 导出的输入名通常会带前缀，直接写images往往不对，要用python -c "import onnx; m=onnx.load('yolov5s.onnx'); print(m.graph.input[0].name)"查一下。
• --soc_version=Ascend310P3：这必须和你的芯片型号对应。npu-smi info能看到芯片型号，转换时填错的话，生成的 OM 在当前设备上基本跑不了。
• --precision_mode=allow_mix_precision：允许混合精度。这个参数很微妙，后面精度排查那节我会详细说。
• --insert_op_conf=aipp.cfg：AIPP 配置，用来自动完成图像预处理，比如 Resize、归一化、减均值。它的好处是能把前处理挪到 NPU 上，省下 CPU 的忙，但配置错了也会让输出面目全非。
• --output_type=FP16：指定模型输出类型为 FP16。后处理时要在 Python 侧做相应转换。

转换成功的标志是当前目录下生成.om文件，并且命令行输出ATC run success。如果报错，常见的有两类：一类是Unsupported op，这说明 ONNX 里有算子 CANN 不支持，优先检查 opset 是否过高；另一类是 shape 不匹配，检查--input_shape是否和 ONNX 的输入节点完全一致。

3.3 精度下降排查：FP16、AIPP 与后处理的锅

我第一版模型转换成功后，跑出来的检测框全在图片左上角堆成一团，置信度也低得离谱。这种"能跑但结果不对"的问题比直接报错还折磨人，因为错误不在异常信息里，而是在数据流里。我排查了很久，最后定位到三个层面，也是你之后一定会遇到的：

第一个层面是 FP16/混合精度。allow_mix_precision模式下，ATC 会把一部分算子自动转成 FP16 以提升性能，但如果模型里有对精度特别敏感的层（比如某些检测头里的 sigmoid、exp 运算），转成 FP16 后精度可能会掉得很厉害。排查方法是先转一个纯 FP32 的 OM 对比：把--precision_mode改成force_fp32，如果 FP32 输出正常而混合精度输出异常，那问题就在精度模式上。这种情况可以考虑把--precision_mode设为force_fp16全模型转 FP16，或者手动指定某些层保持 FP32，但配置起来麻烦，我通常直接选并用实测精度来决定。

第二个层面是 AIPP 的归一化参数不对。这里有个特别隐蔽的坑：训练时你用 PyTorch 的 Normalize 是除以 255再减均值除方差，但 AIPP 配置里crop、mean、norm的顺序和计算方式不一样。如果归一化公式不一致，模型输入分布完全错掉，输出的框就全是乱的。AIPP 配置文件大概是这样的：

[aipp_op] input_format = RGB src_image_size_h = 640 src_image_size_w = 640 mean_chn_0 = 0 mean_chn_1 = 0 mean_chn_2 = 0 var_reci_chn_0 = 0.00392156862745098 var_reci_chn_1 = 0.00392156862745098 var_reci_chn_2 = 0.00392156862745098

记住这里var_reci是方差倒数，不是方差。如果你训练代码用的均值是[0.485, 0.456, 0.406]、方差是[0.229, 0.224, 0.225]，那这里就要填：

mean_chn_0 = 123.675 mean_chn_1 = 116.28 mean_chn_2 = 103.53 var_reci_chn_0 = 0.0171247538316637 var_reci_chn_1 = 0.0175070028011204 var_reci_chn_2 = 0.0174291938997821

单位是像素值，不是 0-1 之间的数。

第三个层面是后处理里没做反归一化。OM 模型输出的是原始检测头张量，你要在 CPU 侧做解码、阈值过滤、NMS。如果模型输出类型是 FP16，在 Python 里直接当成 FP32 解析，数值会完全对不上。需要用np.frombuffer(output, dtype=np.float16).reshape(...)先转成 FP16，再astype(np.float32)。这个问题我在第一版代码里踩得很深。

4. 推理代码实战：用 AscendCL 把 YOLOv5 跑起来

4.1 资源申请与数据流转

环境搞通、模型转换成功，接下来就是写推理代码。昇腾的推理接口是 AscendCL（ACL），从使用者角度看，它解决的核心问题和 CUDA 类似：怎么在 Host（CPU 侧）和 Device（NPU 侧）之间管理内存、怎么做好同步和异步、怎么把模型加载进设备。

你需要理解的第一件事是：NPU 不能直接访问 Host 侧普通内存。你必须先用acl.rt.malloc在 Device 侧申请内存，然后用acl.rt.memcpy把图片数据从 Host 拷到 Device。这一条听起来简单，实际运行时特别容易写成这样的死循环：每次推理都malloc和memcpy，导致大部分时间耗在内存拷贝而不是推理上。

我建议的实践是：如果推理线程是常驻的，就开一个固定的 Device 内存池，输入输出内存提前申请好，推理时只做数据刷新。这样能明显减少延迟。

4.2 推理和后处理分离

第二个要讲清楚的设计决策是：为什么把 NMS 后处理放在 CPU 侧。YOLOv5 ONNX 模型输出的是一组 raw detection tensor，比如输入 640x640，输出就包含 3 个特征层，每个特征层的形状大概是[1, 3, 80, 80, 85]（对应 80x80 格子、3 个 anchor、85 个通道：4 个坐标 + 1 个置信度 + 80 个类别）。后处理要做的就是用这些信息解出 bbox、过滤低置信度框、NMS 去重。

放在 CPU 侧做最大的好处是调试方便。你可以打印每个特征层的数值、可以替换不同的 NMS 实现（比如换成 Soft-NMS、DIoU-NMS）、可以加日志。换个思路，如果你强行要在 NPU 上做 NMS，一是模型转换时要做算子融合，二是出了问题基本黑盒，没法定位。在 YOLO 这种目标数量不多的场景下，CPU 侧后处理的耗时其实可以压到 1-2ms 以内，对整体性能影响不大，所以没必要在这上面找死磕。

4.3 一个最小可跑的推理流程

下面是我调通后的一个最小示例，基于 pyACL 接口，运行前需要提前把 yolov5s_bs1.om 和一张测试图片准备好。省略了部分异常处理，但主干流程完整：

import acl import numpy as np import cv2 # 初始化 acl.init() acl.rt.set_device(0) context, ret = acl.rt.create_context(0) stream, ret = acl.rt.create_stream() # 加载模型 model_path = b"yolov5s_bs1.om" model_id, ret = acl.mdl.load_from_file(model_path) input_size = acl.mdl.get_num_inputs(model_id) output_size = acl.mdl.get_num_outputs(model_id) # 拿模型输入输出的维度信息 input_desc = acl.mdl.get_input_desc(model_id, 0) input_dims = acl.mdl.get_desc_dims(input_desc)[1] # (batch, channels, height, width) batch, channels, height, width = input_dims input_np = np.zeros((batch, channels, height, width), dtype=np.float32) output_desc0 = acl.mdl.get_output_desc(model_id, 0) output_dims0 = acl.mdl.get_desc_dims(output_desc0)[1]

到这里只是搭建好了模型推理的骨架，后面还有几个关键步骤要处理：申请 Device 内存、把预处理好的图片填入输入张量、执行acl.mdl.execute、把输出拿回 Host 侧并做后处理。完整代码较长，我一般会封装成一个YoloDetector类，把初始化、推理、后处理分开，方便在 FastAPI 服务里调用。核心执行的代码长这样：

# 假设已经把图片预处理成 (1,3,640,640) 的 float32 数组，存在 input_np input_tensor, ret = acl.rt.malloc(input_np.size * 4, 2) # 2 表示默认对齐 acl.rt.memcpy(input_tensor, input_np.size * 4, input_np.ctypes.data, input_np.size * 4, 1) acl.mdl.execute(model_id, [input_tensor], [output_tensor0, output_tensor1, output_tensor2])

输出侧三个 tensor 拿回来之后，再按 YOLO 的 decode 逻辑做后处理，这部分和纯 PyTorch 的后处理逻辑完全一致，只是输入的数据类型要注意从 FP16 转出来。我强烈建议你把后处理单独写一个函数，方便用 PyTorch 的原始模型输出做对拍验证。

5. 实测调优：从"能跑"到"跑得快"的几次关键调整

5.1 我的实测数据

我在下面这张表里的数据，来自一台老旧的 Xeon E5 平台，搭配 Atlas 300V 24G，CANN 6.3.RC3，驱动和固件都是配套版本。输入 640x640 的 YOLOv5s FP16 模型，实测单帧时延大约在 8~15ms 之间，折算成吞吐大约是 60~100 FPS。batch=4 时，单帧时延会略微上升，但整体吞吐可以到 150 FPS 以上。注意，这些数字受卡的温度、CPU 后处理耗时、PCIe 通道数影响极大，如果你测出来出入很大，不一定是卡有问题。

说句实在话，这个成绩放在 2024 年的推理卡市场里不亮眼，但结合 24GB 显存、20 多瓦功耗、不用外接供电这些条件，它在"边缘侧多路视频检测"这个细分赛道里算很能打的。

5.2 性能瓶颈定位：别一上来就怪 NPU

如果你跑完一轮 benchmark 觉得速度不理想，我的建议是先用npu-smi info -t proc看芯片利用率，再用 CANN 自带的 profiling 工具看算子耗时。大多数情况下你会发现，真正的瓶颈不在 NPU 算力，而在几个"看不见"的地方：

• 图像预处理：OpenCV 的resize、cvtColor、归一化全在 CPU 上跑，三路视频同时进来，CPU 就跑满了。解决办法是开 AIPP 把预处理挪到 NPU 上，或者用多线程做预处理。
• 内存拷贝：如果每次推理都用acl.rt.malloc新申请内存并在 Host/Device 间搬数据，内存拷贝耗时可能超过 NPU 推理耗时。
• 后处理：NMS 如果用纯 Python 循环写，目标数量一多，后处理耗时能到几十毫秒。优化办法是向量化实现或者用 NMS 的 C 扩展。

这些都是工程优化，不是模型优化，但因为"NVIDIA GPU 上从来没人提这些"，很多从 CUDA 迁过来的人会忽略，白白浪费了 NPU 的性能。

5.3 具体优化手段

我的优化顺序是：先开 AIPP，再做 Stream 并行，再考虑固定 batch。

AIPP 开启后，图像预处理从 CPU 移到 NPU。原本 OpenCV 的 Resize + Norm 大约要 3~5ms，放到 NPU 上几乎是微秒级，整体延迟肉眼可见地下降。AIPP 的配置要和训练时的预处理对齐，这一节前面说过，不再重复。

Stream 并行是昇腾上提升多路吞吐的利器。你可以为每一路视频创建一个独立的 Stream，多个 Stream 各自执行acl.mdl.execute。由于 NPU 本身就是并行架构，多个 Stream 的执行时间和单个 Stream 差不多，而 CPU 侧的内存拷贝和后处理也能在不同线程里异步进行。用 ThreadPool 开 4 个推理线程，配合 Stream，4 路视频同时推理的总吞吐比串行快得多。

固定 batch 的优化建议是：如果业务能接受把多路请求合并成 batch=4 或 batch=8 再推理，吞吐提升非常明显。这有点类似 Triton 的 dynamic batching。昇腾对动态 shape 支持不好，所以你需要在上层自己做请求排队和聚合，达到一定数量后统一推理。单张卡 24GB 显存，跑 batch=8 的 YOLOv5s 完全没有内存压力，但要注意预留后处理的时间，别为吞吐牺牲掉单帧延迟。

6. 关于这张卡，我最后想说的几句实际体验

折腾了几天之后，我的真实体感是：Atlas 300V 24G 确实是一张推理加速卡，而且在功耗、尺寸、部署形态上，它比同价位的 NVIDIA GPU 更贴近边缘业务场景。但它的入门门槛不低，版本配套、算子兼容、模型转换链路都需要专门学习，这和 CUDA 生态的"开箱即用"完全不是一个概念。

如果你决定入坑，我给你三条建议。第一，严格按官方兼容性列表配版本，别贪新，稳定压倒一切；第二，所有模型转换都在小数据集上做精度对拍，千万不要相信"转出来没问题就是没问题"，框位置不对、置信度不对都是常见的事；第三，遇到算子不支持或者性能不达标，先检查自己的版本和对齐参数，再怀疑卡和硬件，不要在一个错误版本上反复纠结。

这篇就是我从零到上线踩坑的全过程。你可以把这篇文章当一份路线图，也可以当一份避坑清单。真到了自己上手的时候，照着这个链路走一遍，你遇到的大部分问题应该都能在前面找到影子。