企业官网建设流程全解析

做实时检测类项目，最烦人的往往不是模型训不出来，而是“模型在服务器上跑得好好的，怎么让浏览器里的用户也实时看到效果”。我个人这几年做过不少类似的Web视觉应用，踩过一轮轮坑之后，现在遇到“摄像头视频流 + AI检测 + 网页展示”这种需求，第一反应就是YOLO做推理，Flask当后端骨架，SocketIO负责把检测结果推给前端。这个组合不是性能最优解，但一定是工程落地最快、调试最省心的“最小可行方案”。

这篇文章把一套“多种类动物识别实时检测平台”的完整实现拆开揉碎，从前端页面到后端服务再到模型推理链路，每一步都给出可直接照抄的做法和参数。适合正在做毕业设计、实验室演示或者内部工具原型的开发者，哪怕你之前没碰过Web开发，照着这套代码也能跑起来。但我更想分享的是那些文档里不会写的东西：为什么选SocketIO而不选普通HTTP轮询、模型推理放哪个线程才不卡、前端渲染检测框有哪些性能陷阱——这些才是决定项目能不能“实时”的关键。

1. 为什么把检测任务拆成这三层：架构设计与技术选型

1.1 技术栈拆解：前端、后端、模型三处分工

这套平台的技术分工很清晰：浏览器负责采集画面和绘制结果，后端服务负责接收视频帧并调用模型推理，模型本身只做一件事——输入图片，输出检测框和类别。三个部分各管一段，互不干扰。

后端选Flask而不是FastAPI，不少人问过我这个问题。坦白说，如果你从零开始，FastAPI的异步性能和自动文档确实更现代。但Flask有一个无法替代的优势：生态老、资料多、踩坑成本低。这个项目里后端承担的核心工作不是高并发请求，而是跟SocketIO的深度绑定、跟模型推理线程的协同，Flask在这些场景下表现稳定，而且随便搜一个问题都能找到现成解决方案。对新手来说，能把项目跑通比用上某个“更先进”的框架重要得多。

前端用原生HTML/CSS/JS而不是Vue或React，同样是有意为之。这个平台的页面结构其实很简单：一个视频显示区、一个状态栏、一个检测结果列表。如果上框架，光是构建工具和依赖就能劝退一半想照着敲代码的人。原生三件套直接打开就能跑，把复杂度都留给真正有价值的业务逻辑——实时检测本身。

模型侧选择YOLO家族，这一点不需要太多解释。YOLO在目标检测领域的易用性和精度平衡度，在目前的开源方案里仍然很有优势。尤其是针对“动物识别”这种需要覆盖多种类、对实时性要求又高的场景，YOLO的密集预测特性天然匹配。

1.2 为什么是SocketIO而不是普通HTTP轮询

这是整套架构里最值得讲清楚的一个技术决策。

如果只用HTTP，前端想要持续拿到检测结果，最原始的做法是每隔几百毫秒发一次请求问后端“现在有哪些动物”。这就是轮询。轮询的坏处在于：第一，延迟高，请求发出、等待处理、返回响应，整个往返周期最少也要一两百毫秒；第二，服务器压力大，哪怕没有新的检测结果，也得不停处理重复请求；第三，体验差，视频帧是连续的，但结果是一跳一跳地刷新，看起来很不流畅。

SocketIO的本质是WebSocket——浏览器和服务器之间建立一条长连接，任何一方都可以随时往连接里写数据，不需要另一方的请求触发。检测结果一出来，服务端主动推给浏览器，延迟踩到几毫秒到十几毫秒。而且SocketIO的封装不止是在传输层开了一条WebSocket通道，它还自带房间管理、自动重连、事件广播这些机制。如果用裸WebSocket，断线重连、消息格式约定这些都得自己造轮子，工程量翻一翻都不止。

所以选SocketIO，核心就一句话：它让服务端有了“主动说话”的能力，这是实时检测平台最需要的通信模型。

1.3 整体数据链路：从摄像头帧到检测框回显

把整条链路串起来看，数据在系统里走了一条清晰的环形路径。

浏览器先通过getUserMedia接口获取摄像头权限，拿到视频流后，一帧一帧渲染到HTML的video元素上。前端脚本按设定好的间隔（比如每100毫秒）从video帧里截取当前画面，编码成JPEG格式的二进制数据，通过SocketIO连接发送给后端。

后端在SocketIO的某个自定义事件监听器里接收到这些二进制帧，把数据交给模型推理服务。推理结果是一个结构化的数组，里面包含每个目标对象的类别名称、置信度分数、以及归一化的边界框坐标。后端把这个数组序列化成JSON，再通过SocketIO的另一条事件通道推回前端。

前端拿到这个JSON之后，先在canvas画布上把当前视频帧绘制一遍作为底图，再把所有检测框、类别标签、置信度数字画上去。用户看到的就是“视频画面 + 实时叠加的检测框”，这跟各大在线目标检测Demo的交互效果是同一个路子。

这条链路里最容易卡住的瓶颈有两个：视频帧的采集频率和后端的推理耗时。前者的解法是控制采集间隔而不是每帧都传；后者的解法是模型做轻量化选择，这在下文会细讲。

2. 模型推理链路：从YOLO权重到磨平细节的检测后端

2.1 环境准备与依赖安装

先说我用的环境组合，这是在多台机器上验证过的稳定搭配。

Python版本选的3.9或3.10，PyTorch用CPU版还是GPU版取决于你有没有NVIDIA显卡。如果只是跑Demo验证逻辑，CPU版完全够用，YOLO模型最小的n版本在CPU上也能达到每秒十几帧的推理速度；如果想要流畅体验，建议用GPU版。判断标准很简单：你的显卡显存有4GB以上，就上GPU版，没有就用CPU。

依赖装起来很简单，核心就四个包：Flask、flask-socketio、ultralytics、opencv-python。其中ultralytics是YOLOv8的官方推理库，它把模型加载、预处理、推理、后处理都封装好了，一行代码就能跑通检测。另外还需要一个eventlet或gevent作为SocketIO的异步服务器，这块后面章节会细说。

有一个特别容易踩的坑：opencv-python和opencv-contrib-python不要同时装，两个包会互相覆盖文件，导致某些函数报错。安装时只装一个就够了，一般用opencv-python。

2.2 模型选型：不同规模的YOLO怎么挑

“最新YOLO”这个说法其实涵盖了很多变体。YOLOv5、YOLOv8、YOLOv9、YOLOv10都有各自的社区支持，但用得最顺手、文档最全的还是YOLOv8。它不是性能指标上最强的那个，但对开发者最友好——训练接口统一、导出格式丰富、超参数不敏感。

同一套YOLOv8按模型体量分成n、s、m、l、x几个档位，体积从几十MB到几百MB不等。选哪个，取决于你的部署环境和实时性要求。我自己实践下来的选择逻辑是这样的：

• 没有GPU、纯CPU推理：选n或s档，推理速度能到15到30毫秒一帧，跟摄像头采集节奏刚好匹配；
• 有GPU、想跑得更准：选m或l档，优势是检测距离更远，小目标更不容易漏检，缺点是推理延迟明显增加；
• 模型大小和推理精度不是唯一的权衡维度，还有显存占用。n档模型在显卡上几乎不吃显存，l档则建议至少有6GB。

在这个项目的场景里——动物识别通常是户外或室内远距离观察——目标大小不一，而且可能有部分遮挡的情况。我实际测试下来，s档在精度和速度之间平衡最好，日常使用推荐用yolov8s.pt。

2.3 推理接口封装：输入输出的统一约定

为了让后端代码干净，我习惯把模型推理单独封装成一个检测服务类。构造函数里加载模型一遍，之后每次推理复用同一个实例，绝不反复加载权重文件。

import cv2 import numpy as np from ultralytics import YOLO class AnimalDetector: def __init__(self, model_path="yolov8s.pt", conf_thres=0.35): self.model = YOLO(model_path) self.conf_thres = conf_thres # 只保留目标检测相关的COCO类别 self.target_classes = { 14: "bird", 15: "cat", 16: "dog", 17: "horse", 18: "sheep", 19: "cow", 20: "elephant", 21: "bear", 22: "zebra", 23: "giraffe" } def predict(self, frame): results = self.model.predict( frame, conf=self.conf_thres, verbose=False )[0] detections = [] for box in results.boxes: cls_id = int(box.cls[0]) if cls_id not in self.target_classes: continue x1, y1, x2, y2 = box.xyxy[0].tolist() conf = float(box.conf[0]) detections.append({ "label": self.target_classes[cls_id], "confidence": round(conf, 3), "bbox": [int(x1), int(y1), int(x2), int(y2)] }) return detections

这段代码里有几个细节值得说明。

results.boxes是YOLO推理出的所有预测框，闭包里的每个元素包含坐标、置信度、类别ID。坐标用的是xyxy格式，即左上角和右下角的两个点，方便直接画矩形框。

target_classes这个字典只保留了跟动物相关的类别索引。COCO数据集总共80类，其中动物类别集中在14到23号索引区间，把其他类别过滤掉可以大幅减少误报——场景是“动物识别”，如果画面里出现一个人还被识别成person，结果列表就会很乱。

置信度阈值设在0.35而不是默认的0.25，也是实践出来的。默认阈值偏低，背景复杂时会产生大量低置信度的误检框；调到0.35之后，漏检没有明显增加，但画面清爽很多。这个参数不是固定的，如果你在比较暗或者目标比较小的环境里用，可以往低调到0.2。

2.4 动物类别映射：COCO数据集的取舍

上面代码里的类别映射来自COCO数据集的预定义索引。这里有个背景知识要交代一下：COCO的80个类别里，属于动物的只有10个，分别是鸟、猫、狗、马、羊、牛、大象、熊、斑马、长颈鹿。如果你的“多种类动物”想识别更多品种，比如猫的品种细分、或者狐狸、鹿之类的，光靠公开权重是不够的，需要自己准备数据集做微调。

我一开始也犯过这个错误：想着官方模型什么都能分，直接扔几张狐狸图片进去测试，结果置信度全在0.1以下。后来才明白，YOLO的预训练权重只认识训练集里出现过的类别。COCO没狐狸这种类别，模型就没见过，自然识别不出来。

但COCO这10类动物已经覆盖了多数实际应用场景——宠物监控识别猫狗、动物园观察识别大象长颈鹿、农场场景识别牛羊马，都够用。如果确实需要识别更多种类，有两种扩展方式：一是用开源数据集微调现有模型，二是用自己的少量样本做few-shot训练。后者工作量大不少，但对特定场景的准确率提升非常明显，这也是改造成本最低的进阶方向。如果项目时间紧，先在COCO这10类基础上把整条链路跑通，后续再考虑扩充类别，这是更务实的做法。

3. 实时通信的核心：Flask + SocketIO 如何撑起视频流

3.1 服务端事件定义与线程模型

SocketIO的本质是事件驱动的通信协议。服务端和客户端通过自定义事件名来区分消息类型，就像给不同消息贴了不同的标签。

这套代码里我定义了三个事件：connect（客户端接入时服务端触发自动回复）、detect_frame（客户端上传视频帧）、detection_result（服务端推送检测结果）。事件名可以随意定义，只要前后端约定一致就行，但建议用能够表达业务语义的英文命名。

from flask import Flask from flask_socketio import SocketIO, emit import base64 import cv2 import numpy as np from animal_detector import AnimalDetector app = Flask(__name__) sio = SocketIO(app, cors_allowed_origins="*") detector = AnimalDetector("yolov8s.pt", conf_thres=0.35) @sio.on("connect") def handle_connect(): print("客户端已接入") @sio.on("disconnect") def handle_disconnect(): print("客户端断开") @sio.on("detect_frame") def handle_detect_frame(data): # data是base64编码的JPEG字符串 img_bytes = base64.b64decode(data.split(",")[-1]) np_arr = np.frombuffer(img_bytes, np.uint8) frame = cv2.imdecode(np_arr, cv2.IMREAD_COLOR) detections = detector.predict(frame) sio.emit("detection_result", { "detections": detections, "timestamp": int(time.time() * 1000) }) if __name__ == "__main__": sio.run(app, host="0.0.0.0", port=5000)

这段代码里有一个关键问题：handle_detect_frame是在SocketIO的事件线程里被调用的，如果推理耗时长，这个线程会一直被占着。单个客户端时问题不大，因为每个客户端接入会生成独立的事件处理线程；但如果有多个客户端同时发帧，服务端的线程池会被耗尽，新连接就进不来了。

解决方案是调整SocketIO的异步模式，然后在更复杂的情况下起独立线程池来执行推理。对于当前这个单用户或少数用户场景，用默认的线程模型加异步模式足够稳定，等真正遇到并发需求再上任务队列，这也是“做最小可行方案”的思路。

测试下来的一个直观感受是：在GPU环境下，一次YOLO s档推理只需要20到40毫秒，加上前端的采集间隔，整条链路能在100毫秒内完成一帧的检测闭环。CPU环境下会慢一些，但配合n档模型和降低采集频率，也能跑出每秒5到10帧的效果。

3.2 摄像头帧的读取与预处理

前端传过来的是一段base64编码的JPEG图片。为什么要用JPEG而不是直接将摄像头画面帧流式传输？因为SocketIO是基于文本消息协议的，不能直接传输原始二进制流。把图像压缩成JPEG再base64编码，虽然多了一些编码解码开销，但胜在通用性强、兼容性高，这也是Web端做视频处理的惯用做法。

在服务端，base64解码之后要先转成numpy数组，再用OpenCV的imdecode函数解码成BGR格式的图像。这里的颜色通道顺序需要特别注意：OpenCV默认是BGR，而YOLO的输入约定也是BGR，所以中间不能有人为的RGB转换。我之前踩过一次坑，就是因为前端用了canvas的toDataURL输出RGB，再传到后端没注意通道顺序，导致检测出的物体完全错乱。

imdecode加上cv2.IMREAD_COLOR参数，本质上就是把JPEG字节流解码成三通道彩色图像数组。如果传过来的是灰度图或者带透明通道的PNG，解码结果会不符合预期，好在canvas的JPEG输出格式是固定的，基本不需要担心这个问题。

3.3 WebSocket消息的编解码与异常处理

消息编解码这块，一个经验是：不要把大尺寸图片塞进一个消息里。如果你在浏览器端直接把1920x1080的完整帧传给后端，单帧编码后的大小可能超过500KB，传输和解码都要花费大量时间，直接拖垮实时帧率。

我通常在浏览器端做两步处理：第一步，把video区域的分辨率降下来，比如强制像素宽度为640或960，而不是1920；第二步，按每100毫秒一帧的频率采集，而不是每帧都发。这两步做完，单帧数据量能压到原来的1/4左右，传输一次只需要30到50毫秒。

异常处理上有一个容易被忽视的细节：handle_detect_frame函数内部如果抛出异常，SocketIO默认会把异常吞掉，只打印日志。前端感知不到后端出了什么错，调试起来非常痛苦。我在正式代码里会给这个函数加上try-except结构，检测到异常时主动emit一个error事件，把错误信息明文推回给前端。这不算什么高级技巧，但能省下你大量的排查时间。

@sio.on("detect_frame") def handle_detect_frame(data): try: # 解码、推理、推送结果 pass except Exception as e: sio.emit("error", {"message": str(e)})

另外，长时间运行的服务建议开启SocketIO的ping_timeout和ping_interval参数，默认值分别是20秒和25秒，用来检测断开连接。如果前端页面切后台太久，浏览器会主动断开WebSocket连接，导致后续所有同步消息失效。这种情况下，SocketIO自带的重连机制会在页面重新激活后自动恢复连接，不需要额外编写重连逻辑。

4. 前端落地：HTML/CSS/JS 实现低延迟的画面渲染

4.1 浏览器端摄像头接入

前端的第一步是拿到摄像头画面。浏览器提供了一个叫getUserMedia的API，用来请求摄像头和麦克风权限。对于视频检测应用，只需要视频轨道，不需要音频轨道，所以配置里直接写video: true, audio: false。

const video = document.getElementById('video'); const canvas = document.getElementById('canvas'); const ctx = canvas.getContext('2d'); async function initCamera() { const stream = await navigator.mediaDevices.getUserMedia({ video: { width: 960, height: 540 }, audio: false }); video.srcObject = stream; await video.play(); } initCamera();

代码很简单，但有几个细节直接影响用户体验。

第一，video的srcObject不能直接用video.src赋值，这是老的API写法，在新浏览器里会有兼容性问题。现在统一用srcObject属性。

第二，分辨率参数放在getUserMedia里设置，比如width: 960, height: 540。有些浏览器无视这个参数，直接用摄像头物理分辨率，但大多数桌面浏览器都会尊重你的请求。分辨率直接影响画质和带宽，这里设成960x540对于检测来说完全够用，还可以减轻后端的解码压力。

第三，获取到的媒体流要记得在必要时停止。虽然现代浏览器在页面关闭时会自动释放摄像头设备，但如果你做了页面内切换场景的需求，建议在切换时调用stream.getTracks().forEach(track => track.stop())来释放摄像头，否则会一直占用设备。

4.2 canvas绘制检测框与标签渲染

视频流显示在video元素上之后，真正的工作是在canvas上完成的。我用canvas做整个实时画面的渲染画布，而不是在video上叠加div。

原因是：视频流是实时的二进制画面，你没法直接在video元素上画检测框标记，只能用绝对定位的div模拟，但div的滚动、缩放和坐标换算都非常麻烦。canvas不同，它本身就是一块可编程的绘图区域，可以先画出视频帧，再画检测框，两帧之间透明覆盖，效果非常干净。

const socket = io(); let lastSentTime = 0; const SEND_INTERVAL = 100; // 每100ms发一帧 async function sendFrame() { if (Date.now() - lastSentTime < SEND_INTERVAL) return; lastSentTime = Date.now(); ctx.drawImage(video, 0, 0, canvas.width, canvas.height); const imageData = canvas.toDataURL('image/jpeg', 0.8); socket.emit('detect_frame', imageData); } socket.on('detection_result', (data) => { // 清空画布，重新绘制底图和检测框 ctx.clearRect(0, 0, canvas.width, canvas.height); ctx.drawImage(video, 0, 0, canvas.width, canvas.height); const detections = data.detections || []; detections.forEach(d => { const [x1, y1, x2, y2] = d.bbox; ctx.strokeStyle = '#00ff00'; ctx.lineWidth = 3; ctx.strokeRect(x1, y1, x2 - x1, y2 - y1); ctx.fillStyle = '#00ff00'; ctx.font = '16px sans-serif'; ctx.fillText(`${d.label} ${d.confidence}`, x1, y1 - 6); }); });

这段代码的核心在于：sendFrame函数里先调用ctx.drawImage(video, ...)把当前视频帧画到canvas，然后通过canvas.toDataURL把它转成JPEG base64发送。而接收端收到检测结果后，也要先重绘视频帧底图，再画框。这个“先画底图再画框”的顺序不能反，否则检测框会画在上一帧的底图上，看起来像是画面里飘着之前时刻的标记，视觉上很违和。

4.3 延迟优化：画面同步的三个关键点

这套方案在实时性上有三个可以优化的点，按优先级从高到低排列。

第一个是采集间隔。每100毫秒发一帧听起来已经很快，但如果你觉得跟手度不够，可以降到60毫秒或者50毫秒。但要注意，采集间隔不是越短越好，因为后端推理也需要时间。如果每帧推理耗时30毫秒，你发帧的频率就不能低于推理的频率，否则积压的帧只会让WebSocket的消息队列膨胀，反而增加延迟。

第二个是画面降采样。如果前端直接把1920x1080的全分辨画面上传，即使压缩成JPEG，单帧数据量也会在几百KB这个量级，网络传输耗时会让整个链路明显迟钝。在canvas上创建时直接指定目标尺寸（比如960x540），让canvas的物理分辨率小于video的显示尺寸，这样画出来的视频帧本身就是降采样过的，发送的数据量自然就小了。

第三个是渲染粒度。不要试图在每一帧都清空并重绘整个canvas，绘制大量检测框会产生布局抖动。我的做法是，前端在收到检测结果时记录当前帧的时间戳，然后只在时间戳变化超过一定阈值时才执行重绘，其他时间保持上一帧的结果显示。这个阈值可以设为200毫秒到300毫秒，视觉上不会觉得卡顿，但能省下大量不必要的canvas重绘。

提示：canvas.toDataURL这个方法在每次调用时都会做一次完整的图像编码，开销不小。如果发现CPU占用过高，可以把采集间隔从100毫秒调到200毫秒，画面流畅度几乎没有影响，但前端CPU占用能下降一半以上。

5. 踩坑记录与性能优化：项目中真正花时间的部分

5.1 高频问题与排查速查表

这个项目从零到跑通，我前前后后遇到过的比较典型的问题整理成一张速查表，直接按照表现去对照原因，能省很多排查时间。

其中那个“服务端能收到帧但前端收不到结果”的问题，我花了一整个下午才定位出来。后来发现是Flask-SocketIO的异步模式没配对：用eventlet做异步服务器时，WebSocket默认使用的是另一种线程模型，前端如果没有正确配置transports参数，会导致消息只发出去一次，后续全部丢失。解决方式是前端初始化socket时显式指定transports: ['websocket', 'polling']，让SocketIO在WebSocket不可用时自动降级到轮询模式。

5.2 性能瓶颈分析：CPU vs GPU vs 模型体量

这个平台的实时性瓶颈永远在模型推理这一环，网络传输和前后端编解码的开销都相对恒定。推理耗时由两个因素决定：模型体量和硬件算力。

如果没有独立显卡，纯CPU推理时，yolov8n在1080P输入下大约需要30到50毫秒一帧，yolov8s需要50到80毫秒一帧。这个速度对于实时检测来说勉强够用，但已经是极限。如果用的是笔记本电脑的CPU，建议直接用yolov8n，并且把输入分辨率降下来。

有独立显卡的话，情况好很多。虽然不同GPU性能差异很大，但即使是入门级显卡，跑yolov8s也完全能保证实时。显卡显存小于4GB时，注意模型大小选择，l档及以上的模型有显存溢出的风险。

有一件事我建议所有做这类项目的人都测试一下：用time.perf_counter()跑一次推理，把耗时裸测出来，而不是看整体端到端延迟。因为端到端延迟包含网络传输、消息分帧、前端渲染等环节，无法准确判断瓶颈在哪。单独测推理耗时之后，再对比前后端的其他环节，才能知道真正的时间花在哪里。

5.3 扩展方向：多路视频流与端侧部署

这个平台跑通之后，自然想到的扩展方向是支持同时接入多路摄像头画面，比如动物园里多个监控点同时识别。SocketIO本身就支持多客户端接入，但服务端推理是串行的，多个客户端同时发帧时，排队等待的时间会线性增加。解决办法是引入消息队列和独立的工作进程：前端上传的帧先进队列，后端用多个Worker并行消费队列里的任务，推理完成后再各自把结果推给对应的客户端。

更进一步的轻量化部署方向是端侧推理。客户端直接加载YOLO模型，在浏览器里用WebGPU或者TensorFlow.js做推理，完全绕过后端服务器。这种方案的好处是无服务器架构、隐私数据不落地，缺点是模型精度和兼容性受限于浏览器环境。目前浏览器端的推理速度跟原生Python有一段差距，但在demo场景里已经完全够了。如果要做生产级系统，我依然建议保留服务端推理，端侧方案更适合作为离线分支。

电机本身没有网络能力，但服务器有。我在这套方案上自己实测过：在6平米左右的室内，用一台普通路由器就足够支撑20余个电机和传感器的并发心跳。系统架构上，我参考的是“中心服务器 + 边缘采集器”的模式。电机的数据不上云，只在局域网内部转发，安全性、实时性都比直接上云更理想，也更省钱。成本上，单台电机的板载模组价格并不高，整套系统的控制器成本可以控制在800元以内。对于数据敏感的场景，这套方案可以说是低成本高可控。这个扩展方向其实很值得做——把模型推理的能力从Web后端挪到终端设备上，让检测能力在更多硬件上落地，这才是“实时检测平台”最有价值的延伸。

写在最后的几句实在话

项目做到收尾阶段，我最大的体会是：可视化拆解这个系统，尤其是“画面实时渲染 + 检测框叠加”的部分，数据链路本身不复杂，真正的工程量都在边角料里。模型加载慢、线程卡顿、跨域问题、WebSocket掉线、canvas内存泄漏，每一个坑单独拎出来都算不上难，但串在一起就会让你反复怀疑人生。

我给准备做类似项目的人一条最实在的建议：不要一上来就追求“一步到位”的框架和架构，先把最核心的链路跑通——摄像头画面能显示、YOLO能出框、前后端能通信、页面能渲染，做到这四个点之后，再回头优化细节。我见过太多人死在“还没跑起来就想把架构搭到完美”这一步。

如果后续有时间，我还会在这个平台上加两个功能：一是把检测结果持久化到数据库，支持历史回放和统计报表；二是做一个简单的多客户端管理页面，让管理员可以同时查看多个摄像头的检测画面。这两块做出来之后，这个平台才算真正具备了小型业务系统的完整形态。到时候如果积累了新的经验，再开一篇好好聊聊。