Python定时截屏+Pillow：定时循环、图像处理与稳定运行

1. 先想清楚：定时截屏这个需求到底在解决什么

“Python版_自动定时截屏_PIL”这个标题，第一眼看上去像个小工具，但我在实际项目里用它解决的从来不是“截个图”这么简单的事。定时截屏本质上是对一个会随时间变化的屏幕状态做周期性采样，它属于“无人值守的视觉记录”这一类需求。比如长时间跑一个数据处理任务，想回头看中间过程有没有异常弹窗；比如做某个软件的自动化流程验证，需要每隔几分钟留一张证据图；再比如盯着一个监控面板，把关键数值的变化趋势以图片形式归档。这些事情共同点很明确：人不方便一直坐在屏幕前，但又必须留下可供回溯的画面证据。

这个小项目的核心关键词有三个层次。自动定时解决的是“什么时候拍”的问题，它决定了整个工具的节奏和资源占用；截屏解决的是“拍什么、怎么拍”的问题，涉及屏幕坐标系、多显示器、DPI缩放这些容易被忽略的细节；PIL（目前主流安装的是 Pillow 分支）解决的是“拍下来之后怎么处理、怎么存”的问题，包括图片格式选择、压缩质量控制、文件命名与归档。很多人做这类工具时只盯着“截屏”两个字，写完发现跑一晚上硬盘爆了，或者第二天发现截到的全是黑屏——问题都不在截屏本身，而在定时策略和图像处理环节。

值得先说清楚的是适用范围和人群。这个方案适合有一点 Python 基础、能看懂函数和循环的人；适合需要在本地机器上做事、不需要上传云端的人；适合希望工具足够轻、代码总共不到一百行、随时能改的人。它不适合需要跨网络采集、需要高帧率录屏、需要毫秒级精度的场景，那些场景应该直接上录屏方案或者专业的采集硬件。我后面所有内容都围绕“单机、低频、长时间运行”这个定位展开，因为这个定位才符合“定时截屏 + PIL”这个组合最真实的落地面貌。

还有一个前提要摆在最前面：定时截屏天然带有隐私风险。屏幕上可能出现聊天窗口、邮件内容、文档草稿。所以我在自己写的每一版截图工具里，第一件事就是明确存储路径和自动清理策略，而不是先让程序跑起来再说。这不是啰嗦，这是我在真实使用中吃过教训的地方，后面第4节会专门写这个坑。

2. 整体设计与技术选型：为什么是 PIL 加上时间循环

2.1 三层结构：抓取、处理、归档各管一件事

我习惯把这个工具拆成三层。第一层是抓屏层，负责从屏幕拿到原始像素数据，这一层只管“拿到”，不管存成什么格式。第二层是处理层，用 PIL/Pillow 对图像做必要的加工，比如缩放、格式转换、加水印式的时间标记、可选的质量压缩。第三层是归档层，负责命名、落盘、清理旧文件。三层分开写的好处非常实际：你以后想把抓屏换成别的库，或者想把存储从本地改成别的目录结构，改动只落在一层里，不会牵一发动全身。

很多新手写这类工具时容易写成一个大函数，抓完图直接save()完事，一开始能跑，一旦需求变成“每隔五分钟拍一次，保留最近三天，文件名带上时间”，就会陷入反复改、越改越乱的境地。分层不是为了显得专业，是为了让你两周后回来改代码时还能看懂自己写了什么。我见过不少人把定时截屏工具的定时逻辑和保存逻辑缠在一起，结果想调整间隔时找不到该改哪一行，直接重写了整个脚本。

具体到职责划分，抓屏层我会封装成一个capture()函数，只返回一个 PIL 的 Image 对象；处理层是一个process(img)函数，可返回也可能返回新的对象；归档层是save(img)，只关心路径和文件名。这三层之间没有共享的全局状态，所有参数通过函数入参传递。这样做的直接收益是单元测试变得可行——你可以手动构造一个 Image 对象去测归档逻辑，不用真的截一张图。

2.2 抓屏库的取舍：为什么 PIL 本身抓不了屏

这里有个常见误解需要先纠正：PIL/Pillow 自己不具备截屏能力，它只负责图像处理。市面上所有“PIL 截屏”的说法，其实都是“用某个抓屏库拿到画面，再交给 PIL 处理”。常见的抓屏方案有几类，各有明确适用边界。

第一类是系统自带的命令行工具或系统 API。有些系统提供截图命令，可以带参数直接存文件，好处是零依赖、极其稳定，坏处是每次调用要起一个外部进程，开销偏大，而且很难拿到“未压缩的原始画面”去做后续处理。第二类是第三方抓屏库，比如某些专门做屏幕采集的包，装完之后一行调用就能拿到整个屏幕的画面对象，速度比起进程快，也方便和 PIL 无缝对接。第三类是更底层的图形接口调用，性能好、可控性强，但代码复杂度和平台适配成本高，做这种小工具完全没必要。

我的选择逻辑很朴素：优先用系统自带能力，其次用轻量第三方库，尽量不碰底层接口。理由是这类工具本身对帧率没有要求（几分钟一次），性能不是瓶颈，稳定和一键可复现才是。用第三方库的前提是它在目标机器上装得顺利——这一点很重要，我在不同机器上装同名的抓屏库，遇到过编译失败、依赖缺失的各种情况，所以最终我会留一个“命令行工具兜底”的分支，确保即使库装不上，工具仍然能跑。

下面的对比表是我自己在选型时整理的口径，供参考。

需要强调的是，表中“依赖成本”这一列是我自己最看重的。定时截屏工具往往要在别人的机器上、或者一台长期运行的老机器上部署，安装步骤越少越不容易出问题。我最终的做法是：抓屏首选第三方库，同时代码里保留一个可切换的配置项，一旦库不可用自动降级到命令行方案，日志里打一行提示。这样同一个脚本在两种环境下都能活。

2.3 为什么用 Pillow 而不是自己拼字节

有人会问，既然只是保存图片，为什么非要引入 Pillow？直接写文件不行吗？这涉及一个很实际的点：抓屏库返回的对象不一定能直接存成标准图片文件。有些返回的是原始像素缓冲区，需要自己做格式封装；有些返回的是特定格式的编码数据，改不了质量参数。Pillow 在这里的价值是把各种来源的图像对象统一成一个稳定的Image接口，之后格式转换、缩放、质量压缩、加文字标记全部有现成方法。

Pillow 里我实际用得最多的几个能力，按使用频率排序大概是：save()的格式与质量参数、resize()的缩放、convert()的像素模式转换、ImageDraw系列加文字和时间戳。这里面最容易被忽略的是convert()——不同抓屏源返回的像素模式可能不同，有的带透明度通道，存成 JPEG 时会直接报错。我在第一次遇到这个报错时花了些时间才发现是模式问题，后来固定成在保存前先convert("RGB")一步，问题就消失了。

注意：Pillow 是老 PIL 的社区延续分支，现在安装都装 Pillow，代码里的导入名仍是PIL。网上有些老教程写pip install PIL，那个包早就不维护了，装不上是正常的，不要在这个问题上耗时间。

2.4 《定时》用循环还是用调度器

定时这块，最直观的写法是while True加time.sleep()。这种做法简单、依赖为零，对“单任务、固定间隔”的需求完全够用。缺点是睡眠期间无法响应退出信号之外的任何变化，而且如果某次截屏耗时较长，间隔会被悄悄拖长。另一个选择是引入调度库，可以做复杂的时间表（比如工作日每十分钟、周末每小时）、任务并发、错过补偿，但代价是多一个依赖和一套学习成本。

我的选择是：默认用time.sleep()的死循环，但把间隔抽成配置，并在每轮循环里记录实际时间戳。这不是偷懒，而是刻意取舍。定时截屏工具最需要的是“可预测、可调试”，调度库带来的是灵活性，但也会让“程序到底几点跑了一次”这件事变得不那么直观。用循环的话，我在日志里打一行开始时间、一行结束时间，对着看就知道有没有漂移。

不过循环写法有个必须处理的问题：间隔不能被截屏耗时侵蚀。如果你写sleep(300)而截屏加保存花了 8 秒，实际周期是 308 秒，跑一整天下来偏移会累积到十几分钟。正确做法是记录本轮开始时间，算出本轮已耗时，下一轮睡眠时长 = 目标间隔 - 已耗时，如果已耗时超过间隔则直接进入下一轮并在日志里告警。这个细节决定了长时间运行的工具是“大致准时”还是“越来越不准”。

3. 核心细节拆解：定时、抓屏、保存里那些真正会咬人的地方

3.1 间隔参数怎么算：从使用目的反推

间隔不该凭感觉定，应该从“你想看到什么”反推。比如你要记录一个跑 6 小时的数据处理任务，希望中间状态大致连续，那 5 分钟一张、共 72 张，这个密度足够还原过程，文件量和存储占用也可控。如果你要盯一个持续两天的监控面板，希望看到趋势而不是细节，15 到 30 分钟一张更合理，图片数量落在几十到一百多张，人工翻阅也不累。

我常用的算法很土：先用目标总时长除以期望图片数，得到初步间隔，再取整到便于心算的数值。比如 8 小时、期望 100 张左右，8×60/100 = 4.8 分钟，取 5 分钟。取整的意义在于人脑对“每 5 分钟”有直觉，对“每 4.8 分钟”没有，出问题时排查时间线会方便很多。另外要留出余量：图片张数乘单张大小就是你得预留的磁盘空间，我一般按“单张估算值 × 张数 × 1.2”来预留，1.2 是给异常情况留的缓冲。

单张大小估算也有方法。假设是常见办公分辨率，全屏截图为 PNG，实际落地通常在一两百 KB 到一两 MB 之间，内容越花哨越大。100 张的话按最坏情况就是两百多 MB，这个量级在现代机器上完全没问题，但如果跑一周不做清理，就会变成几个 GB。所以间隔和保留策略必须一起设计，不能只管拍不管删。

提示：高频档位（30 秒级）只适合短时间调试，不要长期挂着。我试过用 20 秒间隔跑一整晚，第二天磁盘告警，清理花了半小时。

3.2 时间戳与文件名：让文件自己讲清来历

文件名是这个工具最容易被忽略却最影响后续使用的地方。我见过用递增序号命名的做法，也见过直接用时间戳当文件名的做法，两者各有问题：纯序号看不出时间，纯时间戳字符串太长、排序不直观、跨时区不友好。我的做法是把时间戳格式化为可读的紧凑字符串，并前置按自然顺序排列，比如年-月-日加时分秒，中间不留空格，这样文件列表按名称排序就等于按时间排序。

还要考虑运行时信息对排查的价值。文件名里加上间隔档位或者任务标识，能让你一眼判断“这张是哪个任务拍的”。但不要往文件名里塞太多东西，太长会让路径在日志里被截断。我的取舍是：文件名只放时间和一个短任务标签，其余信息（精确时间、屏幕尺寸、文件大小）写进日志，不塞文件名。

时间戳的取法也有讲究：必须在抓屏动作开始前取时间，不要等保存时再取。原因是保存可能因为磁盘慢而延迟，尤其是定时任务跑在负载高的机器上时，若用保存时间命名，会和你对“这张图代表几点”的预期错开。这个偏差不大，但在做时间线对齐时很容易成为怀疑对象。我现在的写法是每轮循环开始取一次now，整轮都用这个值，日志和文件名一致，追溯时不会打架。

还有一个细节涉及夏令时和系统时间调整。用本地时间格式化，如果机器时间被自动校准，可能出现两张图时间戳相同或倒退。为了避开这个坑，我在日志里同时打一行单调递增的计数（第几轮）和一行本地时间，两者互为校验。文件名只用本地时间，因为人看文件列表时更习惯本地时间。

3.3 屏幕坐标、多显示器与缩放：黑图和半屏的根源

截屏工具出问题，最典型的两个现象是“截到的图是黑的”和“只截到半个屏幕”。前者通常和图形接口的权限、渲染方式有关，某些环境下直接抓屏拿不到受保护或硬件加速的窗口内容，会得到黑色区域。后者几乎都和坐标系与缩放有关。现在的系统普遍开启了显示缩放（比如把 150% 作为默认），此时应用层认为的屏幕尺寸和物理像素尺寸并不一致，用错坐标系就会截到局部。

我的处理原则有两条。第一，优先请求“整个虚拟屏幕”而不是“主屏幕”，这样多显示器环境下不会漏掉另一块屏。虚拟屏幕是一个能把所有显示器包住的矩形，需要正确处理它的原点偏移——副屏在主屏左边时，原点可能是负数，这个细节不处理会导致图片被裁掉一条边。第二，抓屏前先打印一次实际取到的尺寸，和系统显示的屏幕尺寸做比对，不一致就说明缩放介入，需要在代码里做补偿。这种“先验证再信任”的习惯，帮我省下过大量调试时间。

黑图排查我有一套固定顺序：先换成最简单的全屏抓取确认基础能力是否正常；再检查是否是特定窗口内容的问题；再检查是否与后台运行、锁屏状态有关。锁屏是最常见的隐形杀手——很多环境下锁屏后画面不再渲染，定时任务照跑，截到的全是锁屏或纯色画面，第二天看文件才发现一整晚白干。这个问题没有代码层的完美解法，只能靠“运行期间不要锁屏”这一运营约束，我会在部署说明里写清楚，同时在程序里加一个检测：连续多张图的内容几乎一致（通过文件大小或简单像素采样判断）就在日志里告警。

3.4 图像处理：PIL 在这里真正发挥价值的三件事

第一件是格式与质量。存 PNG 无损但体积大，适合需要看清文字细节的存档；存 JPEG 有损但体积小，适合长周期、数量多的场景。PIL 的save()支持质量参数，我一般从 80 左右起步，因为多数屏幕内容是文字和界面，质量再高收益已经不明显。我做过一次对比：同一张办公界面的全屏图，PNG 约 900 KB，JPEG 质量 85 约 180 KB，质量 70 约 110 KB，而 70 档在正常缩放下文字仍可辨认。

第二件是缩放。如果只是为了记录趋势，把宽度缩到原来的一半甚至更小完全够用，体积能降一个数量级。PIL 的重采样方式有好几种，LANCZOS质量最好但慢一些，缩屏这种场景完全感受不到差异，我习惯固定用它。缩放的比例建议用整数关系（比如 0.5），非整数比例容易出现文字发虚。

第三件是加时间标记。用ImageDraw在图片角落画一行时间文字，能解决“图片另存或转发后文件名丢失、不知道是哪天”的问题。具体操作要注意字体：默认字体很小且不一定支持中文，我会显式指定字体文件和字号，字号随图片宽度按比例取（比如宽度的 2%），保证不同分辨率下都看得清。标记位置固定放在左下角，避开常见的状态栏和通知区域。

from PIL import Image, ImageDraw, ImageFont def annotate(img, text, font_path=None): base = img.convert("RGB") w, h = base.size size = max(12, int(w * 0.02)) font = ImageFont.truetype(font_path, size) if font_path else ImageFont.load_default() draw = ImageDraw.Draw(base) # 半透明底衬，避免文字和背景同色看不清 draw.rectangle([0, h - size * 2, size * len(text) * 0.7, h], fill=(0, 0, 0)) draw.text((size * 0.3, h - size * 1.6), text, fill=(255, 255, 255), font=font) return base

上面这段里，底衬矩形那一步是我后来加上去的。最初只画白字，遇到浅色界面时文字完全看不清，排查时还以为是字体没生效，实际是对比度问题。加一条深色底衬，代价几乎为零，可读性提升很明显。

3.5 存储与清理：跑一晚上把磁盘写满的教训

清理策略必须内置，而且要默认开启。我的做法是按日期分目录，每天的图片放一个子目录，然后设置一个保留天数，启动时和每轮循环里都做一次旧目录清理。分目录的好处是清理简单——按目录名排序，删掉超过保留期的整个目录，不用逐个文件判断；同时也让归档和拷走变得容易。

清理有两条纪律。第一，只删自己生成的目录，判断依据是目录名严格匹配日期格式，绝不能对父目录做通配删除。我在这上面见过非常危险的写法，一旦目录变量为空，删除范围会失控。第二，删除操作必须写日志，记下删了哪个目录、多少文件。不是因为需要审计，而是当某天发现“想要的图不见了”时，日志能立刻告诉你它是被规则清理掉的，还是压根没截到，这两种情况排查方向完全不同。

还有一个小空间技巧：如果同时需要缩略图和原图，不要各存一份。我一般只存一份中等尺寸（足够看清关键信息），需要原图时靠日志里的记录去对应的完整归档里找。存储是这种长期运行工具最容易失控的成本项，主动缩减比事后清理省事。

4. 完整实操流程：从零跑起来这一版工具

4.1 环境准备与依赖安装

先确认 Python 版本，这条路线上 3.8 以上都够用，我是固定用较新的稳定版，避免老版本在图像处理上有奇怪行为。依赖只有两三个：图像处理用 Pillow，抓屏用一个轻量第三方包。安装命令我习惯写成一行，方便在部署说明里贴给同事。

python -m pip install --upgrade pip python -m pip install pillow

抓屏库的安装要看目标平台，装完之后立刻做一次最小验证：导入、调用、打印返回对象的尺寸，三步都通过再往下写。这一步不是形式主义，我在不同机器上遇到过装成功了但调用时报错的情况，早点发现能省掉后面一堆猜测。

# 最小验证：能拿到画面就算环境就绪 import importlib mod = importlib.import_module("mss") # 以常见抓屏库为例 with mod.mss() as sct: shot = sct.grab(sct.monitors[0]) print("capture ok:", shot.size)

如果这台机器装不上或调用不通，就走兜底路线：用系统截图命令把画面存到临时文件，再用 PIL 打开处理。兜底路线慢一些，但基本任何环境都能用，作为应急足够。

4.2 主循环的骨架与关键参数

主循环的结构我固定成四步：取时间、抓屏、处理、保存并清理。顺序不能乱，尤其时间必须最先取。

import os, time, datetime INTERVAL = 300 # 秒，5 分钟 KEEP_DAYS = 3 # 图片保留天数 OUT_ROOT = os.path.expanduser("~/screen_log") TASK_TAG = "run01" def main_loop(): os.makedirs(OUT_ROOT, exist_ok=True) round_no = 0 while True: round_no += 1 started = time.monotonic() now = datetime.datetime.now() day_dir = os.path.join(OUT_ROOT, now.strftime("%Y%m%d")) os.makedirs(day_dir, exist_ok=True) name = f"{now.strftime('%Y%m%d_%H%M%S')}_{TASK_TAG}.jpg" path = os.path.join(day_dir, name) try: img = capture() img = process(img) save(img, path) print(f"[{round_no}] saved {path}") except Exception as exc: print(f"[{round_no}] failed: {exc}") cleanup(OUT_ROOT, KEEP_DAYS) cost = time.monotonic() - started sleep_s = INTERVAL - cost if sleep_s <= 0: print(f"[{round_no}] overrun {cost:.1f}s, next round immediately") continue time.sleep(sleep_s)

这段里的几个决定都值得说明。用monotonic()而不是普通时间差，是因为系统时间可能被校准，用单调时钟算耗时才可靠。抓屏、处理、保存整段包在try里，是因为这三步任何一步失败都不该让整个工具退出——长时间运行的工具，容错比正确更重要。cleanup放在每轮末尾而不是开头，是为了保证即使第一次就崩了，也不会在启动阶段误删。

4.3 抓屏函数与屏幕尺寸校验

抓屏函数我会写成带降级逻辑的形态，先尝试第三方库，失败则走命令行兜底，两条路都返回统一的 Image 对象。

from PIL import Image def capture(): try: import mss with mss.mss() as sct: shot = sct.grab(sct.monitors[0]) # 0 表示全部显示器合并 return Image.frombytes("RGB", shot.size, shot.rgb) except Exception: return capture_fallback() def capture_fallback(): import subprocess, tempfile tmp = os.path.join(tempfile.gettempdir(), "shot_tmp.png") # 命令行参数需按目标系统调整，此处仅示意调用方式 subprocess.run(["系统截图命令", tmp], check=True) return Image.open(tmp).copy()

monitors[0]这个索引值得强调：在很多抓屏库里，索引 0 代表把全部显示器包住的虚拟屏幕，索引 1 开始才是各个独立显示器。我第一次写时误以为 0 是主屏，结果多屏环境下总是截到一块奇怪的合并画面，后来改过来才正常。这个细节各库约定略有差异，所以我在代码里会打印一次实际尺寸，和系统显示做比对。

尺寸校验我做成一个一次性检查：首次运行打印抓到的尺寸，如果宽度和手动查看的屏幕尺寸差异明显，就在日志里注明“疑似缩放介入”。这类提示不会自动修好问题，但能把“为什么图不对”的排查方向直接指出来，省下的时间是最宝贵的。

4.4 处理与保存的具体参数

处理函数负责三件事：模式统一、可选缩放、可选时间标记。我默认开启模式统一和时间标记，缩放默认关闭但留了开关，因为缩放一旦开了，细节损失是不可逆的，是否要缩得按用途来定。

SCALE = 1.0 # 1.0 表示不缩放 QUALITY = 85 # JPEG 质量 ANNOTATE = True def process(img): out = img.convert("RGB") # 统一模式，避免 JPEG 保存报错 if SCALE < 1.0: w, h = out.size out = out.resize((int(w * SCALE), int(h * SCALE)), Image.LANCZOS) if ANNOTATE: out = annotate(out, datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")) return out def save(img, path): img.save(path, format="JPEG", quality=QUALITY, optimize=True)

optimize=True是保存时值得加的一个参数，它会让 Pillow 在编码上多花一点计算量来换取更小体积。对定时任务来说，每次多几十毫秒完全不敏感，长期下来省下的磁盘很可观。质量 85 是我在“文字可辨认”和“体积可控”之间试出来的平衡点，如果内容是图纸、代码这类需要放大看的，我会临时调到 92 以上，或者干脆改用 PNG。

4.5 清理函数与安全边界

清理函数是整个脚本里我最谨慎的部分，因为它是唯一会主动删除数据的代码。

import shutil, re DAY_PATTERN = re.compile(r"^\d{8}$") def cleanup(root, keep_days): if not os.path.isdir(root): return cutoff = datetime.date.today() - datetime.timedelta(days=keep_days) for name in sorted(os.listdir(root)): full = os.path.join(root, name) if not os.path.isdir(full): continue if not DAY_PATTERN.match(name): # 只处理日期命名的目录 continue try: dir_date = datetime.datetime.strptime(name, "%Y%m%d").date() except ValueError: continue if dir_date < cutoff: shutil.rmtree(full) print(f"[cleanup] removed {full}")

这段里的三道防线是我踩坑后的产物。第一道，目录名必须严格是八位数字，不匹配一律不碰，避免误删同目录下的其他文件。第二道，日期解析失败就跳过，宁可漏删不可错删。第三道，只对子目录操作，绝不对根目录下的文件做通配删除。听起来有点过度防御，但删除操作不可逆，多写三行代码换一个睡得着的晚上，我觉得非常划算。

注意：不要为了“省空间”把保留天数设成 0 或负数。我在测试时设过一次 0，结果当轮就把当天目录删掉了，刚截的图直接消失，白跑。

4.6 让它在后台稳定跑起来

前台跑着的窗口一关，进程就没了，所以实际部署要把脚本放到后台。常用做法有两种：一种是用无界面方式启动，输出重定向到日志文件；另一种是交给系统自带的任务计划，开机自动拉起、异常自动重启。我通常先用前者验证跑通，再上后者做长期部署。

# 后台运行并保留日志，退出终端不影响 nohup python screen_timer.py > ~/screen_log/run.log 2>&1 &

日志一定要落盘，这是长时间运行工具的生命线。日志里至少要有：每轮序号、开始时间、耗时、保存路径、异常信息。有了这些，第二天看文件不对时不用猜，翻日志就知道是没截到、截错了、还是被清理了。我习惯每隔几天扫一眼日志里有没有连续的失败行，连续失败通常意味着环境发生了变化，比如权限、锁屏、磁盘满。

5. 常见问题与排查实录

5.1 症状对照速查表

这类工具出问题时的表现高度集中，我把实际遇到过的整理成一张表，按从高频到低频排列，方便对着现象直接找原因。

5.2 三个真实排查过程

第一个是“黑图”。有次我把工具部署到一台远程机器上跑，第二天全部是黑图。按我的固定顺序排查：先全屏抓一次还是黑，说明不是窗口内容问题；换命令行方案抓，正常，说明是抓屏库在这台机器的图形会话里拿不到画面。结论是抓屏方式与环境不匹配，改用兜底方案解决。这个过程告诉我，黑图不要急着怀疑代码逻辑，先换一条抓取路径做对照，能快速分层定位。

第二个是“周期漂移”。早期版本用固定sleep(INTERVAL)，跑了一个白天后发现比预期少截了好几张。算一下：每轮截屏加保存平均 6 秒，间隔 300 秒，实际周期 306 秒，一整天 100 多轮下来累计偏移超过十分钟。改成“间隔减已耗时”之后，同样的负载下偏移被压到每轮一两秒以内，因为多出来的时间会被下一轮的睡眠自动吸收。这个改动只有三行代码，但它决定了一个长期运行的工具是否可信。

第三个是“文件消失”。有次我发现想要的一张图不在，第一反应是程序没截到，翻日志发现记录里明明有保存成功。继续查是清理策略把目录删了——那天我为了测试临时把保留天数调小，忘了改回来。这次之后我给清理日志加了明确的一行输出，并在部署说明里把保留天数单独列成“部署前必查项”。很多所谓“工具不靠谱”，本质是参数被临时改过又忘了还原，日志是唯一的证据。

5.3 几条从实际使用里攒下来的经验

第一条，先用最短间隔跑五分钟，再放长。把间隔设成 10 秒跑几分钟，能快速验证抓屏、处理、保存、清理全链路是否都正常，等你确认没问题再改成正式间隔。直接上 300 秒去测，一次失败要等五分钟才知道。

第二条，把配置集中到文件顶部。间隔、保留天数、输出目录、质量、是否缩放，全部放在脚本最上面的几行，改的时候不用翻代码。我见过把参数散落在各个函数里的写法，改一次要搜全文，很容易漏改一处，导致行为和预期不一致。

第三条，运行前手动确认一次目标画面长什么样。定时截屏的价值在于“事后可回溯”，如果截到的区域不对、关键信息在屏幕外，截一整天也没用。我现在的习惯是先手动截一张，看看关键内容是否完整落在画面里，再启动定时任务。

第四条，别在高频档位上做长期任务。稳定性、磁盘、系统负担三方面都不划算。真需要高频记录，应该考虑录屏方案或者降低单张体积，而不是拿定时截屏硬撑。

5.4 后续可以怎么改

这个骨架故意留得简单，方便按需扩展。想加的就三类。一类是采集增强，比如只截指定窗口区域、只截某块显示器、多显示器分别存成不同文件。另一类是处理增强，比如批量生成缩略图索引、把一天的图片合成一张时间线长图、做简单的像素差异检测来标记“画面明显变化的时刻”。第三类是运维增强，比如总占用超过阈值时提前触发清理、连续失败若干次后写一个醒目的告警文件、把日志按天切分。

我实际加过的是“像素差异标记”：每轮把当前图和上一张做粗略比较，差异很小时不保存、只记录时间。这个改动让长时间静置的场景下图片数量直接降了一个数量级，磁盘压力小了很多。实现上不必精确，按比例采样一部分像素做比较就够用，本来就是用来筛掉“什么都没发生”的时刻，精度不是重点。

6. 最后说几句实际体会

这个工具我前后改过好几版，最深的感受是：难点从来不在“截屏”那行代码，而在“跑一整天不出事”这件事上。定时、耗时扣减、清理边界、失败容错、锁屏处理，每一项单独看都简单，凑在一起才决定工具能不能用。我早期写的版本功能都能跑，但跑满一天就会暴露各种问题，反而是后来那些看起来“啰嗦”的防御性代码——模式转换、目录名校验、异常包住整段——让它真正变得可靠。

另一个体会是关于取舍。定时截屏这个需求，很容易被越做越大：想加云同步、想加自动识别、想加可视化面板。我现在的做法是先把一件事做稳：本地定时存图、分日归档、按时清理、日志留痕。这些做到位之后，再加任何东西都是在这块稳固地基上长出来的，不会因为底层不稳而反复推倒。工具的价值不在于功能多，而在于你能放心让它自己跑一夜，第二天打开目录，图片整整齐齐、时间对得上、老的按规则清掉，这就够了。