两周前一个做工厂质检的兄弟问了我一个问题：“我用Python写好的模型，怎么接到海康摄像头的实时画面上？”这个问题我实在太熟了。过去几年不管是做智慧门店的人流统计、园区安防平台的视频接入，还是帮算法工程师搭建数据采集环境，十次有八次绕不开海康的相机。而真正把Python和海康设备打通，用的就是“海康设备网络SDK二次开发”这条路：通过官方提供的HCNetSDK动态库，把摄像头的取流、抓图、云台控制、报警订阅这些能力全部暴露给Python。

这篇文章我会从方案选型、SDK部署、核心接口调用、踩坑记录这几个角度，把完整套路讲清楚。适合三种人看：一是刚接手安防项目、需要用Python接海康摄像头的开发者；二是只会用RTSP拉流但需要设备控制能力的工程师；三是做视觉算法集成、需要把实时视频流喂给OpenCV或深度学习模型的人。看懂这篇文章，你能在一两个小时之内跑通“登录—取流—抓图—算法处理”的完整链路。

1. 为什么要把海康摄像头接到Python里

1.1 不是所有的视频接入都该用SDK

很多朋友第一次接触摄像头接入，最先拿到的方案是RTSP地址。没错，海康摄像头有一个标准的RTSP取流地址，格式大概是这样的：

rtsp://用户名:密码@摄像头IP:554/Streaming/Channels/101

其中101代表主码流第一路，102代表子码流第一路。用OpenCV的VideoCapture、FFmpeg或者VLC都能直接拉流，验证设备在线、看个画面非常快，人还没坐下，视频已经出图了。

但RTSP方案有几个很明显的天花板。第一，延迟不稳定，公网或者Wi-Fi环境下经常跳到几百毫秒以上，做实时质检、出入口控制这类对延迟敏感的项目会很难受。第二，RTSP只有视频流，你拿不到云台控制、报警回调、设备校时、远程配置、语音对讲这些能力。第三，多路同时取流时，RTSP在断线重连、码流协商这些环节上表现得不够稳定，稍不注意就会整个程序卡死或内存暴涨。

这时候SDK二次开发的价值就体现出来了。海康设备网络SDK走的是私有协议（默认端口8000），不仅支持实时视频预览，还提供完整的设备控制接口，是接入海康设备最正统、能力最全的路径。我的建议是：做快速原型验证用RTSP，做正式项目、特别是需要设备控制和多路稳定取流的项目，直接用SDK。

1.2 Python在海康二次开发里扮演什么角色

如果你以前是用C++做海康SDK开发，你会发现那套代码非常“工业风”：几十个结构体、一堆回调函数、异常日志全靠调试器。而Python的优势在于胶水能力极强，ctypes可以直接加载动态库，配合OpenCV、NumPy做图像处理，配合Flask/FastAPI做接口服务，配合调度框架做定时巡检，一套代码就能串起来。

实际项目里，Python通常不是去替代SDK本身，而是把SDK当作一个能力底座。摄像头登录、预览、抓图这些脏活累活交给SDK动态库，Python负责业务逻辑、算法推理、数据入库和结果展示。分工清楚以后，整个项目的代码量会小一个数量级，调试效率也高很多。

当然，Python交给SDK的代价是性能。SDK回调出来的视频帧数据要经过一次内存拷贝才能变成NumPy数组，多路并发时还得处理线程同步。但这些问题都有成熟解法，后面我会专门讲。

1.3 技术路线选型：SDK、ISAPI、ONVIF、RTSP怎么选

海康设备的接入方式不止SDK一种。我自己在做项目早期，就在这几个方案之间纠结过，这里一次性对比清楚。

选型逻辑很简单：需要全套能力、对稳定性要求高，首选SDK；只要抓图和设备信息，ISAPI也行；项目里有多个品牌的摄像头，考虑ONVIF做统一接入；仅仅是看画面，RTSP就够了。这篇文章后面的内容都基于设备网络SDK展开。

2. 环境准备与SDK部署细节

2.1 下载SDK与版本选择

海康的设备网络SDK可以从官网“服务支持—下载中心—工具软件”里找到，搜索“设备网络SDK”就行。下载下来的压缩包里一般包含Windows 32位、Windows 64位和Linux 64位三个平台的库文件，以及一个很详细的开发文档和C++示例代码。

版本号经常见到类似“v5.3.6.35”这种，不同小版本间接口基本兼容，但结构体字段会有调整。我建议直接下载最新稳定版，然后用哪个平台，就把对应文件夹整个解压出来，不要混着用。SDK目录里通常有HCNetSDK.dll、HCCore.dll、PlayCtrl.dll、hlog.dll、hpr.dll这些文件，它们是互相依赖的，缺一个都会导致加载失败。

还有一点要提醒：如果你要用Python操作，下载SDK的同时注意Python解释器位数。SDK是32位的，Python就必须是32位；SDK是64位的，Python就必须是64位。混用会在加载DLL时直接报错，而且错误类型还特别迷惑，后面排查章节会专门说。

2.2 Windows部署：DLL文件放哪里不报错

Windows下部署最容易踩坑的就是DLL路径。很多人把Python环境装好了，SDK也解压了，结果一运行就提示“找不到指定的模块”或“无法加载DLL”，其实就是动态库的搜索路径问题。

我的做法是建一个专门的lib/HCNetSDK目录，把SDK压缩包里的全部文件放进去，然后在代码里用绝对路径加载：

import os import ctypes os.environ["PATH"] = os.path.dirname(__file__) + "/lib/HCNetSDK;" + os.environ["PATH"] sdk = ctypes.WinDLL(os.path.join(os.path.dirname(__file__), "lib/HCNetSDK", "HCNetSDK.dll"))

Windows下把SDK目录加入PATH环境变量特别重要，因为HCNetSDK.dll运行时会动态加载HCCore.dll等附属库，如果不把目录加进去，就算你直接用绝对路径加载主DLL，后面也会在调用某个接口时突然崩溃或返回异常。

建议开发阶段把DLL和Python脚本放在一起，或者明确指定路径。不要图省事把所有DLL往System32里塞，后面项目要部署到别的机器时，会到处踩Missing DLL的坑。

2.3 Linux部署：不要再为libcrypto报错浪费时间

Linux下的部署稍微麻烦一点，因为SDK依赖一些系统库。下载的Linux SDK包里会有libhcnetsdk.so、libcrypto.so、libz.so等文件，你需要把整个SDK目录拷贝到项目里，然后设置LD_LIBRARY_PATH，让系统能找到这些库。

我常用的启动脚本是这样的：

export LD_LIBRARY_PATH=/opt/hik/libs:$LD_LIBRARY_PATH python3 app.py

如果程序启动时提示error while loading shared libraries: libcrypto.so.1.1，通常是SDK依赖的OpenSSL版本和你系统里的不一致。最省事的解决办法是在SDK库目录里放一个软链接指向系统已有的版本：

ln -s /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /opt/hik/libs/libcrypto.so.1.1

另外，Linux下客户端要在非root用户下运行，注意确保该用户对SDK目录有读取权限，否则加载so文件时会显示一个很泛的“Operation not permitted”，实际上就是权限问题。

2.4 Python加载DLL的正确姿势

Python加载海康SDK，现在主流的方式还是ctypes。Windows上用ctypes.WinDLL（对应stdcall调用约定），Linux上用ctypes.CDLL（对应cdecl调用约定）。

import ctypes # Windows sdk = ctypes.WinDLL(r"D:\project\lib\HCNetSDK\HCNetSDK.dll") # Linux sdk = ctypes.CDLL("/opt/hik/libs/libhcnetsdk.so")

加载之后建议立刻给关键函数设置返回类型，尤其是返回指针或句柄的函数。ctypes默认把函数返回值当作c_int处理，但SDK很多接口返回的是指针，在高位地址大于2GB的64位进程里就会被截断，轻则返回值错误，重则直接段错误：

sdk.NET_DVR_Login_V40.restype = ctypes.c_long sdk.NET_DVR_GetLastError.restype = ctypes.c_int

这一步非常简单，但很多人会漏掉。我在生产环境里排查过不止一次的“明明登录成功却返回负数”问题，最后都是这个原因。

3. 核心调用链路：从初始化到取流

3.1 调用顺序与整体生命周期

海康SDK的调用顺序非常固定，正常情况下是：

1. NET_DVR_Init()：初始化SDK，必须第一个调用。
2. NET_DVR_SetConnectTime()：设置网络连接超时和重试次数。
3. NET_DVR_Login_V40()：登录设备，返回用户ID。
4. 各种业务操作：预览、回放、云台、抓图、报警监听等。
5. NET_DVR_Logout()：登出，释放用户ID。
6. NET_DVR_Cleanup()：释放SDK全局资源。

这个顺序不能乱。早期我图省事，跳过NET_DVR_SetConnectTime直接登录，结果在设备网络不通的情况下，程序卡了差不多20秒才返回失败。设置了连接超时为2秒、重试1次之后，问题马上缓解。

还有一个细节：一个进程里所有设备共享同一个SDK环境，所以NET_DVR_Init只需要调用一次。多设备并发登录的时候，每个设备拿到独立的用户ID，后续操作都用各自的用户ID区分。

3.2 登录：结构体、端口与编码的细节

登录接口NET_DVR_Login_V40需要两个结构体：登录参数结构体和设备信息结构体。C头文件里的字段一个都不能少，ctypes翻译时要严格按顺序定义。下面这一段是常用的登录代码骨架：

import ctypes as ct class NET_DVR_DEVICEINFO_V30(ct.Structure): _fields_ = [ ("sSerialNumber", ct.c_byte * 48), ("byAlarmInPortNum", ct.c_byte), ("byAlarmOutPortNum", ct.c_byte), ("byDiskNum", ct.c_byte), ("byDVRType", ct.c_byte), ("byChanNum", ct.c_byte), ("byStartChan", ct.c_byte), ("byAudioChanNum", ct.c_byte), ("byIPChanNum", ct.c_byte), ("byZeroChanNum", ct.c_byte), ("byMainProto", ct.c_byte), ("bySubProto", ct.c_byte), ("bySupport", ct.c_byte), ("bySupport1", ct.c_byte), ("bySupport2", ct.c_byte), ("wDevType", ct.c_ushort), ("bySupport3", ct.c_byte), ("byMultiStreamProto", ct.c_byte), ("byStartDChan", ct.c_byte), ("byStartDChan1", ct.c_byte), ("byDChanNum", ct.c_byte), ("byIPChanNum1", ct.c_byte), ("byBlockNum", ct.c_byte), ("byRes1", ct.c_byte * 28), ("byRes2", ct.c_byte * 8), ] class NET_DVR_USER_LOGIN_INFO(ct.Structure): _fields_ = [ ("dwSize", ct.c_uint), ("sDeviceAddress", ct.c_char * 129), ("byUseTransport", ct.c_byte), ("wPort", ct.c_ushort), ("sUserName", ct.c_char * 64), ("sPassword", ct.c_char * 64), # 注意：这里只是最常用的字段，完整结构体必须按照 # 你下载版本的官方头文件逐字段翻译，顺序和字段数量 # 都不能错，否则内存布局不一致，SDK内部会读越界。 ]

登录逻辑：

login_info = NET_DVR_USER_LOGIN_INFO() device_info = NET_DVR_DEVICEINFO_V30() login_info.dwSize = ct.sizeof(NET_DVR_USER_LOGIN_INFO) login_info.sDeviceAddress = b"192.168.1.64" login_info.wPort = 8000 login_info.sUserName = b"admin" login_info.sPassword = b"your_password" login_info.byUseTransport = 0 user_id = sdk.NET_DVR_Login_V40(ct.byref(login_info), ct.byref(device_info)) if user_id < 0: err_code = sdk.NET_DVR_GetLastError() print("登录失败，错误码：", err_code) else: print("登录成功，用户ID：", user_id)

有几个坑特别值得说。

第一，登录端口是8000，不是80，也不是554。这是海康SDK私有协议的默认端口，设备端可以在网络配置里改，如果你改过，这里就要对应改。

第二，密码和IP都是字节串，必须是b"..."而不是普通字符串。尤其是密码里带中文或特殊字符时，编码处理更要小心，Windows下有时需要按设备的语言编码来做转换。

第三，登录失败后要习惯性调用NET_DVR_GetLastError()拿错误码。海康的错误码非常有用，比如71表示密码错误，17表示用户不存在，24表示资源不足，77表示密码错误次数过多账号被锁。拿到错误码再做判断，比自己瞎猜靠谱得多。

3.3 实时取流与两种预览方式的取舍

登录成功只是拿到了“控制权”，真正把视频流拉回来，需要调用NET_DVR_RealPlay_V40。这个接口支持两种模式：直接窗口播放和回调数据。

窗口播放模式下，你要传入一个窗口句柄，SDK内部会把画面直接渲染到这个窗口里。这种方式最简单，但和Python的结合度低，因为你很难把画面再拿去做算法处理。所以Python项目里基本都用回调模式。

回调模式的核心是注册一个回调函数：

REALDATACALLBACK = ct.CFUNCTYPE( None, # 返回值 ct.c_long, # lRealHandle 预览句柄 ct.c_uint, # dwDataType 数据类型 ct.c_char_p, # pBuffer 数据缓冲区地址 ct.c_uint, # dwBufSize 数据大小 ct.c_void_p # pUser 用户自定义数据 )

注册预览时，把窗口句柄设为NULL，再把回调函数丢进去：

preview_info = NET_DVR_PREVIEWINFO() preview_info.lChannel = 1 # 通道号，IP相机通常从1开始 preview_info.dwStreamType = 0 # 0-主码流，1-子码流 preview_info.dwLinkMode = 0 # TCP方式 preview_info.hPlayWnd = None # 不显示窗口 real_handle = sdk.NET_DVR_RealPlay_V40( user_id, ct.byref(preview_info), callback, None )

这里最关键的认知是：回调函数拿到的原始数据不是直接的BGR图像，通常是YUV数据或经过编码的私有流数据。YUV需要转换成BGR才能交给OpenCV；私有流数据则需要通过专门的解码库（比如PlayCtrl.dll）去解码。后面实战章节我会给出一个完整的处理方案。

还有一点：回调函数运行在SDK的内部线程里，千万不要在回调里做耗时操作。你要是直接在回调里调用模型推理，几秒钟就会把SDK的取流线程堵死，表现就是画面卡住、程序内存不断上涨，看起来莫名其妙，其实原因很简单。

3.4 抓图、录像、云台控制等扩展能力

除了实时取流，SDK常用的能力还包括：

• 抓图：NET_DVR_CaptureJPEGPicture可以直接保存一张JPEG图片，适合做事件触发抓拍。
• 本地录像：NET_DVR_SaveRealData可以开始把实时流保存到本地文件；停止时调用NET_DVR_StopSaveRealData。
• 云台控制：NET_DVR_PTZControl_Other可以控制云台的上下左右、变倍、变焦等操作，适合做巡检类项目。
• 报警监听：NET_DVR_SetupAlarmChan_V41可以订阅移动侦测、遮挡报警、IO输入报警等事件，适合做安防联动。

这些接口的调用方式和登录、取流是同一套逻辑：先拿用户ID，再按文档填结构体，最后调用对应接口。有了前两步的基础，后面基本都是查文档填参数的事。

4. 实操示例：登录、抓图、实时取流转OpenCV

4.1 最小示例：登录摄像头并抓一张图

先看一个最直接的例子，用SDK登录摄像头，然后抓一张JPEG图保存到本地。这个例子可以作为任何海康项目的“冒烟测试”，能跑通就说明环境没问题。

import ctypes as ct sdk = ct.WinDLL(r"D:\project\lib\HCNetSDK\HCNetSDK.dll") # 初始化并设置连接超时 sdk.NET_DVR_Init() sdk.NET_DVR_SetConnectTime(ct.c_uint(2000), ct.c_uint(1)) # 登录（结构体定义见3.2节，这里省略） user_id = sdk.NET_DVR_Login_V40(...) if user_id < 0: raise RuntimeError(f"登录失败: {sdk.NET_DVR_GetLastError()}") # 抓图参数：尺寸按当前分辨率，画质最高 class NET_DVR_JPEGPARA(ct.Structure): _fields_ = [ ("wPicSize", ct.c_ushort), ("wPicQuality", ct.c_ushort), ] jpeg_para = NET_DVR_JPEGPARA(0xFF, 0) ret = sdk.NET_DVR_CaptureJPEGPicture( user_id, 1, # 通道号 ct.byref(jpeg_para), b"D:/capture_001.jpg" ) if ret: print("抓图成功") else: print("抓图失败，错误码：", sdk.NET_DVR_GetLastError()) sdk.NET_DVR_Logout(user_id) sdk.NET_DVR_Cleanup()

wPicSize传0xFF表示保持当前分辨率，wPicQuality传0表示最高画质。如果你想抓小图，可以按头文件里的枚举值指定大小。

这个示例最好的一点是它不涉及视频流的解码，非常适合排查部署问题。如果你的SDK环境配置有问题，在这一步就会暴露出来，而不至于等到复杂的取流阶段才炸。

4.2 实时取流：把视频数据交给OpenCV处理

实时取流转OpenCV是大多数视觉项目的主场景。这里要解决的问题是：SDK回调出来的是YUV原始帧，怎么变成OpenCV能处理的BGR图像。

生产级做法是通过PlayCtrl解码库来转换。用PlayCtrl.dll的PlayM4_SetDecCallBack注册解码回调，SDK拿到私有视频流后调用PlayCtrl解出RGB数据，再把RGB数据交给OpenCV。整个链路是：

• 海康摄像头 → HCNetSDK.Play → PlayCtrl解码 → RGB缓冲 → NumPy数组 → OpenCV处理

下面是核心逻辑的简化代码，核心思想是把解码后的数据放进一个有界队列，再由独立线程消费，避免阻塞SDK线程：

import cv2 import numpy as np import ctypes as ct from collections import deque import threading frame_queue = deque(maxlen=2) def decode_call_back(nPort, pBuf, nSize, pUser): # 数据已经过PlayCtrl解码，pBuf里是RGB数据 if pBuf: frame_data = ct.string_at(pBuf, nSize) # 宽高根据实际码流确定，这里用1280x720示例 img = np.frombuffer(frame_data, dtype=np.uint8).reshape((720, 1280, 3)) frame_queue.append(img.copy()) # 注册解码回调 playctrl = ct.WinDLL(r"D:\project\lib\HCNetSDK\PlayCtrl.dll") playctrl.PlayM4_SetDecCallBack(ct.c_int(nPort), decode_call_back, None) # 主循环 while True: if frame_queue: frame = frame_queue.popleft() # 在这里做算法处理，比如人形检测、质检分类等等 cv2.imshow("frame", frame) if cv2.waitKey(1) & 0xFF == ord('q'): break

注意队列用deque(maxlen=2)，这个设计非常关键。它相当于一个缓冲池，只保留最新两帧，防止算法处理不过来时内存无限增长。很多项目卡顿、内存溢出的根源就是没有做这个限制，帧全部堆积在队列里。

4.3 生产环境要处理的三个细节

第一个细节是线程模型。建议把视频处理放在独立线程池里跑，而取流只负责把帧放进队列。主线程可以处理界面/API请求，算法线程专门消费帧。这样即使算法偶尔卡顿，也不会反过来阻塞SDK取流。

第二个细节是断线重连。摄像头的网络随时可能抖动，SDK会在回调里以数据类型NET_DVR_SYSHEAD通知你连接变化。实战中要在取流线程里周期性检查播放句柄是否有效，无效就按“杀掉当前播放句柄 → 重新登录（如果用户ID也失效） → 重新RealPlay”的顺序恢复。重连逻辑一定要加退避，否则设备掉线期间程序会疯狂重连，把带宽和CPU都打满。

第三个细节是资源释放顺序。程序退出时，正确的顺序是：先停止实时取流（NET_DVR_StopRealPlay），再登出（NET_DVR_Logout），最后清理SDK全局资源（NET_DVR_Cleanup）。顺序颠倒的话，轻则日志报错，重则进程崩溃。

5. 高频问题排查与经验汇总

5.1 错误码速查表

海康SDK的错误码排查起来相对比较直接，因为官方文档里有一份完整的错误码表。我这里整理几个高频出现的：

不同SDK版本的错误码可能有细微差别，排查时优先查你下载版本自带的错误码表，不要把网上看到的旧错误码直接套用。

5.2 登录失败与网络不通的排查顺序

登录失败是最常见的现象，但原因五花八门。我的排查顺序固定如下，能省不少时间：

第一步，先确认网络通不通。用ping 摄像头IP看丢包，再用telnet 摄像头IP 8000确认8000端口是否开放。这一步能排除大量低级问题。

第二步，确认SDK初始化和连接超时设置是否正常。如果跳过NET_DVR_SetConnectTime，弱网环境下单个操作卡十几秒很常见，但这不代表SDK坏了。

第三步，检查设备端配置。登录不上时，到浏览器里打开摄像头IP（部分浏览器需要安装插件）确认当前密码是否被改过、账号是否被锁定、设备是否处于激活状态。

第四步，看错误码。通过NET_DVR_GetLastError()拿到的错误码，基本能直接定位到具体问题，不用猜。

5.3 取流黑屏、卡顿、丢帧的排查方向

黑屏问题十有八九是解码链路出问题。SDK回调拿到的是YUV或私有码流，如果你直接把原始数据当BGR图片显示，那当然是花屏或黑屏。确认方式是打印回调数据的类型值：NET_DVR_SYSHEAD表示码流头，NET_DVR_STREAMDATA才是具体视频数据。通道号错误也会黑屏，IP通道通常从1开始，但遇到接入多个IP相机的NVR时，通道号可能要从NET_DVR_GetDVRConfig里查。

卡顿问题先分网络还是性能。主码流如果设成4K、码率8Mbps，在4G或Wi-Fi环境下就会非常卡。解决方案是切到子码流，或者在设备端把主码流的帧率、码率调低。用回调方式做算法处理时，如果算法每秒只能处理10帧，而视频是25帧，就不要奢望全部处理，直接用带最大长度限制的队列配合抽帧策略更实际。

丢帧问题通常不是SDK丢了帧，而是你的消费速度跟不上。回调线程每次都要拷贝完整图像，如果再加上转码和深度学习推理，很容易把回调线程拖死。我推荐的做法是把回调里的工作压缩到极限：只做内存拷贝和入队，所有重活挪到别的线程。

5.4 几个容易被忽略的Python与SDK兼容问题

Python和SDK协同工作时，有些坑平时根本不会注意到，但一旦遇到就是“折腾一晚上”。

首先是位数不一致。32位Python加载64位SDK，会报“不是有效的Win32应用程序”。反过来，64位Python加载32位SDK则可能直接崩溃，原因在2.1节提过，这里不重复。

其次是Python新版本对结构体的对齐要求更严格。ctypes翻译结构体时，字段顺序和类型必须和C头文件完全一致，不能为了省事只翻译自己用到的那几个字段。只要有一个字段顺序错了，SDK就会读到错误的内存数据，表现可能是登录成功但抓图全黑，也可能是某个接口偶发返回错误。

再次是编码问题。SDK的很多字符串参数是char*，在Python里就是bytes。中文密码、中文路径在Windows下还有GBK和UTF-8的区别，一个处理不对就是登录失败或者文件路径错误。

最后是路径问题。PlayCtrl解码库需要能正常找到它自己的附属文件，如果你把PlayCtrl.dll单独拷出来而不带它的配置文件，调用时就会莫名失败。最好是整个SDK目录一起部署，不要只挑几个DLL。

5.5 关于浏览器打不开摄像头的题外话

经常有人问“浏览器打不开海康摄像头怎么办”。这个问题在SDK项目里也常见，因为很多人会先试图用浏览器确认设备状态，结果卡在插件安装或浏览器兼容性上。实际上，浏览器打不开摄像头，通常只是ActiveX插件、浏览器版本、HTTPS证书这些Web层面的事情，和摄像头本身的运行状态没有直接关系。如果你的调试目标是通过Python做二次开发，完全可以绕过浏览器操作，直接走SDK或ISAPI。设备在线、密码正确、端口开放这三点确认后，就不必纠结浏览器能不能出画面了。

写在最后的一点体会

这类项目做多了，我最大的感受是：海康SDK二次开发本身不难，难的是把C语言的异步回调模型干净地放进Python生态里。回调里不要做重活、队列必须有界、重连必须有退避，这三个原则我几乎在每个项目里都会用到。另一个心得是，不要一上来就想把所有功能一步做完，先保证“初始化 → 登录 → 抓图”这条最小链路能跑通，再逐步叠加实时取流、云台控制、报警订阅。每加一个能力，单独验证一个能力，出了问题能快速定位，项目推进反而更快。

如果你正准备做海康SDK的Python接入，照着这篇文章先把环境部署和最小示例过一遍，大概率能少走我当初走过的那些弯路。剩下的功能，基本上就是查官方文档、填结构体、调用接口的重复劳动了。