Python自动化脚本最吸引人的地方，在于它能把“手动重复”压缩成一句话命令。我接触自动化快十年，见过太多人把时间花在重命名文件、合并表格、盯着网页刷新、等等，这些动作单独看都很小，但累积起来，一天至少能吃掉一两个小时。这篇文章要聊的，就是10个我反复用、改过很多遍的Python自动化脚本，覆盖文件整理、表格处理、网页监测、定时汇报、开发辅助这几类场景。每个脚本都会给核心思路、代码片段和使用边界，适合有一定Python基础、或者敢于直接抄代码再改的人参考。
我不追新库，也不堆砌花哨功能。能用标准库解决的，优先用标准库；需要用第三方库的，会明确告诉你它解决什么问题。这样做的原因很简单：自动化脚本最怕依赖过重，一旦换了环境、装了新版本，脚本反而成了新的维护负担。下面直接进入正题，先聊一聊动手写脚本之前，最容易被忽略的一步。
1. 动手前先给重复劳动分类，才知道自动化该往哪使劲
很多人写自动化脚本的第一步是打开编辑器，结果写了一堆看似有用、实际根本用不上的代码。我自己的习惯是反过来的：先把最近一周反复做过的事情列出来，逐项打上标签，再决定哪个脚本优先写。这个分类过程看着啰嗦，但能帮你避开“为自动化而自动化”的陷阱。
1.1 值得自动化的三个特征
第一个特征是执行路径固定。也就是说，你每次操作时大脑都清楚下一步是什么，比如“把downloads文件夹里的png改成日期前缀”“把上个月报表汇总到一个sheet里”，这类动作没有太多需要判断的地方，机械性极强。
第二个特征是规则明确。规则越清晰，脚本越好写。比如“超过30天的缓存目录压缩归档”“HTTP响应码不是200就记录通知”，这种规则可以用if-else写得很干净。相反，如果规则需要大量主观判断，比如“看看这些邮件哪封比较重要”，那自动化只能处理一部分，剩下的还是得靠人。
第三个特征是频率高或出错成本高。频率高的动作容易量化，比如每天要做三次的数据导出，写脚本的性价比很高。出错成本高的动作即使一周只碰一次，也值得自动化，比如手工合并上百个文件，中间错一步，返工时间远超写脚本的时间。
1.2 用一张损耗清单代替拍脑袋
我建议你花15分钟做一份手工损耗清单，就按下面这个表头记：
| 重复动作 | 单次耗时 | 每周次数 | 出错后的代价 |
|---|---|---|---|
| 批量重命名下载的图片 | 3分钟 | 5次 | 命名混乱，后期找文件困难 |
| 合并各分支的日报表 | 10分钟 | 4次 | 漏行、错行，返工1小时 |
| 检查服务是否在线 | 2分钟 | 21次 | 发现晚了，影响扩大 |
| 压缩调整图片尺寸 | 5分钟 | 3次 | 图片过大，上传失败 |
做完这张表，你自然会看出优先级：移动一个文件10秒可能不值得自动化，但每天几十个文件就值得了。把这类高损耗动作排到前面，脚本写出来的成就感也更强。
1.3 通用脚本骨架：输入、处理、输出、日志
无论哪个脚本，我都习惯保持四段结构：准备输入、执行处理、落盘输出、记录日志。输入用参数或配置文件控制，不写死在代码里；处理逻辑只负责单一任务；输出路径单独定义；日志哪怕是简单的print加上时间戳，也能在出错时省下大量排查时间。
import sys import logging from datetime import datetime logging.basicConfig( level=logging.INFO, format="%(asctime)s [%(levelname)s] %(message)s", handlers=[ logging.StreamHandler(), logging.FileHandler("run.log", encoding="utf-8") ] )跑任何脚本之前，先确认它能把“这次发生了什么”写下来。自动化脚本不是给人看表演的，是要稳定解决问题，日志就是它留下的工作记录。
2. 文件整理与归档类：重命名、清理、压缩，三条命令解决脏目录
文件操作是我个人最推荐的自动化入门领域。原因很朴素：所有文件操作都看得见、摸得着，脚本万一出问题，最多伤到文件副本，不会牵扯复杂的网络权限。而且这类脚本通常只要标准库就能跑，拷贝到哪都能用。
2.1 批量重命名脚本：别再用右键菜单一个个改了
有一次我需要处理700多张活动照片，文件名像“IMG_2035.JPG”这种完全没有语义，我还要按日期和分组重新命名。手工改700个文件太痛苦，写个脚本反而安静地跑完了。脚本的核心思路是遍历目录里所有目标后缀文件，按规则生成新名字，同时避免覆盖已有文件。
from pathlib import Path source_dir = Path("./photos") prefix = "photo" for idx, file in enumerate(sorted(source_dir.glob("*.JPG")), start=1): new_name = f"{prefix}_{file.stat().st_mtime_ns:.0f}_{idx:03d}{file.suffix.lower()}" target = source_dir / new_name if not target.exists(): file.rename(target) print(f"{file.name} -> {new_name}")这里我把时间戳纳入了文件名，作用是避免重名，同时保留了文件生成顺序的线索。用st_mtime_ns而不是直接用“当前时间”，是考虑到脚本偶尔中断后重跑，若引用当前时间，同一个文件可能算出不同名称；用文件自身时间戳则每次都稳定。
技术上的坑在于：先判断target.exists()再执行重命名，虽然能挡住多数冲突，但仍有极小概率被别的进程抢先创建同名文件。要求严格时可以改用os.rename加异常捕获，然后在异常分支里再处理。日常使用，先判断后执行已经够用。
2.2 临时文件清理脚本：先打印计划，再动真格
清理临时文件、日志文件、编辑器残留备份文件，这是每个人都干过的重复劳动。隐患在于容易误删重要文件，所以我写的清理脚本有两条铁律：第一，默认只删除指定后缀和指定目录；第二，必须先提供dry-run模式，只打印准备删什么，确认后再真正执行删除。
from pathlib import Path import sys target_dir = Path("./tmp") patterns = ["*.tmp", "*.log", "*~", "*.bak"] dry_run = "--execute" not in sys.argv to_delete = [] for pattern in patterns: to_delete.extend(target_dir.rglob(pattern)) for path in to_delete: if path.is_file(): size = path.stat().st_size if dry_run: print(f"[dry-run] delete {path} ({size} bytes)") else: path.unlink() print(f"[deleted] {path}") if dry_run: print(f"\n共将清理 {len(to_delete)} 个文件；确认无误后加 --execute 参数执行")你可能会问，为什么不直接写上--execute就跑？因为目录清理一旦出错，短时间内很难察觉。某个*.tmp后缀被其他项目作为正式文件使用，或者通配符配到了不该碰的备份文件，都会带来麻烦。dry-run模式成本极低，收益却很实在。我甚至建议把dry-run作为所有破坏性脚本的默认行为，这是自动化脚本保持安全感的习惯。
2.3 旧文件归档与压缩：按月份自动装箱
文件整理走到最后，往往还要面对“历史文件怎么处理”。频繁清理不现实，全删又怕以后要翻旧账，最好是把老一辈文件统一归档压缩。下面是自动归档旧文件的思路：把指定目录下超过N个月未修改的文件，按月份移动到archive目录，再用压缩包打包起来。
import os import shutil from pathlib import Path from datetime import datetime, timedelta source = Path("./data") months_limit = 6 archive_root = Path("./archive") cutoff = datetime.now() - timedelta(days=months_limit * 30) for file in source.rglob("*.*"): if not file.is_file(): continue mtime = datetime.fromtimestamp(file.stat().st_mtime) if mtime > cutoff: continue month_dir = archive_root / mtime.strftime("%Y-%m") month_dir.mkdir(parents=True, exist_ok=True) target = month_dir / file.name if not target.exists(): shutil.move(str(file), str(target)) # 之后可以对archive_root做压缩，例如调用zipfile或外部压缩命令这段脚本的关键点是“按月分目录”，归档包不会变成一个巨大混杂的压缩文件，查找时也更直观。压缩本身你可以用标准库zipfile做，也可以调用系统压缩命令。我个人的经验是：归档动作拆成两步，第一步移动分类，第二步压缩，不要试图一次完成。一旦压缩过程出错，至少原始文件还在archive目录里，恢复成本低。
3. 表格与文档处理类：让数据在多个工作簿之间自动流转
工作里最难缠的重复劳动，多半藏在电子表格里。收到二十个格式相同的表，要把它们合并到一个总表；或者把一个大表拆成按月份/按部门的小表。最早我是手工复制的，直到有一天复制到眼酸，果断写了脚本。
3.1 多工作簿合并：用openpyxl读数据，再统一写入
处理.xlsx这种现代电子表格格式，我的首选是openpyxl这个库。它只处理表格数据，不依赖办公软件安装环境，在服务器上也能跑。合并多个工作簿时，最常用的是“轮询读取，逐行汇总”的模式。
from openpyxl import load_workbook, Workbook from pathlib import Path source_files = list(Path("./reports").glob("*.xlsx")) output = Workbook() out_sheet = output.active out_sheet.title = "合并结果" # 先写表头，再写数据 header_written = False for fp in source_files: wb = load_workbook(fp, data_only=True) ws = wb.active rows = list(ws.iter_rows(values_only=True)) if not rows: continue if not header_written: out_sheet.append(rows[0]) header_written = True for row in rows[1:]: out_sheet.append(row) wb.close() output.save("./combined.xlsx") print(f"已合并 {len(source_files)} 个文件")这里有两个细节，比代码逻辑本身更重要。一是data_only=True：如果表格里有公式单元格，不带这个参数读到的可能是公式字符串而不是计算后的值，汇总时就会出错。二是iter_rows(values_only=True)：直接读取成元组，不会让openpyxl创建一堆Cell对象，内存占用明显更低。遇到几千行的文件感觉不出来，遇到几十个几万行的文件时，这点优化很关键。
3.2 大表拆分成多个小表：按字段自动分组
合并的反向需求是拆分。我见过一张总表里包含多个部门人员名单，每次发通知前要按部门筛选说明。手工筛选不难，但每天都要做就烦了。拆分脚本的思路是读完整表，按指定列的值分组，再为每个组单独创建工作簿。
from collections import defaultdict from openpyxl import load_workbook, Workbook src = "./employees.xlsx" wb = load_workbook(src, data_only=True) ws = wb.active rows = list(ws.iter_rows(values_only=True)) header = rows[0] group_idx = header.index("部门") groups = defaultdict(list) for row in rows[1:]: groups[row[group_idx]].append(row) for group_name, data_rows in groups.items(): new_wb = Workbook() new_ws = new_wb.active new_ws.title = str(group_name)[:30] new_ws.append(header) for row in data_rows: new_ws.append(row) safe_name = "".join(ch for ch in str(group_name) if ch not in '\\/:*?"<>|') new_wb.save(f"./split/{safe_name}.xlsx")我在文件名前做了一次非法字符过滤，这个细节一般人容易忘。组名里如果包含“/”或者“?”，在保存时会有隐患，所以凡是拿数据里的字段当文件名，都必须过滤一遍。否则脚本跑一半报错，前面生成的文件还得手动清理。
3.3 PDF文字提取：把多份文档变成可检索的文本索引
PDF处理是我见过最容易被“手工党”低估的场景。文档一多，想在几十份PDF里找某个关键词，只能用阅读器逐个打开。按字体、表格、扫描件更是各有各的问题，但纯文字型PDF用pypdf处理已经足够。下面这个脚本提取指定PDF每一页的首段文字，生成一个简短索引，方便快速定位。
from pypdf import PdfReader from pathlib import Path pdf_dir = Path("./docs") index_lines = [] for pdf_file in pdf_dir.glob("*.pdf"): try: reader = PdfReader(str(pdf_file)) first_text = "" for page in reader.pages: text = page.extract_text() or "" text = " ".join(text.split()) if text: first_text = text[:120] break index_lines.append(f"{pdf_file.name} | 页数:{len(reader.pages)} | 开头:{first_text}") except Exception as exc: index_lines.append(f"{pdf_file.name} | 解析失败: {exc}") Path("./pdf_index.txt").write_text("\n".join(index_lines), encoding="utf-8") print(f"已生成 {len(index_lines)} 条索引")这段脚本对扫描版PDF无效，因为扫描件本质是图片，需要OCR，pypdf提取不出文本。遇到扫描PDF时，我的建议是先用OCR工具转换成文本再进入脚本流程。另外，不能图省事把整个脚本接收所有PDF，不同PDF制作者的排版逻辑差异很大，extract_text读出来的顺序偶尔会乱。解决方法是保持脚本只做“辅助定位”，不要指望它完美还原文档原文。
4. 网络监测与巡检类：不是爬虫，而是盯着公开信息变化的哨兵
网页监测、接口巡检这两类自动化，经常被人误会成爬虫。其实它们的核心不是“抓取”而是“确认状态”：页面是否更新、服务是否在线、响应是否正常。这类脚本请求量很小，只要控制访问频率并遵守对方网页声明的规则，就是很常规的运维手段。
4.1 网页更新监测：用哈希判断页面是否变化
一个经典场景是：某个公开页面每天更新一些公告或价格信息，你不想反复打开浏览器，想让脚本自动盯梢。思路很简单，抓取页面文本，计算哈希，把上一次的哈希存进本地文件；下次跑脚本时对比哈希，不同就说明页面发生了变化。
import hashlib import json import time from pathlib import Path import requests url = "https://example.com/notices" state_file = Path("./watch_state.json") UA = {"User-Agent": "script-notice-check/0.1"} resp = requests.get(url, headers=UA, timeout=10) resp.raise_for_status() content_hash = hashlib.sha256(resp.text.encode("utf-8")).hexdigest() old_hash = None if state_file.exists(): old_hash = json.loads(state_file.read_text(encoding="utf-8")).get("hash") if old_hash and old_hash != content_hash: print(f"[变化] {url} 页面内容发生更新") elif not old_hash: print("[初始记录] 已完成页面快照") else: print("[无变化] 页面内容保持不变") state_file.write_text(json.dumps({"url": url, "hash": content_hash}), encoding="utf-8")这里最需要留意的是“变化误报”。网页里通常混入动态字段，比如随机广告、时间戳、访问计数，直接对整个页面文本取哈希，可能每次都判定变化。更稳妥的做法是提取标题或核心正文区域再计算哈希。不同站点的页面结构差异很大，所以这个脚本通常需要针对具体站点调一两次，才能长期稳定运行。
同时，监控频率要保持克制。对同一个页面，每10分钟甚至每小时检查一次就足够了。脚本里设置超时时间、写清User-Agent，都是最基本的礼仪，也能避免给自己惹麻烦。
4.2 HTTP健康巡检：记录状态码和响应时间
服务可用性巡检是另一个很实用的脚本。定时给指定地址发HEAD或GET请求，记录状态码、耗时、是否超时，再写入日志或发送提醒。下面这段是基础版：
import time import requests targets = [ "https://example.com/api/health", "https://example.org/status", ] for url in targets: start = time.perf_counter() try: resp = requests.get(url, timeout=5) cost = time.perf_counter() - start status = resp.status_code except requests.RequestException as exc: cost = time.perf_counter() - start status = f"ERROR: {exc.__class__.__name__}" print(f"{time.strftime('%Y-%m-%d %H:%M:%S')} | {url} | {status} | {cost * 1000:.1f}ms")这段脚本本身的逻辑很简单，真正有价值的动作是把输出结果追加到日志文件，而不是只打印在屏幕上。因为巡检脚本常常跑在无人值守环境，你不盯着屏幕，就要让记录可以被事后查看。用logging模块把每轮结果写入轮转日志，是我实际使用时的必备配置。
巡检脚本还要特别注意超时设置。没有timeout的requests请求，在某些网络环境下会一直挂着，脚本可能“死”在那里毫无反馈。timeout设成5秒，已经能覆盖绝大多数正常服务；如果某些接口本身就慢，再针对单个URL单独调整超时值。
4.3 把巡检结果和状态文件放在统一目录
做网络监测类脚本，我习惯在项目目录里建一个state子目录，专门存放上次的哈希值、状态快照、日志文件。这样脚本可以随时中断重跑，状态不会丢。另一个好处是，万一脚本跑了几周后行为异常，你能翻出历史状态，快速判断是哪一轮开始不对的。
5. 自动化日报与邮件提醒：把脚本接进系统调度器
文件整理和表格合并解决了“数据整理”的问题，但如果不把这套流程定时跑起来，它仍然是一段需要你手动敲命令的代码。这一节把自动化往前推一步，讲怎么让脚本主动生成日报，并通过邮件把结果送到你面前。
5.1 自动生成简报：把目录状态浓缩成一段文本
先造一个“日报生成函数”，它扫指定目录，统计文件数量、总占用空间、待处理文件数量。每天定时执行后，脚本自动生成一段简洁文本。这里我刻意避免把内容写得太花哨，机器生成的日报，重点是稳定、可读、信息充分。
from pathlib import Path from datetime import date def build_today_report(base_dir: Path, scopes: list[str]) -> str: lines = [f"自动化日报 - {date.isoformat(date.today())}", ""] for scope in scopes: target = base_dir / scope if not target.exists(): lines.append(f"[{scope}] 目录不存在") continue files = [p for p in target.rglob("*") if p.is_file()] total_size = sum(p.stat().st_size for p in files) lines.append( f"[{scope}] 文件数: {len(files)}，总占用: {total_size / 1024 / 1024:.2f} MB" ) return "\n".join(lines)这段日报的逻辑很直白，但它背后的设计思路值得多说一句：日报不应该只在数据异常时发，而应该每天固定发送。因为如果你的邮箱只在系统出问题时收到邮件，长时间不发声会让人下意识忽略；每天一封固定格式的短邮件，反而会形成一种稳定的“基线感知”，哪天没收到邮件，立刻会留意到是不是脚本挂了。
5.2 SMTP发送：用加密连接，密码别硬编码
日报生成之后，可以用smtplib发送。核心理念是：密码绝不写死在脚本里，而是从环境变量读取。下面的代码用SSL加密方式连接邮件服务器，然后发送纯文本正文。
import os import smtplib from email.mime.text import MIMEText def send_mail(subject: str, body: str, to_addr: str) -> None: smtp_host = os.environ["SMTP_HOST"] smtp_port = int(os.environ["SMTP_PORT"]) smtp_user = os.environ["SMTP_USER"] smtp_pass = os.environ["SMTP_PASS"] msg = MIMEText(body, "plain", "utf-8") msg["Subject"] = subject msg["From"] = smtp_user msg["To"] = to_addr with smtplib.SMTP_SSL(host=smtp_host, port=smtp_port, timeout=15) as server: server.login(smtp_user, smtp_pass) server.send_message(msg)SMTP_HOST、SMTP_PORT这些变量，我会配置在系统环境变量或一个单独的.env文件中，脚本运行时再读取。这样脚本代码可以安全地放进版本库，不会把密钥泄露出去。
使用SMTP.不是唯一手段，如果你的收件服务支持Webhook形式的通知，也可以直接调Webhook接口，代码会更短。但SMTP的优势是通用性强，几乎所有邮箱服务都支持。测试时可以先发给自己，确认正文格式无误后再部署到正式调度。
5.3 把脚本交给系统调度器，而不是开着终端
脚本写好后，要让它定时执行。最通用、平台差异最小的做法是使用系统自带的调度服务：桌面系统可以打开任务计划程序，服务器类系统可以在命令行里配置crontab。放在crontab里的命令大概长这样：
# 每天上午 9 点执行日报脚本，并把标准输出和错误输出写入日志 0 9 * * * cd /path/to/script && /usr/bin/python3 daily_report.py >> logs/cron_$(date +\%Y-\%m-\%d).log 2>&1这段配置最容易被忽略的是“路径切换”。crontab执行脚本时，工作目录往往不是脚本所在目录，所以代码里所有相对路径都要谨慎处理。我的习惯是在Python脚本开头固定设置BASE_DIR = Path(__file__).parent，所有文件和目录都基于它来拼接，这样无论从哪个目录被调用，行为都保持一致。
定时调度是否稳定，很大程度上取决于环境。脚本依赖的Python包要装在调度器实际调用的Python环境里，这一条看着简单，但我见过很多次部署失败，都是因为在两个不同环境里装了包，导致调度器找不到模块。
6. 开发辅助类：把提交前的检查、图片批处理也自动化起来
最后一组脚本，给程序员和经常处理素材的人。把检查步骤、格式转换步骤写进自动化流程，能明显减少低级错误。
6.1 Git提交前自动检查：让钩子替你挡一次
写代码的人多半经历过这种尴尬：一顿操作猛提交，结果合并消息里带着格式错误，或者把没跑通的代码推到公共分支。Git的钩子机制可以把检查动作绑定到特定事件上。在.git/hooks目录里放一个pre-commit文件，内容可以是直接调脚本的逻辑。
一个实用的例子是：提交之前先跑一遍代码格式检查，并执行已有的测试用例，测试不过就阻止提交。
#!/usr/bin/env python3 import subprocess import sys result_format = subprocess.run(["ruff", "check", "."], capture_output=True, text=True) result_test = subprocess.run(["pytest", "-q"], capture_output=True, text=True) if result_format.returncode != 0: print("格式检查未通过，提交被中止") print(result_format.stdout[-3000:]) sys.exit(1) if result_test.returncode != 0: print("测试未通过，提交被中止") print(result_test.stdout[-3000:]) sys.exit(1) print("提交前检查通过")钩子脚本的关键特点是它运行在本地，而且不会跟随仓库分发给别人。它更像是你自己工作流里的一条“安全带”，而不是团队规范。要提醒的是，提交钩子只拦得住跑这个脚本的人，拦不住绕过钩子的操作，所以它适合用来约束自己，别过度指望它管理团队成员。
6.2 图片批处理：压缩、格式转换、加水印
图片处理是我日常非常需要的一类自动化，毕竟压缩和调整尺寸这件事，脚本一定会比在线工具稳定，而且不传第三方服务，更让人放心。下面这段代码用Pillow库把某目录下所有过大的图片压缩成指定宽度，并统一转成JPEG格式。
from PIL import Image from pathlib import Path source_dir = Path("./originals") target_dir = Path("./processed") target_dir.mkdir(exist_ok=True) max_width = 1600 quality = 82 for img_file in source_dir.glob("*.*"): if img_file.suffix.lower() not in {".jpg", ".jpeg", ".png", ".webp"}: continue try: img = Image.open(img_file) if img.width > max_width: ratio = max_width / img.width img = img.resize((max_width, int(img.height * ratio)), Image.LANCZOS) out_path = target_dir / (img_file.stem + ".jpg") img.convert("RGB").save(out_path, "JPEG", quality=quality) print(f"{img_file.name} -> {out_path.name}") except Exception as exc: print(f"处理失败 {img_file.name}: {exc}")这段脚本里有几个易错点。第一，处理png图片时，如果原图带透明通道，保存成JPEG前必须用convert("RGB")处理，否则会报错或生成黑色背景。第二，批量处理前先检查原始文件目录，确认没有混入程序生成的临时文件。第三，压缩质量不是越高越好，80到85之间通常能兼顾体积和观感。这些细节不测试几轮，很难全部踩到。
6.3 扩充思路：批处理不等于无脑处理
图片处理脚本到了这个程度，已经能解放不少双手了。再往后可以思考一个方向：给批量处理脚本加上“只处理指定时间之后修改的文件”“跳过已经处理过的文件”这类增量逻辑。它们的原理和前面的文件清理、归档脚本类似，都是先列特征、再筛选、最后处理。自动化脚本之间可以通过这种思路互相复用，这也是写脚本有趣的地方。
最后分享一点实操体会
写了这么多样本，真正改变我日常节奏的，反而不是脚本本身，而是一开始坚持的dry-run习惯。几乎所有带破坏性的自动化，我都先让它打印“我要做什么”，再让它真正执行。这条原则救过我很多次，比如一次清理脚本差点误删一个带新版数据的目录，正是因为先跑dry-run看到了异常清单，才在最坏结果发生前刹住车。
另一个建议是：不要追求一个脚本解决所有问题。10个脚本最理想的状态，是每个脚本只专注一个动作，然后通过定时任务、命令行参数、日志串联成一个完整工作流。文件整理脚本负责归位，归档脚本负责压缩，日报脚本负责汇总，邮件脚本负责通知，各有各的边界，出问题时也用不着猜来猜去。
如果这篇内容对你有启发，你可以先从“批量重命名”或者“网页更新监测”这两个脚本里挑一个动手试试。先让它跑起来，再逐步加功能，这个从无到有的过程，比一次性读完十个脚本步骤要实用得多。
