每逢腊月我的手机就开始被两类消息刷屏一类是抢票加速包的“好友助力”另一类是复制粘贴式的群发祝福。前几年我也随大流直到有一次盯着12306的刷新按钮盯到凌晨大拇指都快抽筋才意识到这种重复劳动本不应该由人来干。于是去年春节我用Python写了三个自动化脚本把抢票监控、批量祝福、定时提醒这三件事全部交给机器那几天是我过得最轻松的一个年。这篇文章就是那次实践的完整记录。不讲虚的直接说清楚为什么选Python、环境怎么搭、三个脚本分别怎么写、跑起来之后踩了哪些坑以及哪些自动化能做、哪些不该做。如果你也想在春节前搞定这套“数字年味”基建可以参考这份踩过坑的实战笔记。1. 为什么春节自动化是刚需三个脚本解决的痛点1.1 春节场景的三个高频痛点拆解春节的“忙”跟日常工作的忙完全不是一回事。日常忙是任务多、节奏快春节忙是纯体力消耗叠加情绪消耗。先说抢票。12306预售期一出全家人的行程就像一盘散沙落在不同日期、不同车次上。手动刷票时你得反复切换查询条件盯着余票数字从“有”变成“无”再等它从“无”变回“有”。如果是热门线路放票后几分钟内连候补都排不上。这里最折磨人的不是操作本身而是不确定性——你不知道什么时候会放票只能一遍遍刷新把整个人的精力都耗在了一个刷新按钮上。再说群发祝福。我每年通讯录里要点对点发祝福的人有三百多个包括同事、客户、老同学、亲戚。用微信自带群发助手只能选200人上限而且不能针对不同人换称呼。手动逐条发从晚上八点发到凌晨经常发到后半段开始复制粘贴错乱把给张总的祝福发给了李姐场面一度非常尴尬。第三件是提醒类的小事比如抢红包雨时间、年会抽奖投票、给长辈拜年的准确时间节点。这些事单看不难但混在年夜饭、看春晚、打牌这些事里很容易忘。人一旦进入过节状态对“定时”这件事的敏感度会断崖式下降。这三件事有一个共同特征规则明确、操作重复、容错率低。这正是自动化脚本最擅长处理的场景。1.2 为什么选Python而不是其他工具市面上做自动化的工具有很多按键精灵、AutoHotkey、iMacros、甚至Excel里的VBA。为什么最终选了Python我的理由有三条。第一生态覆盖面广。抢票监控需要HTTP请求和JSON解析批量祝福需要模拟键鼠操作或调用接口定时任务需要系统调度这三个需求在Python里都有非常成熟的库requests、json、pyautogui、schedule、logging。不需要在不同工具之间来回跳一个语言全搞定。第二排查问题成本低。自动化脚本最大的坑是“不知道哪里错了”。Python的异常堆栈可读性极高配合requests的响应状态码和pyautogui的截图定位问题基本能在几分钟内定位。而按键精灵这类工具一旦出错你看到的只是“脚本停止”调试体验接近盲人摸象。第三可迁移性。今年写完抢票监控明年改改日期参数就能复用给A客户群发祝福的逻辑换个Excel表格就能给B项目发通知。脚本一旦沉淀下来就是自己的数字化资产。当然Python也有短板打包分发不如Go方便运行效率也不是最高。但春节自动化这种低频、轻量、逻辑简单的场景Python的打法完全够用。1.3 这套方案能做什么、不能做什么先说能做的定时监控12306余票一旦目标车次有票立即推送通知到手机批量生成带称呼的个性化祝福文案按名单逐条发送用定时任务在指定时间点自动执行脚本全程不需要人工盯守日志记录每次执行结果出错自动告警。再说不能做的不能绕过12306的验证码和风控机制去“抢票”。铁路部门的用户协议明确禁止非官方的自动购票行为所以我的方案定位是“监控提醒”把人工操作的等待成本降到最低而不是替代人工下单不能对微信等平台进行大规模、高频的自动化操作。这个我后面会细讲平台风控不是吃素的脚本写得再稳也扛不住封号不能保证100%不出错。网络波动、登录态过期、接口结构调整任何一个环节都可能挂所以必须设计异常兜底。把预期管理做对工具才能真正提升效率而不是给你惹麻烦。2. Python开发环境三件套安装、虚拟环境与IDE配置2.1 本机Python安装的坑与版本选择很多新手第一步就栽在Python安装上。这里把三个主流系统的关键点一次说清。Windows去官网下载安装包时一定要勾选“Add Python to PATH”否则装完在cmd里敲python会提示找不到命令。装完后打开cmd输入python --version验证。如果出现“Microsoft Store”的应用商店跳转说明你用的是系统自带的假入口需要去“设置 - 应用 - 应用执行别名”里把两个python.exe的别名关掉。macOS系统自带的Python 2.7早就不维护了千万别用。建议直接装Homebrew然后brew install python3.12。装完注意看终端提示的PATH路径Homebrew会把Python装到/opt/homebrew/bin如果which python3指向/usr/bin/python3说明还在用系统自带版本。LinuxUbuntu/Debian系执行sudo apt update sudo apt install python3 python3-venv python3-pip。注意不要手动删系统自带的Python很多系统工具依赖它删了会导致桌面环境出问题。版本选择上我建议用3.10或3.11不要盲目追最新版。原因很实际自动化脚本常用的一些库尤其是涉及GUI模拟和旧接口的对新版本Python的适配会有滞后。我实测3.12跑pyautogui在部分Windows环境会有权限弹窗兼容问题而3.11非常稳定。选一个成熟版本远比你用最新版但被依赖库报错卡住要省心。2.2 venv虚拟环境为什么不直接全局安装如果你想把多个Python项目装在同一个环境里很快会碰到“依赖地狱”。A项目需要requests2.28B项目需要requests2.31两个项目共用全局环境升级一个另一个就挂了。venv是Python自带的虚拟环境工具核心作用就是为每个项目创建独立的依赖目录。操作很简单# 创建虚拟环境在项目目录下执行 python -m venv venv # 激活虚拟环境 # Windows venv\Scripts\activate # macOS / Linux source venv/bin/activate # 激活后命令行前面会出现(venv)前缀表示已进入虚拟环境之后用pip install安装的所有包都会进到这个独立环境里不影响系统全局。我第一次做春节脚本时嫌麻烦直接在全局环境装了一堆库结果春节前一周升级了一个依赖库把另一个脚本搞崩了大半夜在那排查依赖冲突血的教训。项目依赖固定下来后用requirements.txt管理# 导出当前虚拟环境的所有依赖 pip freeze requirements.txt # 在新机器上一键还原 pip install -r requirements.txt这个文件我会连同脚本一起存到Git仓库里换电脑、换环境都能快速复原。2.3 IDE选型与调试技巧春节写脚本讲究快、稳、好排查我建议用VS Code加Python插件轻量且调试体验够用。关键配置有三块第一Python解释器指向虚拟环境。在VS Code里按CtrlShiftP输入“Python: Select Interpreter”选择刚才创建的venv目录下的Python。选错解释器是新手最常见的坑写了半天代码运行时报ModuleNotFoundError其实就是解释器没切到虚拟环境。第二开启“Python: Terminal: Activate Env In Current Terminal”这样每次打开新终端VS Code会自动激活虚拟环境。第三学会用断点调试。在代码行号左侧点一下出现红点然后按F5启动调试。程序执行到红点处会暂停你可以逐行查看变量的值。这个功能在排查“接口返回的数据结构和预期不一致”这种问题时比print大法高效十倍。基础环境就绪后接下来进入正题三个脚本逐个拆解。3. 12306余票监控脚本原理、接口分析与时序设计3.1 抢票自动化的工作流程一个完整的12306自动购票流程包括登录、查询余票、提交订单、选择乘客、确认支付。这里面每一环都涉及风控和验证机制。我见过不少人尝试用Selenium控制浏览器去模拟整个购票流程但实际风中控的强度远高于预期验证码识别是专业的图像模型在搞登录状态异常会触发滑块验证高频请求会直接封IP。普通脚本作者在这条路上投入产出比极低而且有合规风险。所以我采用的方案是“只做查询和提醒不做下单”。查询余票这个动作对人来说是重复劳动但对服务器来说只是一个公开的查询接口。这个方案把用户协议里最敏感的“自动化购票”部分绕开了风险和实现成本都大幅下降。省下来的时间足够你在收到提醒后用手机在官方App上一分钟完成手动购票。3.2 余票查询接口实例以requests模拟查询12306的余票查询接口是对外开放的不需要登录也能访问。核心请求是一个GET接口参数包括出发站、到达站、日期。车次信息里包含各席别余票情况。先做车站代码表。12306用的不是“北京”这种中文名而是电报码比如“北京”对应BJP。车站代码表可以提前抓取一次并存成JSON文件避免每查一次就重拉全表。import requests import json # 先请求一次车站代码表频率不要太高存本地复用 def fetch_station_map(): url https://kyfw.12306.cn/otn/resources/js/framework/station_name.js resp requests.get(url, headers{User-Agent: Mozilla/5.0}) text resp.text # 返回格式: var station_names bjb|北京北|BJP|... data text.split()[1].split()[1:] station_map {} for item in data: parts item.split(|) # parts[1]是中文名, parts[2]是电报码 station_map[parts[1]] parts[2] with open(stations.json, w, encodingutf-8) as f: json.dump(station_map, f, ensure_asciiFalse, indent2) return station_map然后用车站代码查余票import requests import json from datetime import datetime, timedelta def query_left_ticket(from_station, to_station, date_str): # 读车站表 with open(stations.json, r, encodingutf-8) as f: station_map json.load(f) from_code station_map.get(from_station) to_code station_map.get(to_station) if not from_code or not to_code: raise ValueError(车站代码不存在请检查中文名) url https://kyfw.12306.cn/otn/leftTicket/query params { leftTicketDTO.train_date: date_str, leftTicketDTO.from_station: from_code, leftTicketDTO.to_station: to_code, purpose_codes: ADULT } headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://kyfw.12306.cn/otn/leftTicket/init } resp requests.get(url, paramsparams, headersheaders, timeout10) resp.raise_for_status() data resp.json() tickets [] if data.get(data) and data[data].get(result): for item in data[data][result]: fields item.split(|) # 关键字段索引3车次, 8出发时间, 9到达时间, 13二等座, 26一等座, 29无座 train_no fields[3] start_time fields[8] end_time fields[9] second_class fields[30] # 各版本字段索引略有差异 first_class fields[31] no_seat fields[29] tickets.append({ 车次: train_no, 出发: start_time, 到达: end_time, 二等座: second_class, 一等座: first_class, 无座: no_seat }) return tickets if __name__ __main__: # 明天 target_date (datetime.now() timedelta(days1)).strftime(%Y-%m-%d) result query_left_ticket(北京, 上海, target_date) for t in result: if t[二等座] not in (无, ): print(f{t[车次]} {t[出发]}-{t[到达]} 二等座有票: {t[二等座]})这里要特别提醒接口返回的字段索引在不同版本可能有变化。我最初从网上找了一份字段表直接跑的时候数据错位把“有票”误判成“无票”还好没有造成实际损失只是虚惊一场。所以写完后第一步是打印原始返回的fields数组对照着确认索引。3.3 数据解析与信息推送查到了余票还要让人及时看到。手机盯屏幕当然可以但既然做了自动化就要把通知也一并自动化。我常用的推送方式有三种推送方式优点缺点适用场景SMTP邮件配置简单、无条件限制可能有延迟、容易进垃圾箱兜底通知Server酱扫码绑定微信、实时推送需要注册获取SendKey个人预警钉钉/企业微信群机器人免费、支持多人接收需要建群、配置Webhook家庭群通知我推荐Server酱作为主力通知通道配置非常轻量。注册后在个人后台拿到一个SendKey然后import requests def send_serverchan(title, content, send_key): url fhttps://sctapi.ftqq.com/{send_key}.send data {title: title, desp: content} resp requests.post(url, datadata) resp.raise_for_status()这样当脚本轮询到目标车次有余票时微信会立刻收到推送标题写“北京到上海 D705 二等座有票”正文放车次详情和购票链接。收到推送后用手机打开官方App手动购票全程不到一分钟。3.4 避开封禁的节奏控制自动化查询有两个“雷区”请求频率过高、请求特征过于统一。请求频率方面官方接口虽然公开但频繁访问同样会被限流。我的实测数据是单次查询请求耗时约200到500毫秒如果把轮询间隔设在1秒以内持续几分钟后大概率返回异常响应或直接超时。稳妥的轮询间隔是3到5秒每查询一次就随机sleep 3到5秒之间的一个值。import random import time interval random.uniform(3, 5) time.sleep(interval)请求特征方面User-Agent不要固定用一个可以在几个常见浏览器的UA池里随机切换。另外建议用requests.Session()保持连接模拟浏览器的行为模式session requests.Session() session.headers.update({ User-Agent: random.choice(UA_LIST), Referer: https://kyfw.12306.cn/otn/leftTicket/init })控制好节奏脚本连续跑几天不出问题是很正常的。4. 祝福消息批量发送从pyautogui模拟操作到模板化文案4.1 消息自动化的三种实现路线群发祝福比抢票更微妙因为涉及社交平台的用户协议。我做这个功能时认真对比过三条技术路线。路线一开放平台官方API。企业微信、钉钉、Telegram这类平台有完善的机器人API合法合规但问题是你的客户、同学、亲戚未必在这类平台上。如果只是给企业客户发这确实是首选。路线二非官方第三方库比如itchat、wechaty这类。它们的原理是通过网页版或HOOK方式接管微信协议。问题在于网页版微信本身在很多账号上不可用HOOK方式更容易触发风控。我在两年前测试过批量发送几十条消息后账号被限制了朋友圈和部分聊天功能折腾了一周才解封。为了发个祝福搭上账号非常不值。路线三桌面端GUI自动化也就是pyautogui模拟鼠标键盘操作。它不介入通信协议本质上是替你在电脑上“手动操作”。优点是不容易被平台判定为协议异常缺点是如果界面布局发生变化脚本需要同步调整。综合来看个人场景下路线三最平衡。本文后续就围绕这条路展开。4.2 模板化祝福文案设计群发祝福最尴尬的一点是“复制粘贴感”太强。发给所有人的文案都是一模一样收的人一眼就能看出来。但逐条现写三百条又不现实所以要用模板加变量的方式做个性化。我的做法是用Excel维护一个联系人名单字段包含姓名、称呼、关系类别、个性化备注。然后准备几个不同风格的模板根据关系类别自动切换。称呼{称呼} 模板同事新年快乐{称呼}感谢这一年的并肩作战。愿新岁平安喜乐诸事顺遂咱们节后见 模板客户尊贵的{称呼}感谢过去一年与您同行。值此新春之际谨祝事业蒸蒸日上身体健康万事如意 模板朋友{称呼}新春大吉愿你岁岁常欢愉万事皆胜意。改天约饭读取Excel用pandas库但春节自动化这种轻量场景只用标准库的csv模块就够了避免为了一个小功能引入重型依赖。import csv contacts [] with open(contacts.csv, encodingutf-8-sig) as f: reader csv.DictReader(f) for row in reader: contacts.append(row) # 模板替换 def gen_message(contact): template contact[template] msg template.replace({称呼}, contact[称呼]) return msg注意CSV文件要用utf-8-sig编码打开否则Excel里写的中文在读取时会乱码。这个细节我第一年就踩过生成的消息批量乱码差点全发出去了。4.3 pyautogui实操打开窗口、定位输入框、发送pyautogui的核心逻辑就三步定位目标坐标、模拟点击输入、按回车发送。第一步最关键也是最容易出问题的。下面是一套我在Windows上稳定跑通的流程import pyautogui import time pyautogui.PAUSE 1.5 # 每个操作之间停顿1.5秒给界面留反应时间 pyautogui.FAILSAFE True # 鼠标快速移到左上角可紧急停止 def send_message_to_contact(contact_name, message): # 1. 打开微信的搜索框快捷键 CtrlF pyautogui.hotkey(ctrl, f) time.sleep(1) # 2. 输入联系人姓名 pyautogui.write(contact_name, interval0.05) time.sleep(1) # 3. 按回车进入聊天窗口 pyautogui.press(enter) time.sleep(1) # 4. 在输入框粘贴消息 pyautogui.write(message, interval0.02) time.sleep(0.5) # 5. 发送 pyautogui.press(enter) time.sleep(1)这里有两个很重要的参数PAUSE和FAILSAFE。PAUSE是每个pyautogui操作之间的默认间隔。如果设成0脚本执行速度会飞快但界面渲染跟不上很容易丢操作。1到1.5秒的间隔虽然看起来“慢”但胜在稳定。FAILSAFE是安全机制。一旦开启如果脚本失控乱飞你只要把鼠标甩到屏幕左上角程序就会立刻抛出pyautogui.FailSafeException并停止避免脚本在不知情的情况下乱点一通。还有一个细节pyautogui.write()对中文支持不太好它在Windows上模拟的是直接按键输入中文会丢字符。最好的方案是先把消息复制到剪贴板再模拟CtrlV粘贴import pyperclip pyperclip.copy(message) pyautogui.hotkey(ctrl, v) pyautogui.press(enter)pyperclip是一个轻量的剪贴板操作库配合pyautogui在中文输入场景下非常好用。4.4 发消息的节奏与风控提醒GUI自动化虽然比协议级操作安全但依然要控制节奏。我实测下来每次发送间隔建议不少于5到8秒每发20条左右暂停一两分钟。频率太高微信PC端的检测机制同样会介入。这里有一个更稳妥的替代思路与其用微信逐条发文字不如把祝福生成一张张长图。用PIL库把文案渲染成图片再通过文件传输助手批量发到手机由你手动转发到朋友圈或群聊。这样操作量大幅下降而且“发图”比“逐条发文字”的触发风控概率低很多。from PIL import Image, ImageDraw, ImageFont def draw_blessing_image(name, message, output_path): img Image.new(RGB, (800, 500), color(255, 248, 235)) draw ImageDraw.Draw(img) # 字体路径根据系统调整Windows可以用微软雅黑 font_title ImageFont.truetype(msyh.ttc, 48) font_text ImageFont.truetype(msyh.ttc, 28) draw.text((60, 60), f{name}新春快乐, fontfont_title, fill(180, 40, 40)) draw.text((60, 200), message, fontfont_text, fill(60, 60, 60)) img.save(output_path)把写好的文案逐条渲染成图片然后手动或半自动发送。这个方案我在去年春节用下来既保住了仪式感又避开了高频操作风险。5. 定时任务调度与异常兜底让脚本自动运行起来的完整方案5.1 定时触发Windows任务计划与Linux cron脚本写好只是第一步关键是让它按计划自动跑。很多人第一反应是在代码里写while True加sleep这在短时间运行可以但长时间驻留有两个问题一是电脑休眠脚本就断二是没有自动重启机制出错后只能人工救。正确的做法是交给操作系统级的定时任务管理器。Windows环境下按WinR输入taskschd.msc打开任务计划程序创建基本任务。触发器选“每天”时间设为早上8点操作选“启动程序”。程序填python.exe的完整路径参数填脚本的完整路径起始于填脚本所在目录。重点注意几个设置“条件”选项卡里取消勾选“只有在计算机使用交流电源时才启动此任务”否则笔记本拔电后任务不会执行“设置”选项卡里勾选“如果任务失败按以下频率重新启动”间隔5分钟最多重启3次关键一步你的Python要激活虚拟环境但任务计划直接执行python.exe不会自动进入虚拟环境所以要么在脚本前加上激活命令要么直接用虚拟环境里的python.exe路径。# 任务计划程序的“操作”里可以直接写 C:\path\to\venv\Scripts\python.exe C:\path\to\ticket_monitor.pyLinux/macOS环境下用crontab配置一行搞定# 每天8点和20点各执行一次余票监控 0 8,20 * * * cd /path/to/project /usr/bin/python3 ticket_monitor.py logs/cron.log 21注意cron执行时的环境变量和终端不一样尤其是PATH。建议在脚本开头用绝对路径或者在crontab里显式声明SHELL和PATH。5.2 日志记录与异常捕获定时任务跑起来后你不可能每次都盯着终端看输出。如果没有日志脚本出错你根本不知道。我用的方案是Python标准库的logging同时输出到文件和控制台import logging logging.basicConfig( levellogging.INFO, format%(asctime)s [%(levelname)s] %(message)s, handlers[ logging.FileHandler(script.log, encodingutf-8), logging.StreamHandler() ] ) logger logging.getLogger(__name__)在关键节点打日志比如“开始查询”“查询结束发现N个车次有票”“网络请求超时重试第2次”。这样出问题后翻日志一眼就能定位是哪一步挂了。异常捕获要区分“可恢复错误”和“不可恢复错误”。网络超时是可恢复的重试几次就好登录态过期是不可恢复的应该立刻发通知让人工介入而不是无限重试。import time MAX_RETRY 3 def query_with_retry(max_retryMAX_RETRY): for attempt in range(1, max_retry 1): try: return query_left_ticket(北京, 上海, date_str) except requests.exceptions.RequestException as e: logger.warning(f第{attempt}次查询失败: {e}) if attempt max_retry: send_serverchan(余票监控异常, f连续{max_retry}次失败请检查网络或接口, send_key) raise time.sleep(10 * attempt)5.3 进程守护让脚本崩了自动重启定时任务适合“短时运行完就退出”的脚本。如果某个脚本需要长时间驻留比如持续监听某个事件那就要引入进程守护。Linux下我用supervisor配置一个简单的守护进程[program:ticket_monitor] command/path/to/venv/bin/python /path/to/ticket_monitor.py directory/path/to/project autostarttrue autorestarttrue stderr_logfile/path/to/logs/err.log stdout_logfile/path/to/logs/out.logautorestarttrue的意思是进程异常退出后自动拉起。这比你在代码里写while True再包一层try...except要可靠得多。Windows下可以用计划任务的“如果任务失败重新启动”做到类似效果或者用脚本套一层死循环但体验一般。个人建议春节这种短周期场景能拆成定时短任务的就不要做成常驻进程复杂度越低越不容易出问题。5.4 断网、登录失效的处理春节在老家网络环境不稳定是常态。我在县城老家实测晚上8点到11点用网高峰期宽带延迟能到200毫秒以上偶尔还会断线。针对断网我的方案是在脚本轮询前先做一次网络连通性检测import socket def is_network_ok(hostwww.baidu.com, timeout3): try: socket.create_connection((host, 80), timeouttimeout) return True except OSError: return False如果是12306的登录态过期查询接口本身不需要登录问题不大。但如果你后续扩展了自动下单功能登录Cookie的刷新管理就是一门学问。我的建议是查询场景保持匿名访问不要为了“省一次手动输入账号”去维护登录态复杂度会成倍上升。6. 脚本落地后的真实体验与合规提醒6.1 实测数据脚本跑了多少天、节省多少时间去年春运我从腊月十六开始跑余票监控脚本到除夕前一天一共跑了14天。目标是从北京回老家的三趟车次。对比前年的手动刷票体验前年我每天早中晚查三次票每次花10到15分钟累计超过6小时而且经常因为没及时看到余票而错过。去年脚本全天候轮询总共推送了7次有票提醒我成功买到了3张票自己和父母各一张实际人工投入时间不超过20分钟——主要是收到推送后的手动下单操作。除夕群发祝福方面往年我从晚上7点发到11点多耗时超过4小时还发错好几次。去年用脚本加长图方案下午4点开始跑5点半全部搞定包含检查和修改的时间。而且因为用了模板加称呼替换每个收件人看到的都是带自己名字的版本反馈明显比以前“复制粘贴”的祝福好。6.2 踩坑记录硬编码带来的连环翻车第一次跑祝福脚本时我把联系人名单直接硬编码在Python文件里看起来省事实际上给后面挖了坑。中途客户名单新增了一个人我得打开代码文件找到那一长串字典小心翼翼地插入一行还要注意逗号不能漏。改完之后突然想到万一代码换行把某个文件夹路径弄乱了怎么办于是我从一开始就决定用csv文件管理联系人数据代码只负责读文件。这样做的好处是数据更新完全不需要碰代码给谁发、不发谁、改称呼一个Excel全搞定。春节前三天你还在加人没关系改完CSV保存脚本下次运行自动生效。这个“数据与逻辑分离”的思路后来也被我用在祝福模板上。模板和文案全部放在一个独立的纯文本文件中脚本按标记读取。调整文案只需要改文本不需要重新看代码逻辑。另一个容易忽视的坑是时区和日期边界问题。腊月二十九的深夜脚本用的是“当天”日期去查询余票结果到了23点50分还在查当天的票车次早就全部开走了白白浪费请求次数。后来我加了判断如果当前时间晚于20点自动把查询日期滚到第二天。6.3 合规边界与风险自检清单自动化这件事技术可行性只是其中一个维度合规和伦理边界同样重要。先说12306。铁路部门在用户协议中明确禁止使用非官方渠道进行自动购票。我的脚本只做“余票查询信息推送”不涉及提交订单、不绕过验证码、不影响购票系统正常使用这在我个人判断中属于可接受的技术实践。但如果你要把它扩展成“全自动抢票”请务必考虑法律风险。我强烈建议保持“监控提醒”的定位把最终决策和执行交给人来完成。再说微信等社交平台。无论用pyautogui还是其他方式批量操作都可能违反平台用户协议并存在账号处罚风险。春节祝福是善意的但善意不能成为行为的免责金牌。我的原则是频率要低、数量要合理、内容要克制。宁可战线拉长一点也不要在短时间轰炸。风险自检清单每次跑脚本前过一遍该操作是否影响其他人的正常使用体验是否遵守了目标平台的服务协议脚本出错时是否有紧急停止机制比如FAILSAFE涉及个人数据的是否只保存了本次任务必需的信息如果脚本被公开是否会让你的账号或平台产生风险最后说一句我自己的体会。Python自动化脚本的价值不在于“替代人”而在于把人的精力从重复劳动中解放出来去做机器做不了的事——比如收到余票提醒后综合时间、价格、换乘方案做出的购票决策比如看完名单后想想今年到底该给谁发什么样的祝福。技术解决“怎么做”但“做什么”和“为什么做”永远是人的课题。希望这篇文章能让你今年的春节少一点机械的忙碌多一点真正属于节日的时间。