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。所以间隔和保留策略必须一起设计不能只管拍不管删。使用目的建议间隔单日图片量建议保留短任务过程留证半天内35 分钟60160 张任务结束即归档全天长时间任务1015 分钟5090 张保留 37 天趋势观察多日30 分钟以上2050 张保留 730 天高频调试定位30 秒1 分钟数百张只留最近 2 小时提示高频档位30 秒级只适合短时间调试不要长期挂着。我试过用 20 秒间隔跑一整晚第二天磁盘告警清理花了半小时。3.2 时间戳与文件名让文件自己讲清来历文件名是这个工具最容易被忽略却最影响后续使用的地方。我见过用递增序号命名的做法也见过直接用时间戳当文件名的做法两者各有问题纯序号看不出时间纯时间戳字符串太长、排序不直观、跨时区不友好。我的做法是把时间戳格式化为可读的紧凑字符串并前置按自然顺序排列比如年-月-日加时分秒中间不留空格这样文件列表按名称排序就等于按时间排序。还要考虑运行时信息对排查的价值。文件名里加上间隔档位或者任务标识能让你一眼判断“这张是哪个任务拍的”。但不要往文件名里塞太多东西太长会让路径在日志里被截断。我的取舍是文件名只放时间和一个短任务标签其余信息精确时间、屏幕尺寸、文件大小写进日志不塞文件名。时间戳的取法也有讲究必须在抓屏动作开始前取时间不要等保存时再取。原因是保存可能因为磁盘慢而延迟尤其是定时任务跑在负载高的机器上时若用保存时间命名会和你对“这张图代表几点”的预期错开。这个偏差不大但在做时间线对齐时很容易成为怀疑对象。我现在的写法是每轮循环开始取一次now整轮都用这个值日志和文件名一致追溯时不会打架。还有一个细节涉及夏令时和系统时间调整。用本地时间格式化如果机器时间被自动校准可能出现两张图时间戳相同或倒退。为了避开这个坑我在日志里同时打一行单调递增的计数第几轮和一行本地时间两者互为校验。文件名只用本地时间因为人看文件列表时更习惯本地时间。3.3 屏幕坐标、多显示器与缩放黑图和半屏的根源截屏工具出问题最典型的两个现象是“截到的图是黑的”和“只截到半个屏幕”。前者通常和图形接口的权限、渲染方式有关某些环境下直接抓屏拿不到受保护或硬件加速的窗口内容会得到黑色区域。后者几乎都和坐标系与缩放有关。现在的系统普遍开启了显示缩放比如把 150% 作为默认此时应用层认为的屏幕尺寸和物理像素尺寸并不一致用错坐标系就会截到局部。我的处理原则有两条。第一优先请求“整个虚拟屏幕”而不是“主屏幕”这样多显示器环境下不会漏掉另一块屏。虚拟屏幕是一个能把所有显示器包住的矩形需要正确处理它的原点偏移——副屏在主屏左边时原点可能是负数这个细节不处理会导致图片被裁掉一条边。第二抓屏前先打印一次实际取到的尺寸和系统显示的屏幕尺寸做比对不一致就说明缩放介入需要在代码里做补偿。这种“先验证再信任”的习惯帮我省下过大量调试时间。黑图排查我有一套固定顺序先换成最简单的全屏抓取确认基础能力是否正常再检查是否是特定窗口内容的问题再检查是否与后台运行、锁屏状态有关。锁屏是最常见的隐形杀手——很多环境下锁屏后画面不再渲染定时任务照跑截到的全是锁屏或纯色画面第二天看文件才发现一整晚白干。这个问题没有代码层的完美解法只能靠“运行期间不要锁屏”这一运营约束我会在部署说明里写清楚同时在程序里加一个检测连续多张图的内容几乎一致通过文件大小或简单像素采样判断就在日志里告警。3.4 图像处理PIL 在这里真正发挥价值的三件事第一件是格式与质量。存 PNG 无损但体积大适合需要看清文字细节的存档存 JPEG 有损但体积小适合长周期、数量多的场景。PIL 的save()支持质量参数我一般从 80 左右起步因为多数屏幕内容是文字和界面质量再高收益已经不明显。我做过一次对比同一张办公界面的全屏图PNG 约 900 KBJPEG 质量 85 约 180 KB质量 70 约 110 KB而 70 档在正常缩放下文字仍可辨认。第二件是缩放。如果只是为了记录趋势把宽度缩到原来的一半甚至更小完全够用体积能降一个数量级。PIL 的重采样方式有好几种LANCZOS质量最好但慢一些缩屏这种场景完全感受不到差异我习惯固定用它。缩放的比例建议用整数关系比如 0.5非整数比例容易出现文字发虚。第三件是加时间标记。用ImageDraw在图片角落画一行时间文字能解决“图片另存或转发后文件名丢失、不知道是哪天”的问题。具体操作要注意字体默认字体很小且不一定支持中文我会显式指定字体文件和字号字号随图片宽度按比例取比如宽度的 2%保证不同分辨率下都看得清。标记位置固定放在左下角避开常见的状态栏和通知区域。from PIL import Image, ImageDraw, ImageFont def annotate(img, text, font_pathNone): 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), fontfont) 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_okTrue) 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_okTrue) 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], checkTrue) 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, formatJPEG, qualityQUALITY, optimizeTrue)optimizeTrue是保存时值得加的一个参数它会让 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(dayskeep_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 21 日志一定要落盘这是长时间运行工具的生命线。日志里至少要有每轮序号、开始时间、耗时、保存路径、异常信息。有了这些第二天看文件不对时不用猜翻日志就知道是没截到、截错了、还是被清理了。我习惯每隔几天扫一眼日志里有没有连续的失败行连续失败通常意味着环境发生了变化比如权限、锁屏、磁盘满。5. 常见问题与排查实录5.1 症状对照速查表这类工具出问题时的表现高度集中我把实际遇到过的整理成一张表按从高频到低频排列方便对着现象直接找原因。现象最可能原因排查动作图片全黑或纯色锁屏、受保护内容、抓屏方式不兼容解锁后手动测一次换抓屏方式对比只截到半个屏幕多显示器原点偏移未处理打印抓取尺寸与实际屏幕比对图片被放大裁切系统显示缩放介入检查尺寸差异按物理像素取图周期越来越长睡眠时长写死未扣耗时改用“间隔减已耗时”的算法磁盘被写满未设清理或保留期过长检查保留天数与单张体积定时任务不生效后台运行环境无图形会话改由用户会话内启动保存报错模式不支持图像带透明通道存 JPEG保存前convert(RGB)文件时间戳重复系统时间被校准回拨日志加单调计数做校验5.2 三个真实排查过程第一个是“黑图”。有次我把工具部署到一台远程机器上跑第二天全部是黑图。按我的固定顺序排查先全屏抓一次还是黑说明不是窗口内容问题换命令行方案抓正常说明是抓屏库在这台机器的图形会话里拿不到画面。结论是抓屏方式与环境不匹配改用兜底方案解决。这个过程告诉我黑图不要急着怀疑代码逻辑先换一条抓取路径做对照能快速分层定位。第二个是“周期漂移”。早期版本用固定sleep(INTERVAL)跑了一个白天后发现比预期少截了好几张。算一下每轮截屏加保存平均 6 秒间隔 300 秒实际周期 306 秒一整天 100 多轮下来累计偏移超过十分钟。改成“间隔减已耗时”之后同样的负载下偏移被压到每轮一两秒以内因为多出来的时间会被下一轮的睡眠自动吸收。这个改动只有三行代码但它决定了一个长期运行的工具是否可信。第三个是“文件消失”。有次我发现想要的一张图不在第一反应是程序没截到翻日志发现记录里明明有保存成功。继续查是清理策略把目录删了——那天我为了测试临时把保留天数调小忘了改回来。这次之后我给清理日志加了明确的一行输出并在部署说明里把保留天数单独列成“部署前必查项”。很多所谓“工具不靠谱”本质是参数被临时改过又忘了还原日志是唯一的证据。5.3 几条从实际使用里攒下来的经验第一条先用最短间隔跑五分钟再放长。把间隔设成 10 秒跑几分钟能快速验证抓屏、处理、保存、清理全链路是否都正常等你确认没问题再改成正式间隔。直接上 300 秒去测一次失败要等五分钟才知道。第二条把配置集中到文件顶部。间隔、保留天数、输出目录、质量、是否缩放全部放在脚本最上面的几行改的时候不用翻代码。我见过把参数散落在各个函数里的写法改一次要搜全文很容易漏改一处导致行为和预期不一致。第三条运行前手动确认一次目标画面长什么样。定时截屏的价值在于“事后可回溯”如果截到的区域不对、关键信息在屏幕外截一整天也没用。我现在的习惯是先手动截一张看看关键内容是否完整落在画面里再启动定时任务。第四条别在高频档位上做长期任务。稳定性、磁盘、系统负担三方面都不划算。真需要高频记录应该考虑录屏方案或者降低单张体积而不是拿定时截屏硬撑。5.4 后续可以怎么改这个骨架故意留得简单方便按需扩展。想加的就三类。一类是采集增强比如只截指定窗口区域、只截某块显示器、多显示器分别存成不同文件。另一类是处理增强比如批量生成缩略图索引、把一天的图片合成一张时间线长图、做简单的像素差异检测来标记“画面明显变化的时刻”。第三类是运维增强比如总占用超过阈值时提前触发清理、连续失败若干次后写一个醒目的告警文件、把日志按天切分。我实际加过的是“像素差异标记”每轮把当前图和上一张做粗略比较差异很小时不保存、只记录时间。这个改动让长时间静置的场景下图片数量直接降了一个数量级磁盘压力小了很多。实现上不必精确按比例采样一部分像素做比较就够用本来就是用来筛掉“什么都没发生”的时刻精度不是重点。6. 最后说几句实际体会这个工具我前后改过好几版最深的感受是难点从来不在“截屏”那行代码而在“跑一整天不出事”这件事上。定时、耗时扣减、清理边界、失败容错、锁屏处理每一项单独看都简单凑在一起才决定工具能不能用。我早期写的版本功能都能跑但跑满一天就会暴露各种问题反而是后来那些看起来“啰嗦”的防御性代码——模式转换、目录名校验、异常包住整段——让它真正变得可靠。另一个体会是关于取舍。定时截屏这个需求很容易被越做越大想加云同步、想加自动识别、想加可视化面板。我现在的做法是先把一件事做稳本地定时存图、分日归档、按时清理、日志留痕。这些做到位之后再加任何东西都是在这块稳固地基上长出来的不会因为底层不稳而反复推倒。工具的价值不在于功能多而在于你能放心让它自己跑一夜第二天打开目录图片整整齐齐、时间对得上、老的按规则清掉这就够了。
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。所以间隔和保留策略必须一起设计不能只管拍不管删。使用目的建议间隔单日图片量建议保留短任务过程留证半天内35 分钟60160 张任务结束即归档全天长时间任务1015 分钟5090 张保留 37 天趋势观察多日30 分钟以上2050 张保留 730 天高频调试定位30 秒1 分钟数百张只留最近 2 小时提示高频档位30 秒级只适合短时间调试不要长期挂着。我试过用 20 秒间隔跑一整晚第二天磁盘告警清理花了半小时。3.2 时间戳与文件名让文件自己讲清来历文件名是这个工具最容易被忽略却最影响后续使用的地方。我见过用递增序号命名的做法也见过直接用时间戳当文件名的做法两者各有问题纯序号看不出时间纯时间戳字符串太长、排序不直观、跨时区不友好。我的做法是把时间戳格式化为可读的紧凑字符串并前置按自然顺序排列比如年-月-日加时分秒中间不留空格这样文件列表按名称排序就等于按时间排序。还要考虑运行时信息对排查的价值。文件名里加上间隔档位或者任务标识能让你一眼判断“这张是哪个任务拍的”。但不要往文件名里塞太多东西太长会让路径在日志里被截断。我的取舍是文件名只放时间和一个短任务标签其余信息精确时间、屏幕尺寸、文件大小写进日志不塞文件名。时间戳的取法也有讲究必须在抓屏动作开始前取时间不要等保存时再取。原因是保存可能因为磁盘慢而延迟尤其是定时任务跑在负载高的机器上时若用保存时间命名会和你对“这张图代表几点”的预期错开。这个偏差不大但在做时间线对齐时很容易成为怀疑对象。我现在的写法是每轮循环开始取一次now整轮都用这个值日志和文件名一致追溯时不会打架。还有一个细节涉及夏令时和系统时间调整。用本地时间格式化如果机器时间被自动校准可能出现两张图时间戳相同或倒退。为了避开这个坑我在日志里同时打一行单调递增的计数第几轮和一行本地时间两者互为校验。文件名只用本地时间因为人看文件列表时更习惯本地时间。3.3 屏幕坐标、多显示器与缩放黑图和半屏的根源截屏工具出问题最典型的两个现象是“截到的图是黑的”和“只截到半个屏幕”。前者通常和图形接口的权限、渲染方式有关某些环境下直接抓屏拿不到受保护或硬件加速的窗口内容会得到黑色区域。后者几乎都和坐标系与缩放有关。现在的系统普遍开启了显示缩放比如把 150% 作为默认此时应用层认为的屏幕尺寸和物理像素尺寸并不一致用错坐标系就会截到局部。我的处理原则有两条。第一优先请求“整个虚拟屏幕”而不是“主屏幕”这样多显示器环境下不会漏掉另一块屏。虚拟屏幕是一个能把所有显示器包住的矩形需要正确处理它的原点偏移——副屏在主屏左边时原点可能是负数这个细节不处理会导致图片被裁掉一条边。第二抓屏前先打印一次实际取到的尺寸和系统显示的屏幕尺寸做比对不一致就说明缩放介入需要在代码里做补偿。这种“先验证再信任”的习惯帮我省下过大量调试时间。黑图排查我有一套固定顺序先换成最简单的全屏抓取确认基础能力是否正常再检查是否是特定窗口内容的问题再检查是否与后台运行、锁屏状态有关。锁屏是最常见的隐形杀手——很多环境下锁屏后画面不再渲染定时任务照跑截到的全是锁屏或纯色画面第二天看文件才发现一整晚白干。这个问题没有代码层的完美解法只能靠“运行期间不要锁屏”这一运营约束我会在部署说明里写清楚同时在程序里加一个检测连续多张图的内容几乎一致通过文件大小或简单像素采样判断就在日志里告警。3.4 图像处理PIL 在这里真正发挥价值的三件事第一件是格式与质量。存 PNG 无损但体积大适合需要看清文字细节的存档存 JPEG 有损但体积小适合长周期、数量多的场景。PIL 的save()支持质量参数我一般从 80 左右起步因为多数屏幕内容是文字和界面质量再高收益已经不明显。我做过一次对比同一张办公界面的全屏图PNG 约 900 KBJPEG 质量 85 约 180 KB质量 70 约 110 KB而 70 档在正常缩放下文字仍可辨认。第二件是缩放。如果只是为了记录趋势把宽度缩到原来的一半甚至更小完全够用体积能降一个数量级。PIL 的重采样方式有好几种LANCZOS质量最好但慢一些缩屏这种场景完全感受不到差异我习惯固定用它。缩放的比例建议用整数关系比如 0.5非整数比例容易出现文字发虚。第三件是加时间标记。用ImageDraw在图片角落画一行时间文字能解决“图片另存或转发后文件名丢失、不知道是哪天”的问题。具体操作要注意字体默认字体很小且不一定支持中文我会显式指定字体文件和字号字号随图片宽度按比例取比如宽度的 2%保证不同分辨率下都看得清。标记位置固定放在左下角避开常见的状态栏和通知区域。from PIL import Image, ImageDraw, ImageFont def annotate(img, text, font_pathNone): 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), fontfont) 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_okTrue) 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_okTrue) 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], checkTrue) 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, formatJPEG, qualityQUALITY, optimizeTrue)optimizeTrue是保存时值得加的一个参数它会让 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(dayskeep_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 21 日志一定要落盘这是长时间运行工具的生命线。日志里至少要有每轮序号、开始时间、耗时、保存路径、异常信息。有了这些第二天看文件不对时不用猜翻日志就知道是没截到、截错了、还是被清理了。我习惯每隔几天扫一眼日志里有没有连续的失败行连续失败通常意味着环境发生了变化比如权限、锁屏、磁盘满。5. 常见问题与排查实录5.1 症状对照速查表这类工具出问题时的表现高度集中我把实际遇到过的整理成一张表按从高频到低频排列方便对着现象直接找原因。现象最可能原因排查动作图片全黑或纯色锁屏、受保护内容、抓屏方式不兼容解锁后手动测一次换抓屏方式对比只截到半个屏幕多显示器原点偏移未处理打印抓取尺寸与实际屏幕比对图片被放大裁切系统显示缩放介入检查尺寸差异按物理像素取图周期越来越长睡眠时长写死未扣耗时改用“间隔减已耗时”的算法磁盘被写满未设清理或保留期过长检查保留天数与单张体积定时任务不生效后台运行环境无图形会话改由用户会话内启动保存报错模式不支持图像带透明通道存 JPEG保存前convert(RGB)文件时间戳重复系统时间被校准回拨日志加单调计数做校验5.2 三个真实排查过程第一个是“黑图”。有次我把工具部署到一台远程机器上跑第二天全部是黑图。按我的固定顺序排查先全屏抓一次还是黑说明不是窗口内容问题换命令行方案抓正常说明是抓屏库在这台机器的图形会话里拿不到画面。结论是抓屏方式与环境不匹配改用兜底方案解决。这个过程告诉我黑图不要急着怀疑代码逻辑先换一条抓取路径做对照能快速分层定位。第二个是“周期漂移”。早期版本用固定sleep(INTERVAL)跑了一个白天后发现比预期少截了好几张。算一下每轮截屏加保存平均 6 秒间隔 300 秒实际周期 306 秒一整天 100 多轮下来累计偏移超过十分钟。改成“间隔减已耗时”之后同样的负载下偏移被压到每轮一两秒以内因为多出来的时间会被下一轮的睡眠自动吸收。这个改动只有三行代码但它决定了一个长期运行的工具是否可信。第三个是“文件消失”。有次我发现想要的一张图不在第一反应是程序没截到翻日志发现记录里明明有保存成功。继续查是清理策略把目录删了——那天我为了测试临时把保留天数调小忘了改回来。这次之后我给清理日志加了明确的一行输出并在部署说明里把保留天数单独列成“部署前必查项”。很多所谓“工具不靠谱”本质是参数被临时改过又忘了还原日志是唯一的证据。5.3 几条从实际使用里攒下来的经验第一条先用最短间隔跑五分钟再放长。把间隔设成 10 秒跑几分钟能快速验证抓屏、处理、保存、清理全链路是否都正常等你确认没问题再改成正式间隔。直接上 300 秒去测一次失败要等五分钟才知道。第二条把配置集中到文件顶部。间隔、保留天数、输出目录、质量、是否缩放全部放在脚本最上面的几行改的时候不用翻代码。我见过把参数散落在各个函数里的写法改一次要搜全文很容易漏改一处导致行为和预期不一致。第三条运行前手动确认一次目标画面长什么样。定时截屏的价值在于“事后可回溯”如果截到的区域不对、关键信息在屏幕外截一整天也没用。我现在的习惯是先手动截一张看看关键内容是否完整落在画面里再启动定时任务。第四条别在高频档位上做长期任务。稳定性、磁盘、系统负担三方面都不划算。真需要高频记录应该考虑录屏方案或者降低单张体积而不是拿定时截屏硬撑。5.4 后续可以怎么改这个骨架故意留得简单方便按需扩展。想加的就三类。一类是采集增强比如只截指定窗口区域、只截某块显示器、多显示器分别存成不同文件。另一类是处理增强比如批量生成缩略图索引、把一天的图片合成一张时间线长图、做简单的像素差异检测来标记“画面明显变化的时刻”。第三类是运维增强比如总占用超过阈值时提前触发清理、连续失败若干次后写一个醒目的告警文件、把日志按天切分。我实际加过的是“像素差异标记”每轮把当前图和上一张做粗略比较差异很小时不保存、只记录时间。这个改动让长时间静置的场景下图片数量直接降了一个数量级磁盘压力小了很多。实现上不必精确按比例采样一部分像素做比较就够用本来就是用来筛掉“什么都没发生”的时刻精度不是重点。6. 最后说几句实际体会这个工具我前后改过好几版最深的感受是难点从来不在“截屏”那行代码而在“跑一整天不出事”这件事上。定时、耗时扣减、清理边界、失败容错、锁屏处理每一项单独看都简单凑在一起才决定工具能不能用。我早期写的版本功能都能跑但跑满一天就会暴露各种问题反而是后来那些看起来“啰嗦”的防御性代码——模式转换、目录名校验、异常包住整段——让它真正变得可靠。另一个体会是关于取舍。定时截屏这个需求很容易被越做越大想加云同步、想加自动识别、想加可视化面板。我现在的做法是先把一件事做稳本地定时存图、分日归档、按时清理、日志留痕。这些做到位之后再加任何东西都是在这块稳固地基上长出来的不会因为底层不稳而反复推倒。工具的价值不在于功能多而在于你能放心让它自己跑一夜第二天打开目录图片整整齐齐、时间对得上、老的按规则清掉这就够了。
