Python 三合一自动化演示脚本这种标题听上去像是个练手项目但实际做下来你会发现爬虫 清洗 报表一旦串成自动化流水线它解决的是整个数据供应链的问题而不是某个单点的小需求。我最近重构了一套这类脚本从架构拆分到落地部署跑了整整一个迭代周期现在把它拆开聊聊。新脚本的宿命往往是上线跑两周就被淘汰。爬虫、清洗、报表这三件事如果各写各的那更惨——今天改一下抓取逻辑明天清洗那边就报字段找不到后天报表格式又对不上。我见过不少开发者在这套组合上反复返工核心问题不是技术难而是从一开始就没把抓-洗-报当成一条流水线去设计。这个标题里的脚本本质上是在做一件事把网页采集、数据整理、结果呈现打包成一个可执行的自动化链路。爬虫负责拿原始数据清洗模块负责把杂乱无章的内容变成结构化数据报表模块负责把结果输出成Excel、CSV这类容易交付的文件。三块既能独立运行也可以串联执行而且通过配置文件和模块化拆分让这套脚本具备了长期迭代的条件。我从这个项目里最想拿出来分享的不是某个高深算法而是整个链路的设计取舍、代码组织方式以及那些文档里查不到、只有实际跑过才会碰到的细节问题。1. 项目背景与整体设计思路1.1 为什么要把三件事装进同一个工程先从业务视角看。如果只是临时取一次数你完全可以用浏览器手动下载、拿Excel随便处理处理。可一旦需求变成每天早上自动更新数据、每周自动出报表问题性质就变了你需要的是可重复运行、可稳定运行、出了问题还能快速定位的程序而不是一锤子买卖的脚本。拆开看三件事各自的难点爬虫的难点在于变化——目标页面的结构会调整、接口参数会变、网站的风控策略会升级写死的代码随时可能失效清洗的难点在于脏——缺失值、重复记录、类型混乱、编码异常、字段格式不统一真实世界的原始数据很少能直接进报表报表的难点在于呈现——同一个数据集管汇总的人想看指标、实操的人想看明细、协作方想要可读的共享格式要求五花八门。把三件事放进同一个工程最重要的原因不是省事而是让数据在采集→清洗→报表之间的流转有唯一、清晰的路径。数据从爬虫输出什么格式、清洗后变成什么结构、报表按什么字段渲染都在一个代码库里定义改起来不会牵一发动全身。工程项目最怕的就是数据在各环节之间变形不自知三合一能帮你把这条路径锁死。1.2 模块解耦看起来是一个脚本实际上是三个可独立维护的模块三合一不等于三坨代码塞在一个文件里。我在这个项目里采用的是按职责分文件的模块结构project/ ├── main.py # 入口支持单跑、全跑、定时跑 ├── config.yaml # 采集源、清洗规则、报表参数集中配置 ├── collector/ # 爬虫模块 │ ├── fetcher.py # 请求层限速、重试、UA轮换 │ └── parser.py # 解析层HTML解析、字段提取 ├── cleaner/ # 清洗模块 │ ├── rules.py # 清洗规则定义 │ └── pipeline.py # 清洗流水线编排 ├── reporter/ # 报表模块 │ ├── exporter.py # Excel/CSV导出 │ └── templates/ # 报表模板 ├── utils/ │ ├── logger.py # 日志 │ └── notifier.py # 异常通知可选 └── tests/ # 各模块的冒烟测试这个结构的好处是哪一环出问题就进哪个目录排查互不干扰新需求来了比如新增一个数据源只需要在collector里加一个parser其他模块完全不动。模块之间通过函数的输入输出约定进行交互数据格式用固定的字典或DataFrame结构传递这就把耦合降到最低。1.3 技术选型为什么锁定Python这套组合选型逻辑很直白网络请求领域的requests/httpx生态成熟、数据处理领域pandas几乎是事实标准、报表输出用openpyxl能精细控制Excel表现三者都用Python语言栈统一学习成本和维护成本都最低。不少同行会质疑为什么不换Go、不换Node。答案很简单这个项目追求的是快速交付 好维护而不是极致性能。数据量在百万级以下Python完全扛得住项目组里随便一个人都能改Python这才是长期维护最大的优势。性能瓶颈真出现了再针对单点优化也不迟。代码组织上每个模块入口函数都很短核心逻辑全部分布在具体的处理函数里。这是刻意为之——长函数是维护者的噩梦拆成短函数之后测试、定位、替换都轻松得多。2. 爬虫模块打造稳定的采集入口2.1 请求层的关键设计会话、限速、重试爬虫最基础也最容易翻车的就是请求层。新手写爬虫往往就是直接发一个GET请求结果跑不到几百个请求就被限制。我在项目里做了三层防护。第一是会话复用。用Session对象保持连接避免频繁重建TCP连接。对于需要登录态的采集场景Cookie直接挂在session上就行不用手动去拼请求头。第二是请求限速。在config.yaml里配置请求间隔参数每次请求之间强制sleep。别觉得慢稳定比速度重要得多。实测下来限速1秒的爬虫跑几小时不出问题的概率远高于每分钟狂发几十个请求的写法。尤其是同一网站多批次连续采集时限速是保命符。第三是重试机制。网络抖动、临时限流、超时都是常态写一个带指数退避的重试函数遇到异常先间隔1秒重试再隔2秒、4秒……重试次数和最大退避时间都做成配置项。这样网站偶尔抽风时脚本不会直接退出而是自己缓一缓再试。import time import random import requests from requests.adapters import HTTPAdapter def make_session(ua: str) - requests.Session: s requests.Session() s.headers.update({User-Agent: ua}) adapter HTTPAdapter(max_retries0) s.mount(http://, adapter) s.mount(https://, adapter) return s def fetch_with_retry( session: requests.Session, url: str, max_retries: int 3, base_interval: float 2.0, **kwargs, ) - requests.Response: for attempt in range(max_retries): try: resp session.get(url, timeout15, **kwargs) resp.raise_for_status() return resp except (requests.ConnectionError, requests.Timeout, requests.HTTPError) as exc: if attempt max_retries - 1: raise exc sleep_time base_interval * (2 ** attempt) random.uniform(0, 1) time.sleep(sleep_time) raise RuntimeError(unreachable)核心思路是把请求行为和业务行为分开。请求层只管把数据拿回来解析层只管从HTML里提取字段两者互不打扰。将来如果要从requests换成httpx只需要改fetcher.py一个文件。User-Agent也不用固定在代码里在配置里维护一个小池子每个请求随机取一个能显著降低被识别为脚本的概率。2.2 页面解析选择正确的解析工具解析层的选型我踩过不少坑最后沉淀下来的经验是数据藏在HTML标签里优先用BeautifulSoup配合lxml解析器写起来直观、容错性好数据藏在接口返回的JSON里直接用标准库json处理绕开HTML解析性能和稳定性都高很多页面结构复杂、追求精准定位和高性能再用XPath或者parsel。实际项目中很多采集任务的本质不是解析页面而是找接口。打开浏览器开发者工具的网络面板很多看似由HTML渲染的内容其实来自某个公开的JSON接口。直接抓接口比解析HTML稳定得多不仅字段清晰而且接口结构变动频率通常低于页面视觉改版。能用JSON解决的绝对不用正则去抠HTML。2.3 字段提取的通用技巧别把格式写死在爬虫里爬虫最容易犯的毛病是把显示格式当成数据格式存下来。比如页面上写着1,234人直接存成字符串后面清洗还得再拆。更稳的做法是爬虫只取下层的原始值能拿数字就拿数字能在页面源码里找到数值属性的就不要用渲染后的文本。另一个技巧是字段名统一走英文蛇形命名比如user_name、view_count而不是中文或者页面上的显示名。这样清洗模块和报表模块引用字段时没有歧义也不会因为页面文案变化导致字段失效。采集完毕的数据统一落成JSON Lines或CSV暂存文件名带上时间戳。这一步是给后面的清洗模块做输入准备的格式越简单中间环节越不容易出问题。3. 数据清洗把脏数据变成可计算的数据3.1 真实数据到底脏在哪里很多人以为清洗就是去掉空值实际遇到的脏数据种类相当多。这个项目里我总结过一张清单基本覆盖了采集数据的常见问题脏数据类型常见例子处理方式缺失值某条记录没有发布时间填充默认值或删除记录重复记录同一内容被抓多次按主键字段或内容指纹去重类型错误数字被读成字符串强制转换并捕获异常文本杂讯字符串带换行、多余空格、残留标签正则清洗格式不统一日期有2024-1-1和2024年01月01日统一转成datetime类型量纲不统一金额单位有万、亿统一换算后存储清洗不是越暴力越好。举个例子缺失值直接删记录虽然简单但如果字段缺失比例很高删掉会让最终报表数据量骤减正确做法是分析缺失原因区分偶发缺失和结构性缺失。结构性缺失说明采集阶段就有问题要回到采集端修而不是靠清洗硬扛。3.2 用pandas写清洗流水线清洗模块的核心是pipeline.py流程是读入采集文件、逐条应用清洗规则、输出标准DataFrame、交给报表模块。每一条清洗规则都被写成独立的函数接收DataFrame、返回DataFrame方便单测和组合。import pandas as pd from typing import Callable def drop_duplicate_rows(df: pd.DataFrame, subset: list[str]) - pd.DataFrame: return df.drop_duplicates(subsetsubset, keepfirst) def normalize_date_column(df: pd.DataFrame, col: str) - pd.DataFrame: df[col] pd.to_datetime(df[col], errorscoerce) return df def strip_text_columns(df: pd.DataFrame, cols: list[str]) - pd.DataFrame: for col in cols: df[col] df[col].astype(str).str.strip() return df def build_pipeline(rules: list[Callable[[pd.DataFrame], pd.DataFrame]]) - Callable: def run(df: pd.DataFrame) - pd.DataFrame: for rule in rules: df rule(df) return df return run这里有个很重要的设计原则规则函数是纯函数不修改外部状态只负责传入一个DataFrame、返回一个新的DataFrame。这样每条规则都能独立测试也能随时调换顺序。实际维护时发现清洗规则顺序会影响结果比如先归一化日期再去重可能会因为日期格式不同导致重复判断失败——把顺序做成显式配置更稳妥。3.3 清洗规则做成配置而不是代码清洗规则里最常变的是阈值字段名默认值这些如果硬编码在代码里每次调整都要动代码、重新部署维护成本很高。我在项目里把清洗参数抽到config.yamlclean: drop_duplicates: subset: [content_id] date_columns: - publish_time defaults: platform: unknown value_maps: status: {1: active, 0: inactive}代码读配置、配置驱动逻辑这是长期维护最核心的开销节省点。业务人员想调整报表口径不需要找开发改代码只需要会改yaml文件这在实际交付中非常加分。3.4 添加内容指纹去重多数据源、多任务跑同一个目标时最隐蔽的问题是重复采集。先采集了100条另一个任务又采集100条两批数据汇到一起变成200条去重逻辑如果只靠业务主键一旦主键不一致就漏掉。我的解决办法是给每条采集记录生成一个指纹用来源URL、内容标题、发布时间三个字段拼接后计算hash作为记录标识在清洗阶段按指纹去重。这样不管多少个数据源汇进来重复记录都能被识别和剔除。这个设计不炫技但非常实用。4. 报表生成让结果真正可交付4.1 先搞清楚报表给谁看报表模块最容易犯的错是不管受众一视同仁地输出一堆密密麻麻的明细数据。实际上给管理层看的核心是汇总指标总数、趋势、同环比、关键排行给业务看的核心是明细和筛选可以按维度下钻、透视给系统用的核心是CSV、JSON这种机器可读格式。设计报表的第一步不是写代码而是确认交付物形态。我的默认做法是明细表单独一个sheet汇总指标放前面的sheet关键变化用条件格式标色。这样一份Excel文件就能同时服务两类人。4.2 用pandas openpyxl输出规范Excelpandas自带的to_excel方法可以快速导出但对单元格样式、列宽、冻结窗格这些可交付性要求就力不从心了。我的做法是pandas负责计算和透视openpyxl负责美化两段逻辑分开写。import pandas as pd from openpyxl import Workbook from openpyxl.styles import Font, PatternFill, Alignment from openpyxl.utils.dataframe import dataframe_to_rows def write_report(df: pd.DataFrame, summary: dict, output_path: str) - None: wb Workbook() ws wb.active ws.title 汇总 ws[A1] 数据来源 ws[B1] summary.get(source, ) ws[A2] 生成时间 ws[B2] summary.get(generated_at, ) ws_detail wb.create_sheet(明细) header_font Font(boldTrue, colorFFFFFF) header_fill PatternFill(start_color4F81BD, end_color4F81BD, fill_typesolid) for row_idx, row in enumerate(dataframe_to_rows(df, indexFalse, headerTrue), start1): ws_detail.append(list(row)) if row_idx 1: for cell in ws_detail[row_idx]: cell.font header_font cell.fill header_fill cell.alignment Alignment(horizontalcenter) ws_detail.freeze_panes A2 ws_detail.auto_filter.ref ws_detail.dimensions for column_cells in ws_detail.columns: length max(len(str(cell.value)) for cell in column_cells if cell.value is not None) ws_detail.column_dimensions[column_cells[0].column_letter].width min(length 2, 50) wb.save(output_path)自动筛选、冻结首行、自适应列宽这几项一定要加。你亲手做的报表直接发给别人时如果连筛选功能都没有用户体验会差很多而这些功能的代码成本其实只有几行。4.3 报表自动化中的三个细节坑第一个是编码问题。用openpyxl写xlsx没有编码问题但如果生成CSV务必用utf-8-sig编码否则Excel打开中文会乱码。这个坑我见过太多次了明明数据没问题交付效果却直接打折。第二个是数值格式问题。pandas读进来的数字有时是浮点数但实际是整数导出后出现一堆100.0很难看。在导出前做一次dtype规范化把整数列转成int必要时把百分比小数保留两位。第三个是Sheet命名和字段标题。让代码生成的Excel直接用英文字段名读者会看不懂用采集端原始字段名又太乱。正确做法是在清洗阶段就映射成按业务口径定义好的列名在报表输出时展示给用户清晰易读的内容。5. 自动化调度与长期维护设计5.1 定时执行方案怎么选自动化的核心诉求是按计划跑、不靠人盯头。Python项目常用的调度方式有几种Windows下直接用系统自带的任务计划程序命令行写成 python main.py run-all配置简单系统自带Linux下用crontab注意要写绝对路径、设置好日志重定向更灵活的可以用APScheduler直接在main.py里调度不依赖外部任务系统如果整个环境已经容器化就用容器编排调度把脚本当成一个常驻服务。我个人推荐从系统自带的定时任务开始。原理都懂、零依赖、失败了有系统日志完全够用。等以后任务多了再迁移到统一调度平台没必要一开始就上重工具。Windows上用计划程序时建议把任务设为不管用户是否登录都要运行否则服务器重启后任务是停着的。5.2 配置与日志长期维护的两根拐杖脚本跑一周、一个月之后最怕的不是跑不起来而是它昨天还在跑、今天突然不跑了你却不知道为什么不跑了。解决这个问题主要靠两件事。第一件事是配置文件。把URL、限速、重试次数、清洗规则、输出路径、日志级别全部集中在config.yaml里。长期维护的脚本任何魔法数字都要从代码里移出去。这样不仅改起来清晰还可以用不同的配置文件应对不同环境。第二件事是日志。日志要分级别记录正常运行的进度用INFO、字段异常的告警用WARNING、彻底失败的用ERROR。日志里必须带上关键上下文——采集到哪条URL、清洗了多少行、报表输出到了哪个文件——否则出了问题还得从头翻。日志加上按大小轮转的策略避免跑一个月之后日志文件占满磁盘。5.3 异常治理让脚本自己恢复长期运行的脚本核心能力不是不出错而是出错后能自己恢复。项目里我设计了一层顶层异常捕获每个模块运行前记录开始状态结束后成功或失败状态失败时发送通知到即时通讯工具或邮件做成可插拔的notifier。重试不是万能的。清洗阶段发现数据量比预期少80%这种日志表明采集环节可能出问题了这时候强行重试没有意义应该打印告警并保留原始数据方便人工介入。宁可报错停跑也比生成一份数据缺失的报表要好——停跑了还能被监控发现数据错了直接分发出去就是事故。5.4 模块演进三合一怎么支撑半年后的新需求半年后最常见的需求是加新数据源、改报表口径、调整清洗规则。三合一架构的好处在这里会明显体现新增数据源在collector下新增一个parser函数配置文件里加一条数据源记录其他模块不动改报表结构改reporter里的导出逻辑或者加一个模板不影响采集和清洗调整清洗逻辑在cleaner的rules里改对应规则函数或者直接调config.yaml里的参数。这种加一个文件就能扩展的工程设计前期写的时候多花一点时间后期维护至少省十倍精力。我强烈建议所有做类似项目的同行从第一天起就为扩展留好位置。6. 常见问题与排查技巧实录6.1 采集阶段的高频问题与排查顺序采集阶段最容易遇到的问题是以前能抓的数据突然抓不到了。排查顺序我建议固定下来先用浏览器手动打开目标地址确认网站还在、页面结构没变再跑一次单独的请求调试脚本看是连接超时还是返回异常状态码看返回内容如果返回验证页面或者空白页大概率是风控策略升级了需要调整请求头、补充访问凭证或更换采集入口如果返回正常但解析结果为空检查页面结构是否变化、选择器是否失效。这套排查顺序能避免一个经典误区一抓不到数据就怀疑是代码问题实际上可能是网站本身挂掉了。先定位是哪一层的问题再动手改才能少走弯路。6.2 清洗结果异常怎么定位清洗完发现行数不对、字段全是空值不要急着调代码。先做数据探查# 快速检查清洗前后数据变化 print(cleaned rows:, len(df)) print(unique ids:, df[content_id].nunique()) print(null counts:\n, df.isnull().sum()) print(dtype summary:\n, df.dtypes)先判断是清洗过度还是采集数据本身有缺。很多时候清洗规则没错问题是采集阶段的数据字段已经变了比如之前是数字、现在变成字符串了。这时候正确做法是回到采集模块字段映射那里看而不是在清洗里打补丁。在清洗层硬适配采集层的变更会让清洗逻辑越来越乱这是长期维护的大忌。6.3 报表阶段容易忽略的问题报表阶段的坑大多跟环境有关。明明本地运行正常放到服务器上跑Excel打不开、中文乱码、字体缺失这些问题多半是服务器环境没装中文字体或者缺少依赖库。部署前先在小规模试跑一次验证输出文件的完整性和正确性。另外服务器上跑自动化任务时路径必须用绝对路径。相对路径在你自己电脑上没问题一放到计划任务里就变成当前工作目录不对、找不到配置文件。很多新手脚本上线第一天就挂在这种低级问题上。6.4 关于数据口径的维护提醒有一次报表数据环比下降得很离谱查了半天发现不是程序问题而是上周改过清洗规则把某个状态字段的映射变了历史数据和本周数据口径不一致。从那以后我养成了一个习惯改清洗规则时必须在配置里保留规则版本号并在报表汇总页记录生成规则版本。数据口径变化不可怕可怕的是变化了没人知道。最后一点体会这种三合一脚本最难写的其实不是任何一个模块而是模块之间的数据约定。花时间把你的字段规范、文件命名、输入输出格式定义清楚后面所有维护都会变得轻松很多。字段规范、流程文档写下来的那一刻你的脚本才真正具备了长期生命力。