简介：v4l2loopback是Linux内核中的虚拟摄像头驱动模块，加载后会在/dev目录下生成video设备节点，供视频软件、流媒体程序等当作真实摄像头调用。这份资源适合Linux驱动开发者、音视频应用测试人员以及需要模拟视频输入的场景，可用于验证视频采集、推流、录制等功能而无需物理摄像头。压缩包共10个文件，约151KB，主体为驱动C源码、头文件、Makefile构建脚本，以及编译生成的目标文件与静态库文件，覆盖从源码阅读到内核模块编译的关键内容。目前在站内已有235人学习下载，适合想快速获取驱动实现、参考模块加载与权限配置的读者。借助这些源码，开发者可深入理解虚拟视频设备的注册流程与数据传输机制，同时结合描述中提到的/dev/video节点权限设置，在生产环境中更合理地控制设备访问策略，提升视频类应用的开发与调试效率。
1. 视频开发的"隐形输入源"：v4l2loopback到底解决了什么问题
做Linux下视频开发的人，多半都遇到过这种尴尬：手头有一个视频处理程序，想调试输出效果，但既不想开摄像头对着自己，又不想买采集卡连相机；或者你写了一个基于OpenCV的人脸检测脚本，想在系统层面把它变成一路"摄像头信号"给其他软件调用——这时候，v4l2loopback就是那个让你凭空多出一路虚拟视频设备的驱动。
简单说，v4l2loopback是一个Linux内核模块，它创建的不是真实硬件设备，而是V4L2（Video for Linux 2）框架下的虚拟视频设备节点。你可以把任意用户态程序生成的图像数据写入这个虚拟设备，而所有读取该设备的程序（OBS、Zoom、Chrome、ffmpeg等）都会认为这是一路真实存在的摄像头。
我最早接触这个模块，是想在不开真实摄像头的情况下给视频会议软件注入一路自定义画面。当时试用过几个用户态的虚拟摄像头方案，要么延迟高，要么兼容性差，都不如直接上内核模块干净利落。v4l2loopback的巧妙之处在于，它在内核态就把数据通路打通了，用户态程序只需要像写普通文件一样写入数据，不涉及任何协议转换，性能和兼容性都远超那些靠软件模拟USB设备的方案。
这篇文章面向的是谁？如果你在Linux下做视频应用开发、做直播推流、做AI视觉调试，或者单纯想在视频会议里放一个"自定义摄像头"画面——这篇内容都适合你。我会从编译安装、设备配置、数据写入、实测调用到常见坑位，把整个链路讲透，最后还会分享几个我用它实现的进阶玩法。
2. 内核模块的安装与编译：比想象中简单，但有几个坑要先避开
2.1 先看你缺不缺内核头文件
v4l2loopback是一个内核模块，编译它必须有内核头文件。以Ubuntu/Debian系为例，先确认当前内核版本再装对应头文件：
uname -r sudo apt install linux-headers-$(uname -r)如果是Arch系：
sudo pacman -S linux-headers这里最常见的坑是：系统里装了好几个内核版本，apt安装的头文件版本和当前运行的版本不一致，导致编译时找不到build目录。解决方式是严格按照uname -r的输出装，装完以后检查一下：
ls /usr/src/linux-headers-$(uname -r)有输出就说明没问题。如果你用的是树莓派或某些定制内核，头文件可能不在/usr/src下，需要单独确认。
2.2 从源码编译还是直接装包？
两个路径都可行，我分别说清楚：
- 发行版仓库直接安装：Ubuntu/Debian下执行
sudo apt install v4l2loopback-dkms，Fedora下执行sudo dnf install v4l2loopback。这种方式会通过DKMS自动适配内核，升级内核后模块也会自动重建，适合大多数用户。 - 源码编译：如果你需要自己修改模块参数、打补丁或者调试，就clone源码手动编译：
git clone https://github.com/umlaeute/v4l2loopback.git cd v4l2loopback make sudo make install注意：v4l2loopback的master分支直接编译可能会报版本错误，因为内核接口变化频繁。如果make报错，可以切到最新tag再编译：
git checkout v0.12.7 # 以当前最新版为准 make clean && make这一步体现了源码编译的真实状态：这个模块更新速度跟内核API变动强相关，如果你用的是很新的内核，最好去GitHub看一眼最近有没有针对性的commit，别盲目用老版本源码。
2.3 加载模块：基础参数和推荐配置
编译安装完成后，加载模块需要指定虚拟设备的数量和格式选项。我最常用的方式是：
sudo modprobe v4l2loopback video_nr=10,11 card_label="VirtualCam","ScreenShare" exclusive_caps=1各参数含义：
video_nr=：指定创建的虚拟设备编号，10和11分别对应/dev/video10和/dev/video11。不指定的话会自动分配，但自动分配的可预测性差，建议手动指定。card_label=：给虚拟设备起个名字，显示给应用程序的是这个名字。比如设为"VirtualCam"，在OBS或浏览器里看到的就是这个名字。exclusive_caps=1：这个参数非常关键，它让驱动程序在查询设备能力时只报告"视频捕捉"（capture）能力，而隐藏"视频输出"（output）能力。加了这个参数，浏览器、Zoom这类软件才能正常识别虚拟摄像头，不加的话某些应用会认为这个设备不支持采集而直接拒绝使用。
如果你用的是DKMS安装的版本，可能还需要手动加载一遍，或者干脆写进/etc/modules-load.d/里实现开机自动加载：
echo "v4l2loopback" | sudo tee /etc/modules-load.d/v4l2loopback.conf但注意：自动加载只加载模块名，不带参数的话设备编号和名称又是随机的。要想开机就固定参数，需要在/etc/modprobe.d/下建一个配置文件，比如v4l2loopback.conf，写入：
options v4l2loopback video_nr=10,11 card_label="VirtualCam","ScreenShare" exclusive_caps=12.4 模块加载失败的排查思路
模块加载失败是新手最常遇到的问题。报错通常长这样：
modprobe: ERROR: could not insert 'v4l2loopback': Exec format errorExec format error多半是头文件版本不匹配，或者模块和当前内核不是同一版本编译的。用modinfo v4l2loopback查看模块的vermagic，再用uname -r对比内核版本，不一致就重新编译。
另一个常见问题是：
modprobe: ERROR: could not insert 'v4l2loopback': Operation not permitted这基本是Secure Boot在作祟。BIOS里开启Secure Boot后，内核只允许加载有合法签名的模块。临时解决方式是sudo mokutil --disable-validation再重启，或者在BIOS里关掉Secure Boot。更严谨的做法是给模块签名，但那要配置MOK密钥，工程上比较繁琐，个人开发机直接关掉更省事。
3. 数据写入与读取：如何让画面真正"流"进虚拟设备
3.1 标准写入路径：用FFmpeg推送视频流
模块加载成功以后，/dev/video10就出现了。现在的问题是怎么把数据写进去。最直接、也最通用的方式是使用FFmpeg：
ffmpeg -re -i input.mp4 -f v4l2 -pix_fmt yuv420p /dev/video10解释一下这条命令的细节：
-re：按原视频的帧率逐帧读取。不加这个参数FFmpeg会全速推流，视频会被加速播放。-f v4l2：指定输出格式为V4L2设备。-pix_fmt yuv420p：指定像素格式。这是兼容性最好的格式，几乎所有读取端都支持。如果你不指定，FFmpeg可能默认输出yuyv422，也大部分场景能用，遇到兼容性问题时优先试yuv420p。
这条命令跑起来以后，OBS里添加视频采集设备，选择"VirtualCam"，就会看到input.mp4的画面在播放。我在实际测试中，用1080p、30fps的MP4推流，CPU占用率大约在8%左右（i5-9400F），延迟很低，体感在百毫秒级以内。
3.2 进阶写入：用GStreamer实现实时画面注入
FFmpeg适合推文件、推RTSP流，但如果想实时注入屏幕画面，GStreamer是更灵活的方案。比如把当前屏幕实时推入虚拟摄像头：
gst-launch-1.0 ximagesrc ! videoconvert ! video/x-raw,format=I420 ! v4l2sink device=/dev/video10在Wayland环境下，ximagesrc可能失效（Wayland不支持X11的截图协议），需要改用pipewiresrc或写一个PipeWire的Portal调用，这里不展开。另一个实用场景是推一个带透明通道的测试信号：
gst-launch-1.0 videotestsrc pattern=smpte ! video/x-raw,format=I420,width=1280,height=720,framerate=30/1 ! v4l2sink device=/dev/video10videotestsrc的pattern=smpte会输出SMPTE标准测试彩条，这是视频流水线调试中最常见的测试源。如果你在调试图像处理链，用标准测试卡比用真实画面更容易发现色彩、拉伸、隔行问题。
3.3 程序化写入：为什么Python方案更灵活
做AI视觉调试时，单纯的FFmpeg推流不够用，因为你需要动态地把推理结果画在画面上再送出去。此时用Python的pyv4l2库或者直接操作文件描述符是最灵活的方式。
最简单的方式是直接调用FFmpeg的子进程：
import subprocess cmd = [ 'ffmpeg', '-y', '-f', 'rawvideo', '-pix_fmt', 'bgr24', '-s', '1280x720', '-r', '30', '-i', '-', '-f', 'v4l2', '-pix_fmt', 'yuv420p', '/dev/video10' ] proc = subprocess.Popen(cmd, stdin=subprocess.PIPE) # 之后不断把帧写入 proc.stdin这里有几个细节值得注意：
- 输入侧用
-f rawvideo配合-pix_fmt bgr24，这是OpenCV默认的像素格式。如果你直接喂RGB24，OpenCV读入的BGR顺序会被当成RGB，画面颜色就反了。 -pix_fmt bgr24与输出侧yuv420p的像素转换由FFmpeg自动完成，这是它做得相当靠谱的部分，颜色空间转换的准确性远超手写代码。- 实时性上，用stdin管道写入会有一次数据拷贝，但性能影响可以忽略；如果要追求极致性能，就改用共享内存方式，但复杂度会大幅上升，一般场景没必要。
3.4 读取端的注意事项
读取端——也就是作为"消费者"的软件——需要注意三点。
第一，设备调度。v4l2loopback本质上是一路管道，多个进程同时读取时，每个读端拿到的帧是相同的拷贝，但写端只会按一个节奏写入。如果两个软件同时打开虚拟摄像头，它们会竞争帧，可能出现其中一个拿不到新帧的情况。解决办法是给每个用途建一个独立的虚拟设备节点。
第二，格式协商。很多软件在打开摄像头时会和驱动协商分辨率、帧率。v4l2loopback的行为是：当写端先启动并持续写入时，读端会匹配写端的格式；如果读端先打开设备、写端还没启动，读端可能以它自己的偏好格式初始化设备，等写端再写入时格式不匹配，画面会花掉或黑屏。实测中，让写端先启动是避免这类问题的最有效方式。
第三，帧率问题。虚拟摄像头没有硬件的帧率节拍，帧率完全由写端控制。如果写端停止写入，读取端会一直停留在最后一帧。这个特性在某些场景下是"画面定格"，在另一些场景下却是"假死"。如果你需要自动断开，可以周期性检查写端的帧时间戳，超过一定时间没有新帧就提示用户设备失联。
4. 实测场景：从视频会议到直播推流，哪些玩法最实用
4.1 给视频会议软件注入自定义画面
这是v4l2loopback最出圈的用途，也是大多数人第一次接触它的原因。操作链路是：启动虚拟设备 → 用FFmpeg循环推流某个视频文件 → 在会议软件中选择虚拟摄像头。
以Google Meet/Zoom的Linux版为例，实测需要注意：
exclusive_caps=1必须设置。这个参数之前已经提过，在会议软件场景中它几乎是必需的。有些版本如果没有这个参数，软件会报"摄像头被占用"或直接不识别设备。- 分辨率尽量设置为720p或1080p，且要和推流文件的真实分辨率一致。会议软件通常只枚举它支持的格式列表，如果你的虚拟设备上报的格式很怪，软件可能自动选择最低分辨率，画面会模糊。
- 推流文件建议用
-stream_loop -1 -re循环播放：
ffmpeg -re -stream_loop -1 -i conference_background.mp4 -f v4l2 -pix_fmt yuv420p /dev/video10-stream_loop -1让视频无限循环播放，-re保持正常播放速率。这两个参数配合，可以让一个短视频变成永不停歇的"摄像头信号"。
4.2 直播场景：把屏幕内容变成一路"摄像头"
直播平台通常会给你"添加摄像头源"和"添加窗口捕获源"两个选项，但有的时候你希望把一个窗口、一个特定区域甚至一个AI生成的画面当作"摄像头"来用，尤其是做游戏直播时想实现"摄像头画面带特效"的效果。
我的一个实际用法是：用OBS内置的虚拟摄像头插件配合v4l2loopback做多层合成。具体来说，OBS本身有obs-virtualcam插件，它就是基于v4l2loopback实现的（Windows版走的是directshow，Linux版就是v4l2loopback）。但如果你不想开OBS那么重的软件，只想把一片屏幕区域推成摄像头，可以这样：
- 用
ffmpeg -f x11grab抓取屏幕区域：
ffmpeg -f x11grab -video_size 1280x720 -framerate 30 -i :0.0+100,50 -f v4l2 -pix_fmt yuv420p /dev/video10这条命令抓取屏幕中从坐标(100,50)开始、1280x720大小的区域，推入虚拟摄像头。实测在X11环境下，这个方案帧率非常稳定，延迟约200ms，足够用于直播场景的副画面。
Wayland下的X11 grab失效问题，我的替代方案是借助wl-screenrec或grim配合gst-pipewire拿到画面，再导入GStreamer管道写虚拟设备。这套链路配置较繁琐，普通用户建议直接用OBS。
4.3 机器视觉调试：用虚拟摄像头模拟硬件输入流
做视觉算法开发时，最烦的是每次跑测试都要插摄像头或者读文件再改代码参数。用虚拟摄像头可以把"输入源"抽象成系统设备，所有软件一视同仁地当作摄像头读取，这样你就可以在多个软件里复用同一个输入信号。
我之前做的一个项目是边缘设备的实时目标检测，调试时需要同时验证检测算法、录像模块和推流模块。我的做法是：
- 用v4l2loopback创建3个虚拟设备：
/dev/video10、/dev/video11、/dev/video12 - 用FFmpeg把一个预录的测试视频分别推入10和11，供检测模块和录像模块使用
- 用GStreamer把检测结果叠加后的画面推入12，作为最终输出
这样，每个软件只需要配置读取哪一路设备，完全不需要关心数据从哪里来。测试视频可以预先标注好ground truth，跑回归测试时直接用同一个视频流，保证每次测试的输入完全一致。这一点对算法评估特别重要——用真实摄像头测试，画面每次都有细微差异，很难精确定位算法回归。
4.4 音频与虚拟设备联动：容易被忽略的配套方案
v4l2loopback只管视频，但你做视频会议或直播时，音频也是刚需。Linux下对应的音频方案是snd-aloop内核模块，它同样是创建虚拟的ALSA设备。
sudo modprobe snd-aloop加载后会有hw:Loopback,0和hw:Loopback,1两组设备，一组用于播放、一组用于录制，中间由内核自动搬运数据。配合PulseAudio/PipeWire可以做"把系统播放的音乐同时送到虚拟麦克风"的玩法。推荐使用PipeWire的loopback模块：
pw-cli create-node adapter factory.name=support.null-audio-sink node.name=virtual_mic media.class=Audio/Source/Virtual这个方案比snd-aloop更灵活，因为PipeWire可以在应用层做路由，不涉及内核模块，配置起虚拟音频源更方便。不过不同发行版的PipeWire配置差异较大，想一气呵成的话，优先用系统自带的音频配置工具（如pavucontrol）把虚拟音频节点设为默认源，会省不少事。
5. 格式协商与分辨率：为什么画面偶尔会卡住或黑屏
5.1 写端与读端的格式协商机制
我用v4l2loopback踩过最久的坑，是"画面显示10秒后突然黑屏"。当时的现象是：FFmpeg推流正常，OBS里能看到画面，但10秒左右画面冻结，再过几秒OBS提示"设备无信号"。
排查之后发现问题是出在格式协商上。v4l2loopback设备的格式是"最后一次协商的结果"。当读端（OBS）在启动时询问设备支持哪些格式，驱动会返回当前已经协商好的格式；如果写端还没有写入任何数据，设备是没有"当前格式"的，驱动就会返回一个默认列表。此时读端可能选择了一个写端完全不支持的格式——比如设置了30fps，但写端实际推送的是15fps，在帧率不匹配时，驱动内部的缓冲机制会逐渐积累延迟，最终导致画面卡死。
解决方式是两类：一是利用-r参数严格匹配帧率，推流端的输出帧率和虚拟设备的设定帧率保持一致；二是尽量让写端持续写入，不要停停推推——一旦写端停止，读端会认为设备已经断开。
5.2 分辨率不一致导致的花屏问题
另外一个让人抓狂的现象是：偶尔画面会变成"绿屏+花条纹"。这通常是像素格式不匹配。v4l2loopback对写入的像素格式有严格限制，如果你用GStreamer推RGBx格式，而读端要求的是I420，驱动虽然不会直接报错，但输出的画面就会错位。
我的排查建议是：优先统一写端和读端的分辨率、帧率、像素格式三要素。在FFmpeg推流时，显式加上-video_size或-s指定分辨率，不要依赖默认值。在GStreamer推流时，用videoconvert+video/x-raw,format=I420强制转换。我写过一个小工具来持续查看虚拟设备的当前格式参数：
v4l2-ctl --device /dev/video10 --get-fmt-video输出类似：
Format Video Capture: Width/Height : 1920/1080 Pixel Format : 'YU12' (YUV 4:2:0) Field : None Bytes per Line : 1920 Size Image : 3110400看到Pixel Format和你预期的输出格式一致，就可以确定协商成功了。
5.3 多路虚拟设备相互干扰的隔离策略
当你创建多个虚拟设备时，可能遇到"设备ID被占用"或"一个卡死另一个也崩溃"的问题。其实v4l2loopback的每个设备是独立的，不会相互干扰，但有一个隐性问题：如果两个设备共用了同一个card_label，某些应用程序会在内部把它们混淆。
比如你要建一个"绿幕摄像头"和一个"特效摄像头"，千万别把两个设备都命名为VirtualCam。建议命名时带上用途标识：
sudo modprobe -r v4l2loopback sudo modprobe v4l2loopback video_nr=10,11,12 card_label="CamSource","CamEffects","CamOutput" exclusive_caps=1卸载再加载的步骤很关键。v4l2loopback创建的设备节点在模块卸载后会消失，但如果某个程序还在占用这个设备，rmmod会失败。这时需要先关掉所有读端软件，再执行sudo rmmod v4l2loopback，否则会报Device or resource busy。
6. 进阶玩法：把虚拟摄像头变成视觉处理管线的一部分
6.1 用虚拟摄像头串联多个处理节点
一个很有价值的架构是：把虚拟摄像头当作中间数据通道，让多个程序像搭积木一样串联起来。V4L2框架天然支持这种"环形"数据流。
举例来说，一个典型的AI换脸流程可以拆解为：
- 真实摄像头捕获原始画面：
/dev/video0 - 中间处理节点从
/dev/video0读取帧，做推理、叠加效果，写入/dev/video10 - 最终消费端（如OBS、会议软件）从
/dev/video10读取最终画面
好处是每个节点可以独立重启、独立替换。今天用FFmpeg做处理，明天换成自研的Python推理服务，消费端完全不用动。这种解耦方式在长时间运行的服务里价值极大。
我实际搭建过类似的服务，用systemd管理各个节点：
# /etc/systemd/system/vcam-processing.service [Unit] Description=AI processing pipeline for virtual camera After=dev-video10.device [Service] ExecStart=/usr/local/bin/process_video.sh Restart=always RestartSec=3 [Install] WantedBy=multi-user.target搭配Restart=always，就算处理程序崩溃也会自动恢复，整条链路的高可用性就起来了。
6.2 动态切换画面源：虚拟摄像头的热插拔特性
v4l2loopback设备有一个真实摄像头没有的优势：你可以随时更换写端程序，读端完全无感知。比如正在视频会议中，我可以先停止FFmpeg推视频文件的进程，立刻启动GStreamer推实时屏幕画面——会议软件那边看到的只是"摄像头画面变了"，但设备连接从未断开。
这个特性在演示场景特别实用。我做过一个"会议投屏"方案：会议软件连接虚拟摄像头，我用脚本监听某个触发文件，一旦文件更新就切换推流源。开会时只需在后台跑一个切换脚本，就可以让所有人看到实时更新的画面，而不需要共享屏幕——因为共享屏幕需要对方手动点到那个窗口，而虚拟摄像头是"强制全屏"的。
6.3 延迟测试与性能分析：判断虚拟摄像头的真实能力
最后聊一下虚拟摄像头的性能边界。很多人关心延迟，其实v4l2loopback的内核路径延迟极低，大概在几毫秒到十几毫秒之间。主要的延迟来源反而是：写端程序的处理延迟、读端软件的缓冲设置、以及像素格式转换的CPU开销。
我做过一组简单测量：用GStreamer的identity插件加sync=true来标记数据流时间戳，对比推入虚拟摄像头前后的时间差，实测在1080p30下，内核路径的额外延迟在3-8ms之间。这与真实USB摄像头驱动的延迟相当甚至更低。
如果你对延迟有极致要求，建议关注以下几点：
- 写端不要用
-re（它会让输出严格按帧率节拍，可能引入额外等待），让编码器和输入源的自然帧率驱动输出 - 读端关闭多余缓冲，比如OBS里把"缓冲大小"调到最小
- 像素格式优先用
yuv420p或nv12，避免输出端的格式转换
延迟敏感场景（如远程操控、实时渲染）如果发现虚拟摄像头成为瓶颈，先查这几个点，绝大多数情况下不是内核模块的问题，而是用户态程序还在做无谓的拷贝和转换。
7. 我踩过的最深一个坑：exclusive_caps参数引发的"设备不可用"
单独把这个问题拿出来说，是因为它太隐蔽了，而且网上很多教程要么不提，要么只给参数不加说明。
exclusive_caps这个参数在v4l2loopback中的含义是：设备的能力查询结果，要么只报告capture，要么只报告output，二者取其一。默认情况下（exclusive_caps=0），设备同时报告两项能力，表示这是一个"既能输出又能采集"的设备。
问题就出在这里。某些应用程序在枚举设备时，遇到同时具备两种能力的设备会直接判定为"非标准摄像头"，拒绝使用或者只显示不加载。典型的就是Chromium内核的浏览器、Zoom的Linux版、以及部分基于GStreamer的会议应用。
我的经历是这样的：第一次配置虚拟摄像头时没加exclusive_caps，FFmpeg推流正常，v4l2-ctl也能读到格式信息，但Chrome的getUserMedia就是报NotReadableError，OBS能识别但画面黑屏。排查了很久，最后在v4l2loopback的GitHub issue里看到有人提到exclusive_caps，加载时加上exclusive_caps=1，问题立刻消失。
这也是为什么我在前面反复强调这个参数。如果你遇到"设备明明存在、数据也在写、某些软件就是读不到画面"的情况，优先检查加载参数里有没有exclusive_caps=1。
另外一个小技巧：如果你不想重新加载模块，可以临时创建一个只带exclusive功能的设备：
sudo modprobe -r v4l2loopback sudo modprobe v4l2loopback video_nr=10 exclusive_caps=1但这样会丢掉之前的所有虚拟设备配置，所以还是要规划好参数再统一加载。
8. 最后的实操建议：直接照抄的推荐配置
如果你从头开始搭，我推荐这样一套开箱即用的配置。在/etc/modprobe.d/v4l2loopback.conf中写入：
options v4l2loopback video_nr=10,11,12 card_label="VCamMain","VCamScreen","VCamDebug" exclusive_caps=1然后加载：
sudo modprobe v4l2loopback推流一个视频：
ffmpeg -re -stream_loop -1 -i any_video.mp4 -f v4l2 -pix_fmt yuv420p /dev/video10抓取屏幕进第二路设备（X11）：
ffmpeg -f x11grab -video_size 1920x1080 -framerate 30 -i :0.0+0,0 -f v4l2 -pix_fmt yuv420p /dev/video11在OBS中添加视频采集设备，分别选VCamMain和VCamScreen，两路画面就都是"活的"了。
这套配置我自己一直在用，稳定性很好，虚拟设备运行一周以上没有出现过内核崩溃或内存泄漏的迹象。v4l2loopback作为一个内核模块，代码质量相当扎实，但它在设计上依赖用户态程序主动写入数据，所以"写端挂了=摄像头黑屏"这种问题只能靠上层服务的守护机制来解决，模块本身不会为你做保活。
最后再分享一个小技巧：如果你用ffmpeg推流并且希望断流后自动重推，写一个简单的外层循环：
while true; do ffmpeg -re -stream_loop -1 -i input.mp4 -f v4l2 -pix_fmt yuv420p /dev/video10 sleep 1 done这套小脚本在生产环境帮我解决了不少"画面莫名消失"的尴尬时刻，算是最朴素的保活方案了。
本文还有配套的精品资源，点击获取
