远程电脑屏幕监控源码：采集、传输与查看端低延迟闭环

简介：这份面向Java初学者与远程控制技术爱好者的远程电脑屏幕监控示例工程，围绕网络实时查看与远端屏幕控制场景，提供一套可导入Eclipse分析学习的轻量源码。压缩包为rar格式，共14个文件、约12KB，包含5个java源文件、6个class编译文件及Eclipse工程配置，便于还原项目结构并对照源码与字节码理解实现。内容涉及屏幕捕获、图像编码、TCP/IP与WebSocket通信、权限控制、多线程处理及增量更新等知识点，适合用作课程设计、技术验证或小型远程协助原型的参考。已有600人浏览学习，体积虽小但结构完整，可帮助读者快速定位核心类与通信流程，梳理从抓屏、压缩到传输、解码的链路，并在此基础上做安全性、延迟与界面体验的二次优化。

1. 远程电脑屏幕监控这套源码：三段链路各自解决什么问题

远程协助时最费劲的场景，是让对方描述"点左上角那个按钮"，来回几轮还是点错。另一类场景是自己放在机房或家里跑长任务的那台机器，想知道它卡在哪一步、报错框长什么样。这两件事最后都收敛到同一个技术动作：把一台机器的屏幕像素，稳定、低延迟地送到另一台机器的屏幕上。这份「远程电脑屏幕监控」资源就是围绕这个动作做的一套可跑闭环，拆成采集端、传输服务端、查看端三段，每段都能单独拎出来替换。

它适合的人很明确：要做远程协助小工具、要做教学演示的画面上行、要巡检自有无人值守设备的开发者。不适合的人也说清楚：想直接拿去做大规模并发视频分发的，这套东西的传输层是长连接加帧队列，不是流媒体服务器。另外，被控端必须由使用者自己启动并显式授权，这是使用这类工具的前提，下面所有实现都按这个前提写。

2. 采集与编码：把 1080p 画面压到 200KB 以内的参数取法

屏幕采集看着简单，真上手第一个翻车点就在"采一帧要多久"。很多教程上来就ImageGrab.grab()，单帧在 1080p 下经常要 30～60ms，还没开始编码，帧率上限就锁死在 20fps 附近了。这一章先把采集这块的地基打稳，再谈帧率、分辨率、码率这三个参数怎么互相牵制，最后落到"只传变化区域"这个能把带宽砍掉一大截的做法。

2.1 采集库选型：为什么先用 mss 起步

mss走的是系统位图接口，用 ctypes 直接拿屏幕缓冲区，不经过中间图像对象转换，1080p 单帧通常在 8～15ms，比ImageGrab快一个量级。它跨平台，Windows、Linux（X11）、macOS 都有一套实现，源码包里的采集端默认就是它。需要注意的是它拿到的像素格式是 BGRA，不是常见的 RGB，这个通道顺序在后面编码和渲染时都要一路对齐，否则画面会偏色。

import time import mss import numpy as np with mss.mss() as sct: # monitors[0] 是全部显示器拼成的虚拟桌面；monitors[1] 起是各块物理屏 mon = sct.monitors[1] grab = sct.grab # 绑定成局部变量，循环里少一次属性查找 for i in range(60): t0 = time.perf_counter() frame = np.asarray(grab(mon)) # shape=(h, w, 4)，通道序 BGRA t1 = time.perf_counter() # 编码前必须切掉 alpha 通道，BGRA -> BGR bgr = frame[:, :, :3] print(f"#{i} {mon['width']}x{mon['height']} " f"采集 {(t1 - t0) * 1000:.2f} ms, shape={bgr.shape}")

这段代码的重点不在打印，而在测出你目标机器上的真实采集耗时。monitors[1]和monitors[0]的区别经常被忽略：前者是单块物理屏，后者是跨屏虚拟桌面，如果直接用[0]，双屏机器上会拿到一张超宽图，后面所有坐标换算都会跟着错。循环里把sct.grab绑成局部变量是省掉每次的方法解析，属于小优化但白拿。

参数上只有一处要注意：mss.mss()实例要复用，不要每帧新建，每次新建都会重新初始化一次平台相关的句柄，代价在几十微秒到几毫秒不等。在 30fps 下看着不多，在 60fps 下就是实打实的浪费。

2.2 帧率、分辨率、码率的三角关系

很多人默认把帧率设成 60，觉得越高越流畅。屏幕内容和摄像头不一样：大部分时间画面是静止的，真正变化的是光标、输入框、滚动列表这类局部区域，盲目 60fps 只会把重复的静止帧再编码一遍。下面这张表是按 JPEG 质量 70 估算的带宽，用来做初步选型够用，实际值会随画面复杂度上下浮动。

最后一行才是这套源码默认走的路子。判断依据很朴素：局域网千兆环境下 1080p30 全帧也就占三成带宽，但一旦跨公网、走自建中继，上行带宽经常只有 5～20 Mbps，全帧直接撑爆，表现就是查看端越看越卡、延迟越堆越高。所以采集端的默认配置是：分辨率等比缩到宽 1280 或 1600，帧率 15，配合帧差，质量 70。

缩放不要用cv2.resize到固定尺寸，要按宽高比算：

import cv2 def fit_width(bgr, target_w=1280): h, w = bgr.shape[:2] if w <= target_w: return bgr scale = target_w / w return cv2.resize(bgr, (target_w, int(h * scale)), interpolation=cv2.INTER_AREA) # 缩小用 AREA 才不会有摩尔纹

INTER_AREA在缩小场景下比默认的INTER_LINEAR干净得多，特别是画面里有细密文字的时候，用线性插值会出现明显的锯齿闪烁，鼠标一移动整片文字都在抖。这个参数属于典型的"改一个字母，观感差一档"。

2.3 帧差分块：只编码真正变了的地方

帧差的思路是把画面切成固定大小的块，逐块比较当前帧和上一帧，只对变化的块编码，其余块在传输时留空，查看端用上一帧的对应区域补上。块大小的选择有讲究：64 太小，1920×1080 会切出 510 块，纯 Python 循环比较的耗时能吃掉采集省下来的时间；128 太大，光标移动这种小范围变化会带动一整块重传。默认取 64，配合 numpy 的向量化比较，单帧判定在 3～6ms。

import numpy as np BLOCK = 64 MSE_THRESH = 2.0 # 均方误差阈值，压掉编码噪声导致的误判 def diff_blocks(curr, prev, block=BLOCK, thresh=MSE_THRESH): """返回 [(x, y, w, h), ...]，空列表表示整帧没变""" h, w = curr.shape[:2] changed = [] for y in range(0, h, block): for x in range(0, w, block): c = curr[y:y + block, x:x + block] p = prev[y:y + block, x:x + block] if c.shape != p.shape: # 边缘不足一块时直接算变化 changed.append((x, y, c.shape[1], c.shape[0])) continue # 用 int16 避免 uint8 相减下溢，这是最常见的翻车原因 mse = np.mean((c.astype(np.int16) - p.astype(np.int16)) ** 2) if mse > thresh: changed.append((x, y, c.shape[1], c.shape[0])) return changed

逻辑上有三处值得说。第一，转int16是必须的，uint8相减在差值为负时会回绕成 255 附近的大数，导致静止区域被判成"变化剧烈"，画面看着一直在传但都是无效流量。第二，阈值不能设成 0，屏幕上的渐变背景、视频播放、抗锯齿文字都会产生 1～2 的微小抖动，阈值 2.0 左右能压掉绝大部分误判。第三，返回的是矩形列表而不是布尔掩码，因为编码器按矩形裁剪比按掩码抠图快得多。

真正发送时，把这批矩形逐个cv2.imencode成 JPEG，打包进一个"帧描述"里，查看端按坐标贴回去。一个实测数据：办公场景（文档 + 终端 + 偶尔滚屏）下，帧差能把平均单帧从 110KB 压到 20KB 出头，带宽下降四倍多，观感几乎没有区别。代价是长时间不动的区域如果有累积误差（比如网页里的动画跑马灯只在一个小角落变），查看端会出现局部"冻住"，这个问题在第 5 章会专门讲怎么兜底。

3. 传输层：长度前缀协议与丢帧背压怎么配

采集端出的是字节流，传输层要解决的是"这段字节属于哪一帧、从哪开始到哪结束"。TCP 是字节流协议，不保证你一次sendall对应一次recv，两块数据黏在一起或者半块到达都是常态。这一章把自定义帧头协议、多客户端分发和断线重连三件事定下来，这三块配不好，前面采集再快也会在查看端表现为花屏和延迟爬升。

3.1 帧头协议：长度前缀为什么不能省

最省事的做法是每次send一个 JPEG，接收端recv(65536)然后imdecode。这个写法在局域网低负载时能跑，一旦网络抖动或者发送端连发两帧，接收端就会拿到两个 JPEG 拼在一起的字节，imdecode直接返回 None，表现就是画面随机丢帧、偶尔整块花掉。正确做法是给每帧加一个定长头，头里写明载荷长度，接收端先读头、再按长度精确读满。

import struct # >I 大端 uint32 长度 | B uint8 帧类型 | I uint32 毫秒时间戳 HEADER = struct.Struct(">IBI") FTYPE_FULL, FTYPE_DIFF, FTYPE_HB = 1, 2, 0 # 0 长度表示心跳 def send_frame(sock, payload: bytes, ts_ms: int, ftype: int = FTYPE_FULL): sock.sendall(HEADER.pack(len(payload), ftype, ts_ms) + payload) def recv_exact(sock, n: int) -> bytes: buf = bytearray() while len(buf) < n: chunk = sock.recv(n - len(buf)) # 只请求还差的字节数 if not chunk: raise ConnectionError("peer closed") buf += chunk return bytes(buf) def recv_frame(sock): length, ftype, ts_ms = HEADER.unpack(recv_exact(sock, HEADER.size)) if length == 0: return ftype, ts_ms, b"" # 心跳，没有载荷 return ftype, ts_ms, recv_exact(sock, length)

recv_exact是这段代码的核心，recv(n - len(buf))里的减法不能省，否则会多读走下一帧的头部，整个连接从此错位，往后全是花屏。>I选大端是为了跨语言时少踩坑，JavaScript 的DataView默认也是大端读取，Web 端接进来不用做字节翻转。时间戳用毫秒 uint32，够用 49 天，超了会回绕，长连接场景要么接受回绕要么换 uint64，这里按 49 天够用来定。

头部长度固定 9 字节，比变长编码浪费一点点，换来的是接收端逻辑简单、不需要状态机。这类小协议里，简单比省几字节重要得多。

3.2 多客户端分发与背压：队列满了丢哪一帧

服务端的职责是把一路采集流分发给 N 个查看端。最容易写错的地方是给每个客户端一个无限长的队列：某个查看端网络差、消费慢，队列就越堆越长，内存涨上去，最后这个客户端看到的画面是几分钟前的，而且服务端开始卡。正确做法是把队列长度压到 2～3 帧，满了丢最旧的，保证"慢的客户端看到的是最新画面，只是帧率低"，而不是"看到完整历史但延迟爆炸"。

import queue, threading class Broadcaster: def __init__(self): self.clients = {} # conn -> Queue self.lock = threading.Lock() def register(self, conn): q = queue.Queue(maxsize=2) # 只留最新两帧，这是刻意的 with self.lock: self.clients[conn] = q threading.Thread(target=self._pump, args=(conn, q), daemon=True).start() def publish(self, payload: bytes, ts_ms: int, ftype: int): with self.lock: for conn, q in self.clients.items(): try: q.put_nowait((payload, ts_ms, ftype)) except queue.Full: try: q.get_nowait() # 先丢最旧的一帧 except queue.Empty: pass try: q.put_nowait((payload, ts_ms, ftype)) except queue.Full: pass # 丢完还是满就放弃这帧 def _pump(self, conn, q): while True: payload, ts_ms, ftype = q.get() try: send_frame(conn, payload, ts_ms, ftype) except OSError: with self.lock: self.clients.pop(conn, None) return

maxsize=2这个数字不是随手写的。设为 1 的时候，帧到达和发送线程取走之间存在竞态，容易出现"每两帧丢一帧"的偶数帧效应，画面会有节奏地一顿一顿；设到 5 以上，慢客户端积压 5 帧，1080p 下就是 500KB 的内存和一个肉眼可见的延迟阶梯。2～3 是实测下来观感和稳定性比较平衡的区间。

publish里那段"先取再放"是关键：queue.Queue没有"丢弃最旧"的原生语义，用get_nowait腾位置是实现这个语义的最短路径。注意这段在锁内执行，而get是线程安全的，逻辑上不会死锁，因为_pump只调q.get()不碰self.lock之外的东西。

3.3 心跳与断线重连：别让连接假活着

长连接最阴的情况是连接没断但已经不可用：中间设备超时回收、NAT 表项老化、对端网卡休眠，表现是recv一直阻塞，不报错也不来数据，查看端画面定格，用户以为是程序卡死。解药是双向心跳加超时。

import socket, time def keepalive(sock, interval=3.0): while True: try: send_frame(sock, b"", int(time.time() * 1000), FTYPE_HB) except OSError: return time.sleep(interval) def connect_with_retry(addr, retries=0): delay = 1.0 while True: try: s = socket.create_connection(addr, timeout=5) s.settimeout(10) # 10s 收不到任何字节就判死 s.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1) return s except OSError: if retries and delay > 60: raise time.sleep(delay) delay = min(delay * 2, 30) # 指数退避，封顶 30s

三个参数各管一件事。settimeout(10)要大于心跳间隔的三倍，心跳 3 秒一次，10 秒没收到任何数据基本可以确定连接废了，抛socket.timeout让外层走重连。TCP_NODELAY必须开，屏幕帧是小包高频场景，Nagle 算法会把小包攒着发，攒的那几十毫秒在看实时画面时非常明显，属于典型的"玄学延迟"来源之一。退避封顶 30 秒是为了服务端重启时不至于所有客户端同时冲上来。

重连之后的状态要清：查看端上次缓存的上一帧必须扔掉，不复位的话帧差会按旧底图算，接上的瞬间会有一大片区域"没变化"，得等它自己动起来才刷新。

4. 查看端渲染：从字节流还原画面与端到端延迟测量

查看端要做的事看起来只有"收、解、显示"三步，但延迟到底是多少、卡在哪一段，多数实现里是黑匣子。这一章把渲染循环、延迟测量和 Web 端的最低成本方案讲清楚，顺带处理多显示器和 DPI 缩放这两个必然遇到的坐标问题，做完之后你手里就有一条能量化、能定位的链路。

4.1 OpenCV 渲染与端到端延迟

渲染循环里最容易犯的错是在imshow后面加了time.sleep，或者waitKey给了 30ms 想"对齐帧率"。waitKey本身就是事件泵，它既是等待也是刷新，给大了直接串行化整个循环。正确写法是waitKey(1)，让它在收到键事件时立即返回。

import cv2, time, numpy as np def viewer(sock): win = "remote" cv2.namedWindow(win, cv2.WINDOW_NORMAL) # NORMAL 允许拖拽缩放 while True: ftype, ts_ms, payload = recv_frame(sock) if ftype == FTYPE_HB: continue img = cv2.imdecode(np.frombuffer(payload, np.uint8), cv2.IMREAD_COLOR) if img is None: continue # 半帧或坏帧，丢掉不崩 cv2.imshow(win, img) if cv2.waitKey(1) & 0xFF == 27: # ESC 退出 break # 端到端延迟：发送端打的时间戳 vs 本地墙钟 latency = int(time.time() * 1000) - ts_ms print(f"latency={latency}ms ftype={ftype} bytes={len(payload)}")

imdecode出来是 BGR，而采集端切的也是 BGR，两边一致，中间千万不要顺手加一句cvtColor(BGR2RGB)，加了就是红蓝对调，人脸变蓝这种经典事故。latency这个数包含采集耗时、编码耗时、网络往返（单程）、解码和渲染，是真正能拿去和用户感知对标的值。局域网内这套实现正常在 40～90ms，跨公网看链路质量。

单帧延迟要以中位数为准，别看第一帧。第一帧通常包含连接建立和窗口创建的额外开销，能有好几百毫秒，拿它做指标会误判。

4.2 Web 端最低成本方案：MJPEG over HTTP

不想装客户端、只想在浏览器里看的时候，最省事的不是 WebRTC，而是 MJPEG over HTTP：multipart/x-mixed-replace响应，浏览器img标签直接就能渲染，不需要任何前端库。代价是每帧独立编码、压缩率不如帧间编码、不支持音频，但对"看一眼远程屏幕"这个诉求完全够用。

from flask import Flask, Response app = Flask(__name__) source = None # 上游查看连接，由启动流程赋值 def mjpeg_gen(): while True: ftype, ts_ms, payload = recv_frame(source) if ftype == FTYPE_HB or not payload: continue # 每个 part 必须自带 Content-Length，否则浏览器会一直等下一段 yield (b"--frame\r\n" b"Content-Type: image/jpeg\r\n" b"Content-Length: " + str(len(payload)).encode() + b"\r\n\r\n" + payload + b"\r\n") @app.route("/stream") def stream(): return Response(mjpeg_gen(), mimetype="multipart/x-mixed-replace; boundary=frame")

Content-Length这一行是踩过的坑：只写Content-Type也能在某些浏览器里跑，但 Chromium 系在部分版本下会把没有长度声明的 part 当作未完成，画面停住不动，控制台也不报错，极难定位。加上长度声明之后行为就稳定了。

这个方案有个硬限制：multipart是单向推流，浏览器没法往回发控制指令。要发"切换显示器""调整画质"这类命令，得另开一个/control的 POST 接口，别指望在同一条流里做双向。

4.3 多显示器与 DPI 缩放：坐标不对的两个根因

第一根因是选错了 monitor 索引，前面说过monitors[0]是虚拟桌面。第二根因更隐蔽：Windows 在进程未声明 DPI 感知时，会把屏幕坐标按 125%、150% 的缩放比例虚拟化，mss拿到的是缩放后的分辨率，而鼠标坐标是物理像素，两边一混，画面里点的位置和实际落点差出几十像素。

import ctypes, sys def enable_dpi_awareness(): if sys.platform != "win32": return try: # 2 = PER_MONITOR_DPI_AWARE，多屏不同缩放时也能拿到物理像素 ctypes.windll.shcore.SetProcessDpiAwareness(2) except Exception: ctypes.windll.user32.SetProcessDPIAware() # 必须在创建窗口、初始化 mss 之前调用 enable_dpi_awareness()

调用时机是关键，放在mss.mss()之后无效，因为句柄已经把虚拟化后的尺寸记下来了。这段在 Windows 10/11 上都要跑，shcore在更老的系统上可能不存在，所以留了SetProcessDPIAware兜底。这套源码里把它放在main的第一行，就是被这个问题折腾过一次之后定下来的规矩。

5. 排查记录：上线后暴露的五个真问题

这套东西在局域网里跑通只要半天，真正花时间的是在各种机器、各种网络下把它跑稳。下面五条都是实际遇到过、且第一次遇到时完全没有头绪的问题，按"现象 → 原因 → 解决"写，遇到同类症状可以直接对照。

5.1 画面随机花屏、半张图糊掉

现象：查看端每隔几秒出现一次花屏，或者图像上半正常、下半是上一帧的残影，重启连接后好一阵又复发。

原因：接收端用了固定长度recv(65536)，没有按头部声明的长度精确读取。网络好的时候一帧恰好一次到齐，看着正常；网络稍有抖动，一帧被拆成两次到达，第二次recv读到的是下一帧的头部加一部分载荷，整个流从此错位。

解决：改用 3.1 节的recv_exact，绝对不要假设一次recv对应一帧。另外在解码处加if img is None: continue，坏帧丢弃而不是抛异常崩掉整个循环，这样即使错位也只影响一帧。

5.2 连续运行几小时后内存持续上涨

现象：服务端进程内存从 200MB 一路涨到 2GB 以上，最后被系统杀掉，重启后恢复。

原因：多客户端分发时用了无界队列，某个查看端网络变差（或者干脆挂起没关连接），消费速度跟不上生产速度，队列无限堆积。每个元素是一帧 JPEG 字节串，1080p 下 100KB 一帧，一小时能堆出好几个 GB。

解决：队列maxsize设成 2，满了丢最旧。同时在_pump里捕获OSError后主动pop掉客户端，别让死连接永远留在字典里。改完之后内存曲线是平的，代价只是慢客户端帧率下降。

5.3 换了台高分屏机器，点击位置全部偏移

现象：画面能看，但远程控制时点"确定"按钮，实际点到的是它左边偏上几十像素的位置。

原因：进程没有声明 DPI 感知，系统把坐标按 150% 缩放虚拟化，采集拿到的是逻辑分辨率，鼠标注入用的是物理坐标系，两者差了一个缩放系数。

解决：在main一开始调用 4.3 节的enable_dpi_awareness()，并且必须在任何窗口或采集实例创建之前。改完之后mss拿到的宽高和鼠标坐标就一致了。

5.4 本机能连，同事的电脑连不上

现象：服务端在自己机器上127.0.0.1连得好好的，同网段另一台机器连过去一直超时。

原因：bind绑到了127.0.0.1而不是0.0.0.0，或者系统防火墙没放行监听端口。前者的表现是本地全通、外部全断，非常有迷惑性。

解决：监听地址改成0.0.0.0，端口固定一个高位端口并在系统防火墙里显式放行入站。排查顺序是先在服务端netstat -an | grep <端口>确认监听地址，再从对端telnet或nc -vz探端口，两步就能定位是绑定问题还是防火墙问题。

5.5 静止区域长时间不刷新，鼠标划过去才更新

现象：画面大部分内容卡住不动，但一移动鼠标整片区域突然刷新成最新状态。

原因：帧差只传变化块，静止区域的累积误差（比如带轻微动画的网页、时钟秒数、渐变背景的细微抖动）低于阈值 2.0，永远判不出变化，查看端就一直贴着旧底图。

解决：加一个"强制全帧"机制，每 5～10 秒无条件发一帧完整画面，或者在连续 N 帧都没有全帧时触发。这一帧的带宽代价可以忽略，换来的是不会出现"局部冻住"这种让人以为程序挂了的观感问题。这是后悔药，不是优化。

6. 把延迟压进 80ms：buf 复用、编码器替换与授权边界

前面几章把链路跑通了，最后这一步是把它从"能用"推到"用着舒服"。延迟这件事要拆开看，不能笼统地说"优化一下"。这套实现里各环节的耗时占比大致是这样，1080p、帧差命中率 60% 的场景下实测：

编码那块是大头。cv2.imencode内部走的是 OpenCV 自带的 libjpeg-turbo，其实已经不慢了，真正能再提的是参数。质量从 70 降到 60，单帧体积能掉三成，编码时间也线性下降，观感上文档和代码场景几乎看不出区别，照片类画面才会明显。如果目标机器性能很弱，值得上turbojpeg库直接操作 buffer，绕过一次 numpy 到 Mat 的拷贝：

import numpy as np, time # 复用同一个输出 buffer，避免每帧新建 ndarray def make_encoder(quality=60): params = [int(__import__("cv2").IMWRITE_JPEG_QUALITY), quality] import cv2 def encode(bgr): ok, buf = cv2.imencode(".jpg", bgr, params) if not ok: return b"" return buf.tobytes() # tobytes 保留一次拷贝，换来可直接 sendall return encode

params只算一次，不要每帧重建列表，这是很典型的"看着无所谓、实测能吃 1～2ms"的细节。tobytes()这一步的拷贝其实可以省掉，直接buf传给sendall也行，但那样每次都要处理 memoryview 的切片长度，代码可读性下降明显，我在这种量级上一般选择留拷贝。

另一个容易被忽略的是查看端的窗口尺寸。cv2.WINDOW_NORMAL创建的窗口默认按图像大小显示，如果你手动拖大过窗口，OpenCV 每帧都会做一次缩放再绘制，1080p 放大到 4K 窗口，这一下就是 8～15ms。我的习惯是固定窗口大小并在代码里resizeWindow到目标尺寸，让缩放留在硬件路径上。

注意：这里所有优化的前提是链路本身已经在稳定的局域网或可预期的专线上。如果网络单程抖动就有 50ms 以上，前面省下的十几毫秒意义不大，先解决链路。

最后说边界，这不是客套。这类屏幕采集程序在不同系统上有不同的可见性要求，Windows 下有明确的会话与授权机制，Linux 下 X11 和 Wayland 的行为完全不同，Wayland 下常规的屏幕抓取会被限制，需要走对应的门户接口。所以这套源码在采集端启动时强制要求本机用户确认，并且保留了运行日志，谁在什么时候看过哪台机器的屏幕，日志里能查到。我把这条当成不可绕过的实现约束，而不是可选项。

血泪经验是：早期版本图省事，把采集做成随服务静默启动，结果在一台测试机上反复被安全软件拦截，排查了大半天才想明白是"没有可见的授权动作"导致的。从那以后我每次接这类需求，第一步不是写采集，而是先把"谁授权、授权怎么显示、日志落哪"定下来，再动后面的代码。希望你在这块少走一遍我走过的路，希望帮到你。

本文还有配套的精品资源，点击获取