企业官网建设流程全解析

家里装了五六路摄像头，海康、大华、小米、萤石各占一半，这大概是很多人开始折腾 go2rtc 的第一推动力。我当时就是被折腾烦了：海康要看海康的客户端，大华网页版每次都要装插件，小米就只能打开 App 等它云端转圈。各路摄像头的视频流本质都是 H.264，偏偏各家协议、端口、地址格式完全不同，最后被迫在手机里装四五个 App 来回切换。

go2rtc 就是为了解决这个割裂局面的。它是一个用 Go 写成的轻量级流媒体服务器，核心能力是把各种来源的摄像头视频流统一接入，再以你想要的协议重新发出去：浏览器里用 WebRTC 低延迟看，老系统里接 RTSP/RTMP，网页嵌入用 HLS 或 MJPEG，API 侧则是一堆现成的 HTTP 接口。最方便的一点是它官方提供了 Docker 镜像，部署起来比编译源码省心太多。

这篇文章就按我实际项目里一步步做的顺序来写：先讲明白为什么需要它，再讲 Docker 怎么部署，然后把海康、大华、小米、树莓派 CSI、USB 摄像头这些不同来源的接入配置逐个过一遍，最后聊聊低延迟播放和录像落盘的方案。适合有摄像头想统一接入的人、NAS 玩家，以及做智能车/机器人需要多路视频调试的开发者参考。

1. 先把场景说清楚：为什么需要一个多协议流媒体层

1.1 摄像头生态的割裂远比想象中严重

海康有海康的 SDK 和 Hik-Connect，大华有乐橙和 DMSS，萤石要装萤石云，小米绑死米家生态。这些平台互不通信，接口规范也不同。最讽刺的是，绝大多数网络摄像头底层都支持 RTSP 协议，你只要知道用户名密码，用 VLC 就能直接打开视频流。但厂商偏不在自己的客户端里给你一个标准入口，而是想方设法把你拉进云平台。

再看设备形态就更乱了：有 PoE 供电的枪机，有 Wi-Fi 家用云台，有树莓派上的 CSI 摄像头模块（比如 ov5647），有机器人上插的 USB 摄像头，甚至还有 ESP32-S3 通过 USB 转出来的 UVC 视频节点。这些设备有的走 RTSP，有的走 ONVIF，有的根本没有网络协议栈，只是 Linux 下的一个/dev/video0。

在这样的环境里做统一视频平台，最核心的问题不是"要不要上云"，而是"怎么先把这些协议全都消化掉"。go2rtc 的角色就是这样一个多协议消化层。

1.2 go2rtc 的定位：所有视频流的中转站

go2rtc 的名字很直白：go 语言的 RTSP/RTC 服务器。它支持的输入源包括：

• RTSP 流（海康、大华、萤石、TP-LINK 等绝大多数 IPC/NVR 的取流地址）
• RTMP 流（推流设备、OBS 等）
• ONVIF Profile S/T 摄像头（可自动发现局域网内的 ONVIF 设备）
• 本地视频文件（测试时特别方便）
• Linux V4L2 设备（USB 摄像头、树莓派摄像头等）
• HTTPS/UDP 直播流、HLS 地址，甚至是某些云平台的拉流 URL

支持的输出协议更丰富：WebRTC、RTSP、RTMP、HLS、MP4 片段、MJPEG、FLV、fMP4。也就是说，一个好比的摄像头取到流之后，你想接着把这个流以什么形式给别人，全由 go2rtc 决定。

它做的是"接入+转发"，而不是"录制+重压缩"。所以它的资源占用非常低，在树莓派或 NAS 的 Docker 里跑起来很轻松，单进程内存占用基本保持在几十 MB 级别。

1.3 和 NVR、录像软件的边界：go2rtc 不是用来取代录像机的

需要说明一个很关键的边界：go2rtc 不负责录像持久化，也不负责运动检测、人脸识别那些智能分析。它是流媒体代理层，负责把摄像头流"接进来、转出去"，让下游的消费方能够方便地使用这些视频流。

所以常见架构是：

摄像头 RTSP 流 ↓ go2rtc 统一接入并转换协议 ↓ 浏览器 WebRTC 实时预览 ↓ Frigate / 群晖 Surveillance / FFmpeg 录像

我自己项目里就是 go2rtc 做实时预览分发，Frigate 消费 go2rtc 转出来的 RTSP 流做检测和录像存储。大家各管一段，职责清晰。不要把录像和存储这两件事压在 go2rtc 上，它真的不擅长，也没必要。

2. Docker 部署：从一条命令到 docker compose

2.1 最小启动命令和一个能打开的后台

go2rtc 的官方镜像写得比较省心，数据目录就一个配置文件夹。我第一回测试用的是一条最简单的命令：

docker run -d \ --name go2rtc \ --restart=always \ -p 1984:1984 \ -p 8554:8554 \ -p 1935:1935 \ -v /opt/go2rtc:/config \ alexxit/go2rtc:latest

启动后浏览器直接打开http://你的IP:1984，看到的就是 go2rtc 的 Web 管理界面。界面上能做的事不少：

• 在顶部添加需要接入的流地址
• 查看每个流的参数与状态
• 点击预览，实测时 WebRTC 延迟基本在 200~500ms 内
• 查看可用的 HTTP API 路由

端口这块说明一下：1984 是 Web 界面和 HTTP API 的默认端口，8554 是 go2rtc 对外提供的 RTSP 服务端口，1935 是 RTMP 的默认端口。go2rtc 还会用到 WebRTC 的动态 UDP 端口，如果跑在桥接模式 Docker 里，需要按实际需要把 UDP 端口范围也映射出来；更省心的办法是用 host 网络，后面单独说。

2.2 镜像拉取慢先解决，别等到部署时才卡住

Docker 镜像下载慢是很多人的第一道坎，尤其在国内网络环境下拉 go2rtc 这种镜像，有时候要等几分钟甚至超时。标准的处理办法是配置 registry mirror，也就是镜像加速源。改/etc/docker/daemon.json：

{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.com", "https://docker.mirrors.ustc.edu.cn" ] }

改完重启 Docker：

systemctl restart docker

然后再执行 docker pull 或直接 run，速度会明显提升。这个配置只影响 Docker Hub 镜像拉取，不影响容器运行，随手开好能省不少事。

2.3 用 docker compose 固化你的部署

命令行跑起来只是起步，真正要长期稳定运行，我强烈建议用 docker compose 把配置固化。我的做法是单独建一个目录，比如~/docker/go2rtc，里面放一个docker-compose.yml：

services: go2rtc: image: alexxit/go2rtc:latest container_name: go2rtc restart: always ports: - "1984:1984" - "8554:8554" - "1935:1935" volumes: - ./go2rtc.yaml:/config/go2rtc.yaml - ./recordings:/recordings environment: - TZ=Asia/Shanghai

目录里的go2rtc.yaml就是全局配置。go2rtc 会自动读取这个文件里的流定义，里面写完摄像头配置以后，即使容器重启，所有接入配置也不会丢。

另外加了个recordings目录挂载进去，虽然 go2rtc 本身不录像，但后面要用 ffmpeg 或者其他容器落盘时，这个目录可以直接复用。

启动关闭的常用操作：

docker compose up -d docker compose logs -f go2rtc docker compose restart go2rtc docker compose down

2.4 host 网络什么时候更好

桥接模式是最通用的部署方式，但如果你打算依赖 go2rtc 的 ONVIF 自动发现摄像头，或者摄像头在另一个网段需要靠组播广播发现，建议直接在 Linux 上用 host 网络：

docker run -d \ --name go2rtc \ --restart=always \ --network host \ -v /opt/go2rtc:/config \ alexxit/go2rtc:latest

host 模式下容器直接共享宿主机网络栈，没有端口映射，WebRTC 的 UDP 端口也能直接被外部访问到，某些跨网段组播和 mDNS 发现的场景会顺畅很多。但注意，host 网络只在 Linux 下有效，Windows 和 macOS 的 Docker Desktop 不支持。如果你的 go2rtc 计划跑在群晖 NAS 或树莓派上，那基本都是 Linux，可以放心用 host。

我个人的选型经验是：单纯接几路 RTSP 给浏览器看，桥接模式加端口映射就够；一旦涉及 ONVIF 自动发现、多网段发现、WebRTC 打通，优先 host。

3. 摄像头连接配置：RTSP、ONVIF 和那些老设备的信令

3.1 海康、大华、常规 RTSP 地址怎么写

接入网络摄像头最常用的是 RTSP。不同厂商的 RTSP 地址格式差别很大，这里给出最常见的三个例子。

海康威视（包括萤石部分型号）一般是这样：

rtsp://admin:password@192.168.1.64:554/Streaming/Channels/101

末尾的 101 代表通道 1 主码流，102 代表通道 1 子码流。如果摄像头有多个通道，依次是 201、202、301、302 等。

大华的一般格式是这样：

rtsp://admin:password@192.168.1.65:554/cam/realmonitor?channel=1&subtype=0

channel 是通道号，subtype 为 0 是主码流，为 1 是子码流。TP-LINK 的则类似：

rtsp://admin:password@192.168.1.66:554/stream1

在 go2rtc 的配置里，这些地址直接填进streams段落即可：

streams: haike_main: - "rtsp://admin:password@192.168.1.64:554/Streaming/Channels/101" haike_sub: - "rtsp://admin:password@192.168.1.64:554/Streaming/Channels/102" dahua_main: - "rtsp://admin:password@192.168.1.65:554/cam/realmonitor?channel=1&subtype=0"

go2rtc 的 streams 支持写一个名字对应一个或一组地址，多个地址时会自动在主源断掉后切换到备用源。如果你的摄像头有主码流和子码流，建议分开定义为两个流，方便在不同带宽场景下调用。

3.2 摄像头没有激活或忘记密码时先做什么

大华摄像头第一次使用必须激活，你不激活它连 RTSP 取流都不开放。所谓激活，就是通过大华的官网工具或 Web 界面给摄像头设置一个管理员密码。新买的大华设备插上网线进它的默认 IP，浏览器会先跳到激活页面，这时候千万别直接关掉。

海康的老设备也是类似，默认 IP 通常是 192.168.1.64，需要用 SADP 这个工具扫描局域网内的设备，然后改 IP、激活、设置密码。我之前帮朋友装一台旧海康，怎么都拉不到流，最后发现是设备停在出厂状态压根没激活。

密码搞忘了也别慌，海康大华都支持通过硬件恢复按钮重置，但重置会清掉所有配置，摄像头 IP 会回落到默认值。这一步完成后，再去 go2rtc 里填 RTSP 地址才有意义。

如果你连密码都还没设置好，看到摄像头画面是灰的，不要调 go2rtc，先回到设备供应商的工具里把摄 像头基础状态弄干净。

3.3 跨网段取流：让 go2rtc 驻留在有路由的网段

很多人遇到"海康摄像头跨地址进行硬盘录像机"的问题，本质是网络可达性问题。举个例子，录像机在 192.168.50.x 网段，摄像头在 192.168.1.x 网段，两个网段之间如果没配置静态路由或者 VLAN 互通，那无论你怎么填 RTSP 地址，流都过不来。

go2rtc 本身的处理能力再强，也只能拉"它自己能访问到的地址"。所以跨网段场景下第一个思路是让 go2rtc 这台机器能路由到摄像头网段。可以在宿主机上加多个网卡，一个连摄像头网段，一个连办公网段；或者在上游路由器做静态路由。然后 go2rtc 配两条路由指向不同网段，它就能把多个网段的摄像头流都拉回来。

第二个思路是用 Docker macvlan 网络，让 go2rtc 容器直接绑定到摄像头所在的物理网段，分配一个同网段 IP。这种做法在网络隔离比较严格的园区里很实用，因为容器不再是跨越三层去取流，而是在二层直接面对摄像头。配置 macvlan 需要确认宿主机网卡支持，并且 macvlan 网络不能让宿主机直接与容器互通，所以通常只作为接入专项使用。

还有第三个思路比较取巧：既然 go2rtc 支持多个实例，那就在每个摄像头网段各部署一个 go2rtc，然后让中心节点去拉各网段 go2rtc 转出来的 RTSP 流。相当于用多个轻量代理把网络打通，这个方案我在多站点项目里用过，部署成本低，排查也直观。

3.4 本地视频源：树莓派 CSI、V4L2 USB 摄像头

如果你的"摄像头"不是网络摄像头，而是树莓派上的 CSI 接口摄像头，或者是智能小车上的 USB 摄像头，go2rtc 也能处理。在 Linux 系统里，这些设备最终都会映射成一个视频设备节点，也就是/dev/video0。

go2rtc 支持 V4L2 输入源，配置示例：

streams: usb_camera: - "v4l2:/dev/video0" rpi_csi: - "libcamera:0"

v4l2适用于 USB 摄像头（包括常见的 ESP32-S3 USB 摄像头模块）和很多支持 UVC 协议的摄像头；libcamera主要面向树莓派 CSI 接口的摄像头，比如 ov5647 模块。要注意的是，在 Docker 里要访问这些设备，必须把宿主机设备映射进容器。用 docker run 时加上：

--device /dev/video0:/dev/video0

用 docker compose 时写：

devices: - "/dev/video0:/dev/video0"

少了这一步，容器里根本看不到物理设备，go2rtc 会一直报打开设备失败。树莓派的 CSI 摄像头如果你用的是较新的系统，还可能需要配合 libcamera-apps 先确认设备能正常出图，再接进 go2rtc。

4. 浏览器低延迟播放：WebRTC、HLS、MJPEG 到底选哪个

4.1 为什么浏览器不能直接播 RTSP

视频流进了 go2rtc 之后，摆在面前的下一个问题是：怎么让用户在浏览器里直接看，而不装任何插件。RTSP 不是浏览器原生支持的协议，哪怕是 Chrome 也不会内置 RTSP 播放能力。过去大华、海康的网页端都要求装 ActiveX 插件，换到非 IE 浏览器就抓瞎。HLS 和 WebRTC 没有这个问题。

go2rtc 支持把同一个源转换成多种输出格式，你按使用场景挑选就行。不需要挨个配置，go2rtc 会自动根据请求的 API 路径做转换。

最简单的是直接在 Web 界面里点播放，go2rtc 会优先尝试使用 WebRTC 播放，如果网络环境不允许，会回退到其他方式。你不需要手动选择协议，这一点对新手很友好。

4.2 go2rtc 的输出通道

对于想在别的页面或系统里嵌入播放的场景，go2rtc 提供了一批 HTTP API 地址。假设你已经配置了一个名为cam1的流：

HLS 播放地址：

http://192.168.1.100:1984/api/hls/cam1.m3u8

MJPEG 播放地址：

http://192.168.1.100:1984/api/mjpeg?src=cam1

MP4/fMP4 播放地址：

http://192.168.1.100:1984/api/mp4?src=cam1

RTSP 输出地址（给其他录像机或软件消费）：

rtsp://192.168.1.100:8554/cam1

RTMP 输出地址：

rtmp://192.168.1.100:1935/cam1

HLS 的兼容性最好，几乎所有浏览器、手机端播放器都能直接播放，代价是延迟一般在 2~5 秒，如果只是监控回看或近距离查看，完全够用。MJPEG 是逐帧 JPEG 图片流，兼容性极强，很多老旧的监控面板协议都认它，但带宽占用大、画面更新率有限，适合做缩略图或者嵌入式老系统对接。

4.3 WebRTC 的低延迟表现和实际优化

如果你需要低延迟播放，比如门铃、看护、远程操纵机器人这种场景，建议用 WebRTC。WebRTC 基于 UDP 传输，配合 SRTP 加密，在局域网内延迟通常能做到 200ms 到 500ms，这个体感基本就是"实时"了。

go2rtc 的 Web UI 默认就会用 WebRTC 来播放，如果你要在自己的页面里嵌入，可以调用 go2rtc 的 WebRTC API。我这里先给一个思路：前端页面通过 HTTP API 发起 WebRTC 请求，拿到 SDP 后交给 go2rtc 建立连接。

如果 WebRTC 总是连接不上，先排查三件事：

• 查看浏览器控制台有没有 ICE 失败记录
• go2rtc 所在机器的 UDP 端口是否被防火墙拦截
• 容器是否做了正确的 UDP 端口映射

跨公网使用时，WebRTC 需要 STUN 服务器配合网络地址转换。go2rtc 的配置文件里可以指定 ICE 服务器：

webrtc: ice_servers: - stun:stun.l.google.com:19302

STUN 只是让双方找到可用的公网路径，并不像有些人想的那样是媒体数据经过的中转服务器，所以延时开销很小。

5. 一个真实的接入案例：小米、海康、大华共用一个页面

5.1 配置清单和逐条解释

我实际项目里有一个 "all-cams" 配置，把小米、海康、大华三家的摄像头都收了进来。先说小米的问题：小米家用摄像头（特别是国内版）对标准 RTSP 支持很差，有些型号只有通过米家 App 或者云存储才能看，好在部分海外版和部分新固件开放了 ONVIF 或 RTSP。我的这台小米智能摄像头恰好支持 RTSP，固件设置里开启"局域网访问"后就能拿到取流地址。

另外小米摄像头的 ONVIF 能力是可以通过搜索引擎查到社区反馈的，配置前先在局域网扫一下是否有开放 8000 端口，有就说明 ONVIF 服务起来了。如果完全找不到，那只能走米家 App，go2rtc 也救不了它。

完整示例配置如下：

streams: xiaomi: - "rtsp://xiaomi_user:pass@192.168.1.70:554/stream0" haike_nvr: - "rtsp://admin:pass@192.168.1.64:554/Streaming/Channels/101" - "rtsp://admin:pass@192.168.1.64:554/Streaming/Channels/102" dahua_ptz: - "rtsp://admin:pass@192.168.1.65:554/cam/realmonitor?channel=1&subtype=0"

我在这里把海康 NVR 的 101 和 102 同时写在了haike_nvr下面，这样 go2rtc 会在主码流出问题时自动尝试子码流。虽然不是严格的双源备份，但至少提高了稳定性。实际测试中，如果 NVR 主码流带宽过高，我也经常会主动去请求 102 子码流作为低延迟预览源。

5.2 多路画面批量预览

配置好之后，不需要再做任何前端开发，直接在浏览器里打开 go2rtc 的 Web UI，左侧能看到已配置的所有流，点哪一个都会直接播放。如果要在同一个页面里看多路画面，技术上有两种方案。

第一种是直接打开多个标签页，每个标签页指向不同的流地址。这个操作最简单，缺点是浏览器多进程内存占用高。

第二种是把 go2rtc 的播放页面通过 iframe 嵌入你自己的监控面板。比如：

<iframe src="http://192.168.1.100:1984/stream.html?src=xiaomi" width="640" height="360"></iframe> <iframe src="http://192.168.1.100:1984/stream.html?src=haike_nvr" width="640" height="360"></iframe>

组装一个 2x2 的网格页面，就能同时看到多路画面。Home Assistant 里也可以直接通过 iframe 卡片把这个页面嵌进去，这样手机端、PC 端都能在一个面板里管理全部摄像头了。

5.3 录像和存储：go2rtc 负责转发，Frigate 负责记录

很多 NAS 用户希望把摄像头录像存到大容量存储里。go2rtc 本身不处理录像，但它和其他录像系统配合得很好。我目前使用的方案是 go2rtc + Frigate，Frigate 从 go2rtc 的 RTSP 输出口拉流录制，存储目录挂载到 NAS。

docker-compose 里大致这样：

services: go2rtc: image: alexxit/go2rtc:latest restart: always ports: - "1984:1984" - "8554:8554" - "1935:1935" volumes: - ./go2rtc.yaml:/config/go2rtc.yaml frigate: image: ghcr.io/blakeblackshear/frigate:stable restart: always volumes: - ./frigate.yml:/config/config.yml - /mnt/nas/recordings:/media/frigate devices: - "/dev/video0:/dev/video0" ports: - "5000:5000"

Frigate 的配置里，摄像头源直接指向 go2rtc 转出来的 RTSP 地址，比如rtsp://go2rtc:8554/haike_nvr。这样 go2rtc 负责把多个摄像头协议统一转成 RTSP，Frigate 只消费这一种协议，稳定性会好很多。

有的同学直接用 FFmpeg 循环录像，也是一种方案：

ffmpeg -i "rtsp://192.168.1.100:8554/haike_nvr" \ -c copy -f segment -segment_time 3600 -reset_timestamps 1 \ /recordings/haike_%Y%m%d_%H%M.mp4

segment_time 控制单个录像文件的时长。之前有朋友问"老摄像头存储大文件大的话怎么弄"，其实就是把切片时长从 3600 秒调小，比如 600 秒或 300 秒，这样每个文件体积更小，好管理也方便按时间段回看。

6. 部署后你必须知道的调优和安全注意点

6.1 主码流/子码流切换与带宽计算

很多人上来就全部用主码流接入，结果 8 路 4K 摄像头全部拉主码流，交换机先扛不住了。先算一笔账：单路 4K 主码流大约 8~12Mbps，8 路就是 64~96Mbps，接近千兆网卡的极限，再加上 NVR 录像、NAS 备份，链路带宽瞬间被打爆。

建议分场景用流：

• 实时预览和低延迟播放：优先使用子码流，一般 720P/1080P 在 1~3Mbps，多路画面很流畅
• 重要区域录像：用主码流录制，保证细节
• 公网或弱网下的远程查看：只开子码流
• 同一路摄像头同时有人查看和录像时：用 go2rtc 把子码流用于实时预览，主码流交给录像服务消费

go2rtc 有一个很有用的点：你可以在 Web UI 或 API 里针对不同消费方选择不同的源。一个摄像头地址可以是子码流，录制侧可以单独引用主码流，互不干扰。

6.2 常见故障：卡顿、延迟、摄像头掉线重连

接入后最常见的坑有三个。

第一是密码或地址里的特殊字符导致拉流失败。比如密码里带@、#、/这类特殊字符，URL 解析会错位。解决方式是先用工具把特殊字符做 URL 编码再填入。比如密码原本是abc@123，要写成abc%40123。

第二是摄像头反复掉线。这可能是摄像头端 RTSP 连接数限制导致的，很多低端摄像头只允许同时建立 1~2 路 RTSP 会话。解决办法是不要用多个服务同时去拉同一台摄像头的 RTSP，统一通过 go2rtc 拉流，其他消费方都从 go2rtc 的转出地址取流，这样摄像头侧只有 go2rtc 这一个会话。

第三是 NTP 时间不同步。有些摄像头时钟不准，导致 ONVIF 事件时间、录像时间轴全部乱掉。接入前先确认摄像头开了 NTP 校准，并且 Docker 容器里也设置了正确的时区。前面 compose 里的TZ=Asia/Shanghai就是干这个的。

6.3 不要在公网裸奔：go2rtc 的认证和反代

go2rtc 默认没有较强的认证机制，Web UI 和 API 一旦暴露到公网，等于把摄像头画面直接送给路人。这是绝对不能忽略的事情。

正确的远程访问姿势是在 go2rtc 前面加一层 Nginx/Caddy 反向代理，并开启 Basic Auth 或更严格的身份认证。一个很基本的 Nginx 反代配置片段大概是：

location / { proxy_pass http://127.0.0.1:1984; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.htpasswd; }

用htpasswd生成账号密码文件，然后只把反代端口暴露给需要访问的人。如果只是局域网内使用，尽量把 go2rtc 的 1984 端口绑定在内网 IP 或仅限内网访问，不建议直接写0.0.0.0:1984映射到公网。

另外，如果摄像头本身有 ONVIF 的 Web 服务端口，不要把它和 go2rtc 一起暴露出去。ONVIF 设备默认端口（8000、80、554）在公网裸奔非常危险，特别是有些摄像头还开着弱口令。重要的事再说一遍：go2rtc 只在内网取流，暴露出去的只有经过反代保护的画面页面。

6.4 Docker 更新、备份和迁移

go2rtc 的更新频率不算高，但隔几个月升级一次也很正常。升级前先备份配置文件：

cp /opt/go2rtc/go2rtc.yaml /opt/go2rtc/go2rtc.yaml.bak docker compose pull docker compose up -d

如果新版本出了问题，恢复也很简单：直接把配置文件和镜像回退到旧版本即可。配置文件是 go2rtc 唯一的持久化状态，流定义、日志级别、API 设置全在里面，日常备份这一个文件就够。

迁移到新机器时，同样只要把go2rtc.yaml和 compose 文件复制过去，再重新docker compose up -d就能无缝恢复。我在树莓派和 NAS 之间迁移过一次，整个过程没超过五分钟。

回到最开始那个问题：为什么要折腾 go2rtc？说白了我只是想在一个网页里把所有摄像头看完，不用为每一路摄像头的牌子单独记一个 App 地址。做完这个项目之后，我对这套架构最满意的一点是它把"摄像头接入"这件事从各家厂商的封闭生态里抽离了出来，全部归口到一个标准协议层。以后再买摄像头，不用再关心它到底哪家的，只要能出 RTSP 或者能被 ONVIF 发现，就能直接并进这个平台。如果让我重新部署一遍，我一定先把网段规划和摄像头激活状态检查做完，再去写 go2rtc 的配置，这会少走很多弯路。