企业官网建设流程全解析

1. 项目缘起与整体设计思路

1.1 为什么会有这个需求

手里攒了几块树莓派，从早期的3B+到后来的4B、5都有，摄像头模块也买了好几个，OV5647、IMX219、IMX477这些都用过。最开始的想法很简单：树莓派接上摄像头，当个网络监控用，但市面上现成的方案要么功能太重，要么延迟高得离谱，要么就是画质被压缩得没法看。后来琢磨着自己用Python写一套，核心诉求就三个：低延迟、可定制、能跨设备。

这个项目的本质，是把树莓派上的摄像头采集到的画面，通过局域网实时传输到PC端显示或处理。听起来像是“视频推流”，但实际做下来你会发现，它跟传统的RTMP推流、RTSP拉流完全不是一回事。RTMP那套东西延迟动辄两三秒起步，而且需要额外的流媒体服务器；RTSP虽然延迟低一些，但配置复杂，调试起来让人头大。用Python加picamera这套组合，走的是原始数据直传的路子，延迟可以压到100毫秒以内，而且代码量极少，几百行就能跑起来。

适合谁来参考这个方案？如果你手头有树莓派和摄像头模块，想做一个低延迟的远程画面查看工具，或者想把树莓派的摄像头画面接入到PC上的OpenCV做实时图像处理，再或者你想给树莓派小车加个“眼睛”，这个方案都能直接拿来用。不需要你精通网络编程，只要会基本的Python语法，照着步骤走就能跑通。

1.2 方案选型的几个关键决策

在动手之前，我对比了几种常见的实现路径，这里把选型逻辑说清楚，方便你根据自己的场景做取舍。

方案一：HTTP MJPEG流。这是最简单的方式，树莓派端起一个HTTP服务，把每一帧编码成JPEG，用multipart/x-mixed-replace的方式推给客户端。优点是浏览器直接就能看，不需要额外客户端；缺点是延迟不稳定，而且每帧都要独立编码，CPU占用不低，画质和帧率很难兼顾。

方案二：RTSP + FFmpeg。树莓派端用FFmpeg把摄像头数据推成RTSP流，PC端用VLC或者OpenCV拉流。优点是生态成熟，工具多；缺点是FFmpeg在树莓派上跑起来资源消耗大，而且RTSP的握手和缓冲机制会引入额外延迟，调优空间有限。

方案三：Python Socket直传。树莓派端用picamera采集原始帧，通过TCP Socket直接发送到PC端，PC端接收后解码显示。优点是延迟极低、完全可控、代码透明；缺点是需要自己处理粘包、帧同步、网络抖动这些问题。

我最终选了方案三，原因很直接：这个项目的核心场景是局域网内的实时画面传输，不需要跨公网，不需要兼容各种播放器，要的就是快和可控。Socket直传虽然要自己写一些底层逻辑，但一旦跑通，后续想加什么功能都方便，比如在PC端做目标检测、人脸识别，或者把画面转发到其他设备。

注意：如果你需要跨公网访问，这个方案需要额外考虑网络穿透和数据加密的问题，不在本文讨论范围内。本文聚焦局域网场景。

1.3 整体架构长什么样

整个系统分两端：树莓派端（服务端）和PC端（客户端）。

树莓派端负责三件事：初始化摄像头、采集视频帧、通过TCP Socket发送数据。PC端负责三件事：连接树莓派、接收数据、解码并显示画面。

数据流向是这样的：picamera采集到一帧原始数据（通常是YUV或RGB格式），经过JPEG编码压缩后，加上一个简单的帧头（包含帧长度信息），通过Socket发送出去。PC端收到数据后，先读帧头拿到帧长度，再按长度读取完整的帧数据，解码成numpy数组，最后用OpenCV显示出来。

这里有个关键设计：为什么要在树莓派端做JPEG编码，而不是传原始数据？算一笔账就明白了。假设分辨率是640x480，RGB888格式，一帧数据是640×480×3 = 921600字节，约900KB。按30帧每秒算，带宽需求是27MB/s，也就是216Mbps。千兆局域网勉强能跑，但WiFi就完全扛不住了。而JPEG编码后，同样分辨率下每帧大概30-50KB，带宽需求降到1MB/s左右，WiFi轻松应对。虽然编码会消耗一些CPU，但树莓派的GPU有硬件编码单元，picamera可以直接调用，实际开销很小。

2. 核心细节解析与实操要点

2.1 硬件准备与系统环境

先把手头的东西理清楚。硬件方面，你需要：

• 树莓派一块（3B+、4B、5都可以，Zero 2 W也能跑，但性能有限）
• 摄像头模块一个（OV5647、IMX219、IMX477都行，注意排线方向）
• PC一台（Windows、Linux、macOS都可以）
• 局域网环境（树莓派和PC在同一网段）

软件方面，树莓派端需要：

• Raspberry Pi OS（Bullseye或Bookworm版本）
• Python 3.7以上
• picamera2库（注意：Bullseye之后官方推荐用picamera2替代老的picamera）
• OpenCV（可选，用于图像处理）

PC端需要：

• Python 3.7以上
• OpenCV（pip install opencv-python）
• numpy

这里要特别说明一下picamera和picamera2的区别。老的picamera库基于Broadcom的MMAL接口，在Bullseye之前的系统上工作得很好，但在新系统上已经不再维护。picamera2是官方新推出的库，基于libcamera，支持更新的硬件和系统。如果你用的是Raspberry Pi OS Bullseye或更新版本，建议直接用picamera2。本文的代码会以picamera2为主，但核心思路对两个库都适用。

实操心得：摄像头排线插反是新手最容易犯的错误。排线的金属触点朝向要看清，树莓派端的接口是掀开卡扣插入排线，摄像头端的接口也是类似操作。插好后轻轻拉一下排线，确认卡住了再通电。如果通电后摄像头没反应，先检查排线，再检查系统里有没有识别到设备。

2.2 摄像头初始化与参数调优

picamera2的初始化流程比老picamera稍微复杂一点，但灵活性更高。核心步骤是：创建Picamera2对象、配置视频流参数、启动摄像头。

from picamera2 import Picamera2 import time picam2 = Picamera2() config = picam2.create_video_configuration( main={"size": (640, 480), "format": "RGB888"}, controls={"FrameRate": 30} ) picam2.configure(config) picam2.start() time.sleep(2) # 等待摄像头稳定

这段代码里几个参数值得细说。size决定了分辨率，640x480是延迟和画质的平衡点，如果你需要更高清的画面，可以上到1280x720，但延迟会相应增加。format指定了像素格式，RGB888方便后续处理，但如果你只做传输，YUV420格式数据量更小。FrameRate控制帧率，30帧是流畅的底线，再低就会有明显的卡顿感。

实际调试时，我发现曝光和白平衡对画面质量影响很大。树莓派的摄像头默认是自动曝光和自动白平衡，在光线变化不剧烈的场景下没问题，但如果你要做颜色识别或者目标检测，最好手动锁定这些参数。picamera2里可以通过controls参数设置：

controls = { "FrameRate": 30, "ExposureTime": 10000, # 微秒 "AnalogueGain": 2.0, "AwbEnable": False, "ColourGains": (1.5, 1.2) }

ExposureTime和AnalogueGain需要根据实际光照调整，没有万能值。我的经验是，室内日光灯环境下，ExposureTime设在8000-15000微秒之间比较合适，AnalogueGain在1.5-3.0之间。ColourGains的两个值分别对应红和蓝的增益，需要对着白色物体调，直到画面不偏色为止。

2.3 网络传输协议的设计

Socket传输最怕的就是粘包和拆包。TCP是流式协议，不保证每次recv收到的数据边界和send时一致。比如你发了三帧数据，每帧50KB，接收端可能第一次recv收到80KB，第二次收到70KB，完全打乱了帧的边界。

解决办法是自定义帧头。每帧数据发送前，先发一个固定长度的帧头，里面包含帧的长度信息。接收端先读固定长度的帧头，解析出帧长度，再按这个长度读取完整的帧数据。

帧头的设计很简单：4个字节的unsigned int，用struct.pack打包。

import struct def send_frame(sock, frame_data): # 先发帧长度 header = struct.pack("!I", len(frame_data)) sock.sendall(header) # 再发帧数据 sock.sendall(frame_data)

接收端对应地先读4个字节，解析出长度，再循环读取直到收满。

def recv_frame(sock): header = recv_exact(sock, 4) if not header: return None frame_len = struct.unpack("!I", header)[0] frame_data = recv_exact(sock, frame_len) return frame_data def recv_exact(sock, n): data = b"" while len(data) < n: packet = sock.recv(n - len(data)) if not packet: return None data += packet return data

这个设计看起来简单，但实际跑起来非常稳。我试过连续跑几个小时，没有出现过帧错位的情况。关键点在于sendall和recv_exact的配合，sendall保证数据全部发出，recv_exact保证数据全部收齐。

注意事项：帧长度用4字节unsigned int，最大支持4GB的帧，实际使用中远远够用。但如果你要传超大分辨率的数据，可以考虑用8字节。另外，网络字节序用"!I"表示大端序，两端保持一致就行。

2.4 JPEG编码的质量与速度权衡

树莓派端采集到的原始帧是RGB或YUV格式，数据量大，必须压缩后再传输。JPEG是最常用的选择，因为编码速度快、压缩比高、解码端支持好。

picamera2可以直接输出JPEG格式，但那样会失去对原始帧的控制。我的做法是采集RGB帧，然后用OpenCV的imencode做JPEG编码。

import cv2 import numpy as np def encode_frame(frame, quality=80): # frame是numpy数组，shape为(height, width, 3) encode_param = [int(cv2.IMWRITE_JPEG_QUALITY), quality] result, encoded = cv2.imencode(".jpg", frame, encode_param) if not result: return None return encoded.tobytes()

quality参数控制压缩质量，范围0-100。80是一个很好的平衡点，画质肉眼几乎看不出损失，但数据量比quality=95小了将近一半。我实测过，640x480分辨率下，quality=80时每帧大约25-35KB，quality=95时每帧大约50-70KB。对于局域网传输来说，这点带宽差异无所谓，但如果你用WiFi或者网络状况不好，降低quality能明显改善流畅度。

还有一个优化点：树莓派的CPU编码和GPU编码。OpenCV的imencode用的是CPU，在树莓派4B上编码一帧640x480的JPEG大约需要5-8毫秒，30帧每秒的话CPU占用大概15%-25%。如果你觉得CPU吃紧，可以用picamera2直接输出JPEG，让GPU的硬件编码单元来处理，CPU占用能降到5%以下。但这样你就拿不到原始帧了，没法在树莓派端做图像处理。

我的建议是：如果树莓派只负责采集和传输，用GPU编码；如果还要在树莓派端做处理，用CPU编码。根据你的实际场景选。

3. 实操过程与核心环节实现

3.1 树莓派端完整代码实现

把前面的片段串起来，树莓派端的完整代码如下。我加了详细的注释，方便你理解每一步在做什么。

import socket import struct import time import cv2 from picamera2 import Picamera2 # 配置参数 HOST = "0.0.0.0" # 监听所有网卡 PORT = 8888 RESOLUTION = (640, 480) FRAMERATE = 30 JPEG_QUALITY = 80 def main(): # 初始化摄像头 picam2 = Picamera2() config = picam2.create_video_configuration( main={"size": RESOLUTION, "format": "RGB888"}, controls={"FrameRate": FRAMERATE} ) picam2.configure(config) picam2.start() time.sleep(2) # 等待摄像头稳定 # 创建TCP Socket server_sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server_sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server_sock.bind((HOST, PORT)) server_sock.listen(1) print(f"等待PC端连接，端口 {PORT}...") # 等待客户端连接 client_sock, addr = server_sock.accept() print(f"PC端已连接: {addr}") try: while True: # 采集一帧 frame = picam2.capture_array() # JPEG编码 encode_param = [int(cv2.IMWRITE_JPEG_QUALITY), JPEG_QUALITY] result, encoded = cv2.imencode(".jpg", frame, encode_param) if not result: continue frame_data = encoded.tobytes() # 发送帧头 + 帧数据 header = struct.pack("!I", len(frame_data)) client_sock.sendall(header) client_sock.sendall(frame_data) except (BrokenPipeError, ConnectionResetError): print("PC端断开连接") finally: client_sock.close() server_sock.close() picam2.stop() if __name__ == "__main__": main()

这段代码有几个细节值得注意。SO_REUSEADDR选项允许端口复用，避免程序重启时出现“Address already in use”的错误。**capture_array()**返回的是numpy数组，格式是RGB，可以直接喂给cv2.imencode。异常处理捕获了BrokenPipeError和ConnectionResetError，这是PC端意外断开时最常见的异常，捕获后优雅退出，不会留下僵尸进程。

3.2 PC端完整代码实现

PC端负责接收、解码、显示。代码同样不复杂，但有几个坑要避开。

import socket import struct import cv2 import numpy as np # 配置参数 PI_IP = "192.168.1.100" # 树莓派的IP地址 PORT = 8888 def recv_exact(sock, n): """确保接收n个字节""" data = b"" while len(data) < n: packet = sock.recv(n - len(data)) if not packet: return None data += packet return data def main(): # 连接树莓派 sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect((PI_IP, PORT)) print(f"已连接到树莓派 {PI_IP}:{PORT}") try: while True: # 读取帧头 header = recv_exact(sock, 4) if not header: print("连接断开") break frame_len = struct.unpack("!I", header)[0] # 读取帧数据 frame_data = recv_exact(sock, frame_len) if not frame_data: print("连接断开") break # 解码JPEG frame_array = np.frombuffer(frame_data, dtype=np.uint8) frame = cv2.imdecode(frame_array, cv2.IMREAD_COLOR) if frame is None: continue # 显示画面 cv2.imshow("Raspberry Pi Camera", frame) if cv2.waitKey(1) & 0xFF == ord("q"): break except KeyboardInterrupt: print("用户中断") finally: sock.close() cv2.destroyAllWindows() if __name__ == "__main__": main()

PC端的关键点是PI_IP要填对。树莓派的IP地址可以在树莓派上运行hostname -I查看，或者在路由器的管理界面里找。如果你用的是Windows，可以在命令提示符里ping一下树莓派的IP，确认网络通不通。

实操心得：第一次跑的时候，建议先在树莓派上单独测试摄像头能不能正常工作。运行libcamera-hello -t 0（picamera2的系统）或者raspistill -o test.jpg（老系统），确认摄像头没问题再跑代码。PC端先用ping测试网络连通性，再用telnet或者nc测试端口是否开放。这样分段排查，出问题了容易定位。

3.3 性能实测与参数调优记录

代码跑通之后，我做了一轮性能测试，记录了几个关键指标。测试环境是树莓派4B（4GB内存）+ OV5647摄像头 + 千兆局域网 + PC（i5-10400）。

从数据可以看出几个规律。分辨率对延迟的影响最大，640x480到1280x720，延迟增加了约50%。JPEG质量对带宽的影响很大，但对延迟的影响相对较小。树莓派4B在1080p下已经比较吃力，CPU占用超过60%，帧率掉到15fps，体验明显下降。

我的推荐配置是640x480 + quality 80，这个组合在延迟、画质、资源占用之间取得了最好的平衡。如果你需要更高清的画面，1280x720 + quality 80也可以接受，但要注意树莓派的散热，长时间跑CPU温度会到70度以上，最好加个散热片或者小风扇。

注意事项：树莓派的WiFi模块性能有限，如果你用WiFi传输，建议把分辨率降到640x480，quality降到70，否则容易出现卡顿和丢帧。有条件的话尽量用有线网络，稳定性完全不是一个级别。

4. 常见问题与排查技巧实录

4.1 连接类问题排查

问题一：PC端连接树莓派时报“Connection refused”

这个错误说明TCP连接被拒绝了。排查步骤：先确认树莓派端的程序有没有跑起来，有没有打印“等待PC端连接”；再确认IP地址和端口号填对了没有；然后在PC上运行ping 树莓派IP，看网络通不通；最后检查树莓派的防火墙有没有拦截8888端口。

我遇到过一次，折腾了半天发现是树莓派的IP地址变了。因为路由器DHCP分配的IP不是固定的，树莓派重启后可能拿到新IP。解决办法是在路由器里给树莓派绑定静态IP，或者在树莓派上配置静态IP。

问题二：连接成功但收不到画面

这种情况通常是数据发了但PC端没正确解析。先看树莓派端有没有报错，再看PC端的recv_exact有没有卡住。我遇到过一次，是因为树莓派端发送的帧头用了小端序，PC端用大端序解析，长度完全对不上，导致recv_exact一直等不到足够的数据。

排查方法很简单：在树莓派端打印每帧的长度，在PC端打印解析出的长度，对比一下就知道问题在哪。

问题三：画面卡顿、延迟越来越高

这是典型的缓冲区堆积问题。PC端处理速度跟不上树莓派发送速度，数据在Socket缓冲区里越积越多，延迟就越来越大。解决办法有两个：一是降低树莓派端的帧率或分辨率，减少数据量；二是在PC端加一个丢帧逻辑，如果缓冲区里有多帧数据，只取最新的那一帧。

# PC端丢帧逻辑示例 sock.setblocking(False) # 非阻塞模式 try: while True: data = sock.recv(65536) if not data: break buffer += data except BlockingIOError: pass # 从buffer里解析出所有完整帧，只保留最后一帧

4.2 画质与编码类问题

问题四：画面颜色偏绿或偏紫

这是白平衡没调好。树莓派的摄像头默认自动白平衡，但在某些光源下会失准。解决办法是手动设置ColourGains，对着白色物体调，直到画面颜色正常。如果懒得调，可以在PC端用OpenCV做简单的颜色校正，但效果不如在源头调好。

问题五：画面有横纹或闪烁

这是曝光时间和光源频率不匹配导致的。国内交流电频率是50Hz，如果曝光时间不是10ms的整数倍，就会出现横纹。解决办法是把ExposureTime设成10000微秒（10ms）的整数倍，比如10000、20000。或者直接开自动曝光，让摄像头自己调。

问题六：JPEG编码后画质明显下降

quality参数设太低会导致明显的块状伪影。我的经验是quality不要低于70，低于70的画面在文字和边缘处会出现明显的马赛克。如果带宽实在紧张，宁可降低分辨率也不要降quality，因为分辨率降低是整体模糊，quality降低是局部块状失真，后者更难看。

4.3 稳定性与长期运行问题

问题七：跑几个小时后程序崩溃

长时间运行最常见的问题是内存泄漏和Socket超时。picamera2的capture_array()如果频繁调用，可能会有内存碎片。解决办法是定期重启摄像头，比如每采集10000帧后stop再start一次。Socket方面，设置SO_KEEPALIVE选项可以让系统定期发送心跳包，检测连接是否还活着。

sock.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1)

问题八：树莓派温度过高导致降频

树莓派4B长时间跑视频编码，CPU温度很容易到80度以上，触发降频后帧率骤降。解决办法是加散热片和风扇，或者在代码里加温度监控，温度过高时自动降低帧率。

def get_cpu_temp(): with open("/sys/class/thermal/thermal_zone0/temp", "r") as f: return int(f.read()) / 1000.0 # 在主循环里检查 if get_cpu_temp() > 75: time.sleep(0.1) # 降低采集频率

问题九：多客户端同时连接

上面的代码只支持一个客户端。如果你需要多个PC同时查看画面，需要改成多线程模式，每个客户端一个线程，共享摄像头数据。但要注意，picamera2不支持多线程同时capture，所以需要用一个线程专门采集，然后把帧数据分发给各个客户端线程。

import threading frame_lock = threading.Lock() latest_frame = None def capture_thread(): global latest_frame while True: frame = picam2.capture_array() with frame_lock: latest_frame = frame def client_thread(client_sock): while True: with frame_lock: frame = latest_frame.copy() # 编码发送...

这个改动稍微复杂一些，但思路很清晰：采集和发送分离，用锁保护共享数据。实际测试下来，树莓派4B同时支持3-4个客户端问题不大，再多就吃力了。

4.4 常见问题速查表

实操心得：调试这类网络传输程序，最有效的办法是分段验证。先确认摄像头能出图，再确认Socket能连通，再确认单帧能传输，最后确认连续帧能稳定传输。每一步都打印日志，出问题了看日志就知道卡在哪。我见过太多人一上来就跑完整程序，出问题了完全不知道从哪查起。

5. 进阶扩展与场景延展

5.1 在PC端做实时图像处理

画面传到PC端之后，你可以做很多事情。最常见的是接OpenCV做目标检测、人脸识别、颜色追踪。因为PC端的算力比树莓派强得多，把处理放在PC端是更合理的选择。

比如做人脸检测，只需要在显示之前加几行代码：

face_cascade = cv2.CascadeClassifier(cv2.data.haarcascades + "haarcascade_frontalface_default.xml") gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) faces = face_cascade.detectMultiScale(gray, 1.1, 4) for (x, y, w, h) in faces: cv2.rectangle(frame, (x, y), (x+w, y+h), (0, 255, 0), 2)

这样画面上就会实时框出人脸。类似的，你可以接YOLO做目标检测，接MediaPipe做手势识别，接自己的模型做特定任务。树莓派只负责采集和传输，PC端负责所有计算，分工明确。

5.2 多树莓派画面汇聚

如果你有多个树莓派，想在一个PC端同时查看所有画面，可以把PC端改成多线程客户端，每个线程连接一个树莓派，收到画面后拼接到一个大窗口里显示。

import threading def recv_from_pi(pi_ip, position): sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect((pi_ip, 8888)) while True: # 接收帧... # 将frame放到position指定的位置 pass # 启动多个线程 threads = [] for i, ip in enumerate(["192.168.1.101", "192.168.1.102", "192.168.1.103"]): t = threading.Thread(target=recv_from_pi, args=(ip, i)) t.start() threads.append(t)

这个方案适合做多路监控或者多角度拍摄。每个树莓派独立运行，互不干扰，PC端负责汇聚和显示。

5.3 录制与回放功能

在PC端加一个录制按钮，按一下开始录制，再按一下停止，把视频保存成MP4文件。用OpenCV的VideoWriter就能实现。

fourcc = cv2.VideoWriter_fourcc(*"mp4v") out = cv2.VideoWriter("output.mp4", fourcc, 30, (640, 480)) # 在显示循环里 out.write(frame) # 退出时 out.release()

这个功能很实用，比如你想记录树莓派小车跑过的路线，或者想回看某个时间段的画面，直接录下来就行。

5.4 延迟优化的几个进阶技巧

如果你对延迟有极致要求，可以试试这几个优化手段。

第一，用UDP代替TCP。UDP没有握手和重传机制，延迟更低，但会丢包。对于视频流来说，丢几帧无所谓，画面稍微卡一下但延迟稳定。用UDP的话需要自己处理帧的排序和丢包检测，复杂度高一些。

第二，用硬件编码。picamera2可以直接输出JPEG，走GPU硬件编码，比OpenCV的CPU编码快很多。代价是拿不到原始帧，没法在树莓派端做处理。

第三，降低分辨率。这是最直接有效的办法。320x240分辨率下，延迟可以压到50ms以内，但画质就只够看个大概了。

第四，优化网络路径。树莓派和PC之间如果经过路由器，延迟会增加。有条件的话用直连网线，或者用支持低延迟模式的路由器。

我实测下来，640x480 + quality 80 + TCP直连，端到端延迟稳定在80-120ms，这个水平对于大多数应用场景已经足够了。如果你要做的远程控制需要更低的延迟，那就得在分辨率和画质上做取舍。

5.5 这个方案还能怎么用

除了基本的画面传输，这个架构还可以扩展到很多场景。

树莓派小车FPV：把树莓派装在小车上，摄像头朝前，PC端实时显示画面，配合手柄或键盘控制小车移动。延迟控制在100ms以内的话，操作体验很跟手。

家庭监控：树莓派固定在某个位置，PC端或者手机端随时查看。可以加个移动侦测，画面有变化时才传输，节省带宽。

远程实验观察：比如你在培养细菌或者做化学实验，需要长时间观察，树莓派摄像头对着实验对象，PC端记录画面变化。

多机位直播：多个树莓派从不同角度拍摄同一场景，PC端切换或拼接画面，做低成本的多机位直播方案。

这个方案的核心优势就是简单、可控、低延迟。没有复杂的流媒体服务器，没有繁琐的配置，几百行Python代码就能跑起来。对于个人项目和小型应用来说，性价比极高。

最后分享一个小技巧：如果你在PC端用OpenCV显示画面时发现窗口卡顿，可以试试把cv2.imshow换成cv2.namedWindow + cv2.imshow的组合，或者用matplotlib的动画显示。不过大多数情况下，cv2.imshow的性能是足够的，卡顿通常是因为解码或网络环节出了问题，而不是显示环节。