Python自动化脚本实战：从文件整理到Excel报表与定时任务-平芜编程栈

你有没有过这样的早晨：打开电脑，先把上周的测试报告从十几个文件夹里拖出来，重命名成规范格式，再手工汇总到一张Excel表里，顺便把下载目录里乱七八糟的安装包按类型归置好。等这一套做完，半小时已经过去了，而真正该干的活还没开始。后来我写了一个Python脚本，双击运行，这些事在喝咖啡的间隙里就全部完成了。这篇文章想分享的就是这个脚本从零到诞生的完整过程，包括需求怎么拆、方案怎么选、代码怎么写，以及那些文档里从来不写的坑。

我默认你至少知道Python长什么样，但如果你只是刚看完安装教程、还没写过几行代码，也完全能跟上。文章里每一个结论都会讲清楚为什么这么做，不是为了炫技，是为了让你在复现的时候少走弯路。

1. 项目概述与需求拆解

1.1 自动化脚本到底能解决什么问题

很多人一提“自动化”就想到机器人、流水线，其实日常工作中90%的自动化需求都是很小的事：整理文件、处理表格、批量重命名、定时清理缓存、跑测试用例、把网页上的数据复制下来。这些事有一个共同特点：规则明确、操作重复、出错率低，但就是吃时间。

我自己习惯在动手写脚本之前，先花十分钟把所有想自动化的任务列出来，然后把每个任务拆成三个问题：

这件事是不是每天/每周固定发生？
做这件事的规则能不能用语言描述清楚？
如果操作错了，后果是否可承受？

三个问题都是“是”，就值得自动化。比如“把下载目录里所有jpg文件移动到图片文件夹”规则足够明确，移动错了也能移回来，适合写成脚本。但“帮我把这份方案写得更高级一点”这种需求就不适合，因为规则不清晰，脚本帮不了你。

把需求做减法还有个额外好处：你会发现自己真正需要自动化的事情可能只有三四件，而不是十几件。大多数人的工作痛点不是缺工具，而是没想清楚自己要什么。脚本只是把你的思考结果固化下来而已。

1.2 为什么选Python而不是Shell或批处理

确定需求之后，面临的下一个问题是工具选型。Windows上很多人第一个想到的是批处理bat，Linux上自然是Shell脚本。这两种方案我都重度用过，但最终主力还是切到了Python，原因有三点。

第一，跨平台。我工作的电脑是Windows，服务器是Linux，有时候临时要在macOS上处理点东西。同一个业务逻辑用Shell写一遍、bat再写一遍，维护成本直接翻倍。Python脚本在这三个平台上基本可以做到“写一遍到处跑”，前提是别用平台特有的路径写法。

第二，生态库太丰富了。就拿文件处理和表格汇总来说，Shell处理文本流确实很强，但操作Excel需要调用外部工具，麻烦。Python一个pandas库就能搞定大部分表格需求，一个pathlib库能优雅地处理所有路径问题，这些库经过大量项目验证，比自己写的字符串处理函数靠谱得多。

第三，好维护、好交接。脚本写完三个月后自己回头看的概率很高，更别说同事还要接手。Python的代码可读性在所有脚本语言里算第一梯队，只要稍微注意命名和注释，后续维护成本会低很多。Shell脚本写长了之后，那个语法真的只有写的人能看懂，我自己一个月后看都有些吃力。

用处明确之后，选择Python还有一个现实原因：它可能是你除了Office之外最值得投资的办公技能。从自动化测试框架pytest，到运维领域的Ansible，再到桌面自动化，整个工具链都是围绕Python生态长出来的。你为脚本付出的学习成本，在后续其他自动化项目里都能复用。

2. 环境准备与工程结构设计

2.1 先装好Python并建一个干净的虚拟环境

不管你用Windows、Linux还是macOS，第一步都是装好Python运行时。Windows用户从官网下载安装包的时候，注意安装向导第一页一定要勾选“Add Python to PATH”。这个选项我见过无数人漏掉，结果装完在命令行里敲python提示“不是内部或外部命令”。如果你已经漏了，最简单的修复是重装一遍并勾上，比手动改环境变量省心得多。

Linux用户一般系统自带Python 3，但版本可能偏旧，建议用包管理器装一个较新的版本。macOS用户推荐用Homebrew安装，不要用系统自带的那个，因为系统自带的Python往往被系统工具占用，你给它装第三方库容易把环境搞乱。

装完之后，我强烈建议你在项目目录里建一个虚拟环境。虚拟环境的作用是给当前项目圈一块独立的地盘，里面安装的库不影响系统其他Python程序。这就好比你在公共厨房里给自己准备了一套专用厨具，做完饭收拾好，不影响别人用灶台。

创建和激活的命令很简单，我演示一下：

# Windows python -m venv venv venv\Scripts\activate # Linux / macOS python3 -m venv venv source venv/bin/activate

激活之后，命令行提示符前面会出现(venv)，意思是当前处于虚拟环境里。此后用pip安装的所有库都只会装进这个环境。如果哪天项目做完了想清理，直接把venv目录删掉就行，不留一点垃圾。

2.2 脚本目录别乱来：一个轻量结构就够用

很多刚接触自动化脚本的人，会觉得“我就写一个脚本，要什么目录结构”。我也这么懒过，但当脚本从十几行膨胀到几百行，日志文件和数据文件散落在各个角落的时候，后悔都来不及。

这里分享一个我常用的轻量结构，不复杂，足够应付大部分日常工作自动化：

automation/ ├── main.py # 程序入口，负责调度 ├── config.ini # 配置文件，放路径、阈值等可变参数 ├── core/ # 核心逻辑 │ ├── __init__.py │ ├── file_handler.py │ └── report.py ├── logs/ # 日志输出目录 ├── data/ # 原始数据目录 └── output/ # 处理结果输出目录

不要觉得这是过度设计。把入口和核心逻辑分开，最大的好处是你可以不追求“所有功能一个文件搞定”的怪癖，而把代码当作积木来搭。哪天上位机要加一个定时任务，只需要在main.py里加几行调度逻辑，不用去动文件处理的核心代码。

config.ini这个文件容易被忽略，但实际体验很好。比如归档目录的路径、报表要保留多少天这些参数，写死在代码里的话，每次改都要找到对应函数再小心改；放在配置文件里，用configparser读取，以后调整参数只改文件不改代码，出错概率大幅下降。这就是“把变化的东西和不变的东西分开”的思路体现。

3. 核心脚本实现：从零到能跑

3.1 第一个练手脚本：下载目录自动归档

我的第一个自动化脚本解决的是最朴素的需求：下载目录太乱。浏览器下载的文件总是堆在一起，安装包、图片、PDF、压缩包全部混杂。我决定写一个脚本，把下载目录里的文件按扩展名分类，放到对应的子文件夹里，并且按当天日期建一个二级目录方便追溯。

这里最关键的设计决策是用pathlib而不是os.path来操作路径。pathlib是Python 3.4引入的面向对象路径库，用起来更符合直觉。比如拼接路径，old school写法是os.path.join("downloads", "images")，而pathlib直接用除号操作符：Path("downloads") / "images"，一眼就能看明白。另外它在Windows和Linux上的分隔符差异处理是自动的，这一点在团队协作时特别省心。

核心代码大概长这样：

from pathlib import Path import shutil import datetime DOWNLOAD_DIR = Path.home() / "Downloads" TARGET_ROOT = Path.home() / "Desktop" / "归档" EXT_MAP = { "图片": [".jpg", ".jpeg", ".png", ".gif", ".webp"], "文档": [".pdf", ".docx", ".xlsx", ".pptx", ".txt"], "压缩包": [".zip", ".rar", ".7z", ".tar", ".gz"], "安装包": [".exe", ".msi", ".dmg"], "代码": [".py", ".js", ".ts", ".html", ".css"], } def archive_files(): today = datetime.date.today().isoformat() for file_path in DOWNLOAD_DIR.iterdir(): if not file_path.is_file(): continue ext = file_path.suffix.lower() for category, exts in EXT_MAP.items(): if ext in exts: target_dir = TARGET_ROOT / category / today target_dir.mkdir(parents=True, exist_ok=True) dest = target_dir / file_path.name if not dest.exists(): shutil.move(str(file_path), str(dest)) break if __name__ == "__main__": archive_files()

有几个细节值得提一下。第一，file_path.suffix.lower()是把扩展名统一转小写，否则.JPG和.jpg会被当成两种类型。第二，target_dir.mkdir(parents=True, exist_ok=True)里的parents=True会连带创建父目录，exist_ok=True表示目录存在时也不报错，这两个参数配合使用是创建目录的标准姿势。第三，移动前检查目标文件是否已存在，避免同名文件被覆盖。

写完之后我在自己电脑上测试了几天，又加了一个小功能：跳过正在被占用、无法移动的文件，把错误记录到日志里而不是中断整个任务。这样一来即使有文件移动失败，其余文件也能正常归档。

3.2 让Excel报表自己说话：多文件汇总

文件归档解决了目录整洁问题，但工作中更常见的痛点是Excel报表汇总。每到月底，我需要在十个子目录下各取一个销售明细表，把这些表格的若干列合并成一张大表，再按商品维度做汇总。手工操作要反复复制粘贴，眼睛盯久了还会串行。

Python处理这个需求首选pandas库。pandas读取Excel依赖的是openpyxl引擎，所以在虚拟环境里要安装两个包：

pip install pandas openpyxl

下面是我实际使用过的汇总脚本核心部分：

import pandas as pd from pathlib import Path DATA_DIR = Path("data") files = sorted(DATA_DIR.glob("**/*.xlsx")) frames = [] for f in files: df = pd.read_excel(f) df["来源文件"] = f.name frames.append(df) merged = pd.concat(frames, ignore_index=True) summary = merged.groupby("商品名称", as_index=False)["销售额"].sum() summary.to_excel("output/月度汇总.xlsx", index=False)

这段代码的有趣点在于DATA_DIR.glob("**/*.xlsx")一行就能递归找出所有子目录下的Excel文件，不需要手写遍历的逻辑。pd.read_excel默认读取第一个工作表，如果你的表格里恰好有多个sheet，可以通过sheet_name参数指定。

我在实际执行时经常遇到两类问题，这里提前为你排雷。第一是中文字段名导致的列名匹配问题，groupby("商品名称")要求这个列名在所有表格里完全一致，哪怕多一个空格都会报错。稳妥的做法是在汇总前对列名统一做strip处理：df.columns = df.columns.str.strip()。第二是数据量的问题，如果单个Excel有几万行，pandas加载会比较慢，可以用pd.read_excel(f, read_only=True)减少内存占用，不过openpyxl的原生read_only模式对pandas支持有限，大数据量还是建议改用csv中间格式。

另外，最终输出的Excel如果想要一个好看的格式，可以再用openpyxl调整列宽和表头样式，但我的建议是第一步先保证数据正确，格式美化放在后面迭代。

3.3 老系统没有API怎么办：界面自动化兜底

文件处理和表格汇总还属于“数据层面”的自动化，真正让很多人兴奋的是“界面层面”的自动化：模拟键盘鼠标去操作那些老旧的管理系统。我之所以用“兜底”这个词，是因为界面自动化是所有自动化方案里最脆弱的一种，只要界面布局变了，脚本就可能失效。但有些老系统确实没有API，也没有数据库直连权限，界面自动化是唯一选择。

Python做界面自动化最常用的库是pyautogui。它能控制鼠标移动、点击、键盘输入，甚至能截屏识别屏幕上某个区域的内容。下面是一个最简化的登录操作示例：

import pyautogui import time time.sleep(3) # 给人工留出切换窗口的时间 pyautogui.click(400, 400) pyautogui.typewrite("username", interval=0.05) pyautogui.press("tab") pyautogui.typewrite("password", interval=0.05) pyautogui.press("enter")

这段代码最大的问题在于坐标是写死的。如果换一台电脑或者分辨率变了，按钮位置就全错。我在实际项目中会做一个截屏定位的辅助工具，先在屏幕上截取一个按钮的小图片，然后让pyautogui在屏幕范围内搜索这个图片，找到就点击，这样至少能扛住分辨率变化：

btn_pos = pyautogui.locateCenterOnScreen("button.png", confidence=0.8) if btn_pos: pyautogui.click(btn_pos) else: raise RuntimeError("没有找到按钮图标")

这里confidence=0.8的意思是允许80%的相似度匹配，因为不同屏幕上按钮渲染效果会有细微差别。注意locateCenterOnScreen对性能有一定消耗，每次搜索大概需要零点几秒到几秒，不要在一个循环里高频调用。

界面上自动化还有一条铁律：必须在脚本开头设置“紧急停止”机制。我的做法是让脚本定期检测鼠标是否被移动到了屏幕左上角，一旦检测到就立即终止程序。这样当脚本失控乱点的时候，我只需要把鼠标甩到角落就能截停它。不要觉得这多余，我亲眼见过同事的自动化脚本在界面上疯狂点击了几分钟才被强制关闭，造成了一批错误数据。

4. 让脚本更健壮：日志、异常与调试

4.1 日志不是可选项：怎么记录脚本的一生

脚本只要能自己在后台跑，就一定需要考虑“出了问题我怎么知道”。很多人用print来输出信息，但print有两个硬伤：程序关掉之后输出就没了；输出到控制台的信息没有分级，日常跑得太顺的时候一片刷屏，真出问题反而看不清。

Python标准库logging模块是解决这个问题的正路。我常用的配置是把日志同时输出到文件和终端，日志文件按大小自动轮转，避免单个文件无限膨胀：

import logging from logging.handlers import RotatingFileHandler logger = logging.getLogger("auto_task") logger.setLevel(logging.INFO) fmt = logging.Formatter('%(asctime)s %(levelname)s %(message)s') fh = RotatingFileHandler("logs/auto.log", maxBytes=1_000_000, backupCount=5, encoding="utf-8") fh.setFormatter(fmt) ch = logging.StreamHandler() ch.setFormatter(fmt) logger.addHandler(fh) logger.addHandler(ch)

这样配置之后，logger.info("开始归档文件")会在控制台和文件里同时留下一条带时间的记录。文件达到1MB就自动轮转，保留最近5个文件，旧日志自动删除。日志轮转这个功能我强烈建议加上，否则脚本跑半年能产生几个GB的日志，磁盘被吃光之前你根本不会发现。

日志还有一个隐含价值：它是复盘脚本性能的依据。你看日志里每条记录的时间戳，就能算出某个环节耗时多少秒，进而定位性能瓶颈。没有日志的脚本就像没有黑匣子的飞机，出了事只能猜。

4.2 异常与重试：脚本不会一直顺风顺水

自动化脚本跑在无人看守的深夜时，网络抖动、文件被占用、权限缺失这些小事都会让它中断。一个健壮的脚本需要在异常处理上做两层功夫。

第一层是精确捕获异常，不要大包大揽。我见过有人在代码最外层套了一个except Exception: pass，结果所有错误都被吞掉了，脚本看起来“成功”了，实际上什么都没干。正确做法是预估可能出现的异常类型并分别处理：

try: shutil.move(src, dst) except FileNotFoundError: logger.error("源文件不存在: %s", src) except PermissionError: logger.warning("文件被占用，稍后重试: %s", src) except shutil.Error as e: logger.error("移动失败: %s", e)

第二层是重试机制。很多瞬时错误不用立刻放弃，退避重试往往就能成功。下面是一个轻量级重试装饰器，我把通用逻辑抽出来，每个函数都能复用：

import time from functools import wraps def retry(max_attempts=3, delay=2): def decorator(func): @wraps(func) def wrapper(*args, **kwargs): for attempt in range(1, max_attempts + 1): try: return func(*args, **kwargs) except Exception as e: logger.warning("第%s次执行失败: %s", attempt, e) if attempt == max_attempts: raise time.sleep(delay * attempt) return wrapper return decorator @retry(max_attempts=3, delay=1) def download_file(url): # 下载逻辑 ...

注意time.sleep(delay * attempt)是递增等待，第一次失败等1秒，第二次等2秒，第三次直接放弃。这种退避策略比固定间隔更温和，不会在服务恢复高峰期集中重试造成雪崩。重试只对瞬时错误有意义，如果你的程序是逻辑错误，重试一万次也是白搭，所以在加装饰器前先判断错误类型是不是值得重试的那种。

4.3 那些年我们踩过的调试坑

脚本写多了，总会遇到一些奇奇怪怪的问题。这里挑三个最常见的坑分享，每一个我都亲手踩过。

第一个坑是编码问题。Windows下打开文件默认编码是gbk，而Python 3里字符串默认是utf-8，两者不一致就会出现UnicodeDecodeError。解决方法是打开文件时显式指定编码：

with open("data.txt", encoding="utf-8") as f: content = f.read()

在Windows上写代码，这个习惯能从源头避免掉一半的编码问题。

第二个坑是当前工作目录。很多人以为脚本在哪个目录就用哪个目录，其实不一定。如果从Windows的任务计划程序里启动脚本，工作目录默认是C:\Windows\System32，脚本里相对路径data/会指向一个你意想不到的地方。所以我建议所有涉及路径的代码都基于脚本自身所在目录去拼接：

from pathlib import Path BASE_DIR = Path(__file__).resolve().parent DATA_DIR = BASE_DIR / "data"

__file__是当前文件的路径，resolve()会解析成绝对路径，这样无论从哪里启动脚本，路径都不会跑偏。

第三个坑是pyautogui的屏幕三秒延时问题。pyautogui为了防止误操作，在调用click/typewrite之前默认有一个安全延时，如果脚本里连续点击多个位置会特别慢。实际做自动化的时候，我通常会在脚本启动时把暂缓存关掉，但绝不在无人值守的场景下开这个开关。

5. 自动化脚本的进阶玩法与落地反思

5.1 定时任务：让脚本变成数字员工

脚本写好了只能手动运行，那还不能叫自动化，顶多是“半自动”。真正全自动要靠定时任务系统来驱动。Linux上标准答案是crontab，Windows上是任务计划程序。

crontab的语法很多人初看会被五个星号吓到，其实理解成“分时日月周”五个字段就行。比如每天凌晨2点执行归档脚本，在命令行输入crontab -e，然后写一行：

0 2 * * * cd /home/user/automation && /home/user/automation/venv/bin/python main.py >> logs/cron.log 2>&1

注意两个细节。第一，这里用的Python是venv里的绝对路径，直接写python的话系统可能用的是另一个版本，导致导入库失败。第二，>> logs/cron.log 2>&1把标准输出和标准错误都追加到同一个日志文件，这样定时任务自己产生的异常也能被看到。

Windows任务计划程序不用写代码，图形界面操作几步就好。关键设置是“操作”里选择“启动程序”，程序填python.exe的路径，参数填主脚本路径，起始于填脚本目录。这里的“起始于”就对应前面说的工作目录问题，一定要填，不然脚本里的相对路径会出错。

如果脚本需要联网才能工作，还要注意网络环境差异。在公司内网正常跑的脚本，放到家里可能因为代理设置不同就失败。我的经验是定时任务不要24小时都开，先跑几天观察日志，确认稳定之后再放开频率。

5.2 从一次性脚本到可复用工具

脚本经历了“能跑”和“能跑稳”的阶段后，自然会有下一个想法：把脚本变成其他人也能用的工具。做到这一步有两个关键手段：参数化和配置化。

参数化是指脚本不再通过修改代码来改变行为，而是通过命令行参数来指定输入。Python标准库argparse可以帮你优雅地解析命令行参数。比如把归档脚本改造成可以指定源目录：

import argparse parser = argparse.ArgumentParser(description="自动归档脚本") parser.add_argument("--source", type=str, default=str(Path.home() / "Downloads"), help="要归档的源目录") parser.add_argument("--dest", type=str, default=str(Path.home() / "Desktop" / "归档"), help="归档目标目录") args = parser.parse_args()

配置化是指把随环境变化的参数放到配置文件里，而不是放在代码里。这个在前面讲目录结构时已经提过，用configparser实现起来也简单，这里不重复展开。

但也要泼一盆冷水：不是所有脚本都要变成工具。如果某个脚本就是解决你个人的特定问题，给代码写注释、放在自己固定的目录，这些就够了。盲目追求“通用”会让代码越来越复杂，最终变成自己都维护不了的四不像。我见过太多人一开始就抽象层满天飞，结果两周后连自己写的类都找不到了。

一句话经验：先让脚本解决今天的问题，再考虑明天的问题。明天的还没来之前，今天的代码越简单越好。

另一个容易犯的错是想让脚本“一把梭”，所有功能塞进一个脚本里。我记得自己曾经写了个脚本，既要整理文件又要发邮件还要生成报表，结果每次改需求都战战兢兢，生怕动了一个模块影响另外一个。后来把功能拆成多个脚本，分别定时执行，反而没什么维护负担了。单一职责原则不光是工程项目的，对个人自动化脚本同样适用。