第一次冒出用 Python 把一个点击动作变成自动化的念头是在连续三天忘打上班卡之后。准确说不是忘了是早上一头扎进会议里等到想起来抬手补卡时OA 考勤页面上的“上班打卡”按钮已经变成了刺眼的红字。于是我给自己开了个 Python 项目名字就叫OA 自动打卡。这篇文章是围绕这个项目做的完整记录内容涵盖动手前的合规思考、技术方案选型、核心代码落地、定时任务配置以及运行之后踩过的真实问题。它不是一篇教你“怎么钻考勤空子”的教程而是一篇把“把一个重复点击动作变成自动化脚本”的全过程反思。适合刚学 Python、想拿真实场景练手的人也适合已经写了一些脚本、想评估“到底该不该自动化”的人。点击一次打卡按钮不过三五秒的事但围绕这三五秒牵扯出的边界问题、环境问题、任务调度问题和维护问题值得单独写一篇首记。1. 动手前先划红线这事能做到什么程度不能做到什么程度1.1 收益与成本的第一笔账我先把“手动打卡”这件事量化了一遍。假设每天早晚各点一次每次打开页面、等待加载、找到按钮、点击、确认结果大约需要 15 秒。一天 30 秒一个月按 22 个工作日算约 11 分钟。说实话这点时间并不值得专门写一个脚本。那真正的收益在哪在于“注意力中断”。开会开到一半手头正改着配置突然想起“卡还没打”于是切到浏览器操作完再切回来表面只花了十几秒实际上思路被打断的代价远高于这个时间。我见过不少人为了不忘记打卡把打卡时间设置成手机闹钟可闹钟响时正好在接电话还是会漏。所以这个项目的真实收益不是节省了多少秒而是“把一件需要记住的事变成了一件不需要记的事”。如果脚本能稳定运行我每天早上不再需要给自己设提醒。1.2 三条红线碰都不要碰在写任何代码之前我先做了合规性评估。这一点远比技术重要。自动化打卡的本质是“代替人手完成一个系统操作”本身是个工具关键看怎么用。我给自己立了三条红线不代打卡脚本只在我本人实际在岗、且本人操作考勤页面合规的前提下运行绝不用于帮别人代打也不在自己未到岗时“远程打卡”。不虚报时间如果当天请假、外勤、迟到脚本宁可失败也不自动补卡。考勤数据的真实性不允许被脚本稀释。不绕过制度动手前我认真查了公司考勤制度。不少公司的员工手册里明确写了“禁止使用自动化工具操作考勤系统”如果制度里明令禁止那就不能做。我后来确认了当前环境没有这条限制才继续推进。这里必须多说一句如果你所在公司的制度里有明确禁止条款请立即停下。代码写出来不难但一旦违反制度轻则书面警告重则影响工作评价。脚本运行得再稳定也稳定不过制度的约束。1.3 我给自己设置的“能跑就行”的验收标准第一次做项目很容易被完美主义拖垮。我当时给自己定了几条务实的验收标准能打开 OA 登录页完成登录。能定位到打卡区域并成功点击。点击后能读出系统返回的“打卡成功”提示。如果 3 分钟内没成功发一条通知给我让我手动处理。脚本一次只解决“上班打卡”下班打卡后续再扩展。这套标准很重要因为它把“写一个完美的软件”缩小成了“写一个能用的脚本”。后来的所有开发都围绕这五条展开没浪费时间去追求不必要的功能。2. 技术选型requests、PyAutoGUI、Selenium 三条路线我为什么走向第三条2.1 requests 最灵活但 OA 页面不让它轻易“看见按钮”最早映入脑海的方案是requests。作为 Python 里最经典的 HTTP 库它可以直接构造登录请求、携带 Cookie、提交打卡参数理论上能做到很轻量甚至不需要浏览器。但打开 OA 考勤页面的源码后我立刻打消了这个念头。现在的 Web 版 OA 系统前端普遍使用现代框架渲染页面打卡按钮并不是一个简单的form加button而是多个异步请求加载完成后才出现的动态节点。登录接口可能有加密参数点击打卡之后还会附带一串由 JS 动态计算的校验字段。用requests模拟这套流程意味着要逆向前端 JavaScript 的加密与拼包逻辑而且 OA 系统一旦升级加密逻辑变了脚本立刻作废。这个维护成本对我这种“首记”项目来说太高了。2.2 PyAutoGUI 能点但像蒙着眼睛敲键盘第二个想到的方案是PyAutoGUI它可以直接控制鼠标键盘截屏识别或按坐标点击。听起来很简单把鼠标移动到打卡按钮的位置按下完事。但实际操作中问题非常明显坐标依赖屏幕分辨率。换显示器、改缩放比例、贴靠窗口位置变化都会导致点击偏移。页面不能预判一旦弹出广告、消息提醒、新手指引坐标就会失效。调试体验差。脚本运行期间鼠标被接管我什么都不能干只能盯着它表演。PyAutoGUI 更适合做演示、做重复性极强且页面固定的操作不适合做需要长期无人值守的考勤脚本。2.3 Selenium 用真实浏览器跑所见即所得最后我选了 Selenium。准确说是用 Selenium 驱动一个真实的浏览器让它像真人一样打开页面、输入账号、点击按钮。Selenium 的优势在于它能拿到浏览器渲染完毕后的完整 DOM 树。页面变成什么样脚本看到的就是什么样。即使按钮位置在屏幕不同位置但只要它在页面结构里有一个稳定的选择器脚本就能找到并点击。再加上显式等待机制可以让脚本等元素出现再操作比固定sleep靠谱得多。做个简单对比维度requestsPyAutoGUISelenium对 JS 动态渲染的支持需要逆向难度高不关心按坐标点原生支持对页面改版的敏感度接口变了就挂位置变了就挂选择器变了才挂对验证码的处理需要单独处理无法智能处理可以等待人工介入维护成本高中中调试直观程度低低高当然Selenium 也有它的代价依赖浏览器驱动、启动慢、资源占用高。但对一个“每天只运行一两次、每次一两分钟”的脚本来说这些代价完全可以接受。2.4 选型后的妥协我接受它的“重”选了 Selenium就等于接受了几个事实必须装一个对应的浏览器驱动版本要和浏览器严格匹配。脚本运行时会弹出一个真实浏览器窗口不能完全“隐形”但可以最小化。运行机器必须保持开机否则没人替我打开浏览器。这些妥协在开发阶段没有困扰我反而是后来维护期的核心成本这部分留到最后一章展开。3. 核心实现从登录到打卡成功的完整链路3.1 环境准备Python、Selenium、浏览器驱动我的环境是 Windows 机器Python 3 环境。安装 Selenium 只用一条命令pip install selenium然后是下载对应浏览器的 WebDriver。这里有个非常容易踩的坑浏览器版本和驱动版本必须匹配。比如浏览器自动更新到了某个版本驱动还在旧版本启动时直接抛SessionNotCreatedException。我当时的做法是先把浏览器更新到指定版本再下载对应版本的驱动放到一个固定目录比如D:\tools\driver。后续有没有踩坑第 5 章会详细说。启动浏览器的最小代码长这样from selenium import webdriver from selenium.webdriver.chrome.service import Service options webdriver.ChromeOptions() # 打开调试窗口方便观察运行时行为 options.add_experimental_option(detach, True) service Service(rD:\tools\driver\chromedriver.exe) driver webdriver.Chrome(serviceservice, optionsoptions) driver.get(https://oa.example.com/login)注意代码里的 OA 地址我换成了示例地址实际使用时替换成你们公司 OA 的登录页即可。账号密码绝对不要写死在代码里这一点后面专门说。3.2 定位打卡元素别用绝对路径用相对选择器打开 OA 页面后按 F12 打开开发者工具找到打卡按钮能看到它对应的 HTML 结构。不同 OA 系统的结构千差万别但定位思路是一致的。我遇到的大致结构长这样div classattendance-panel button idcheckInBtn classbtn btn-primary上班打卡/button /div定位方式有三种常用思路用IDBy.ID, checkInBtn前提是 ID 唯一且稳定。用CSS 选择器By.CSS_SELECTOR, .attendance-panel .btn适合层级比较明显的场景。用XPathBy.XPATH, //button[contains(text(),上班打卡)]适合没有 ID、只能靠文本定位的情况。我最推荐的是“优先 ID → 其次 CSS → 最后相对 XPath”。绝对不建议复制浏览器右键生成的完整 XPath那种一长串的路径会从html一路指下来中间任何一个节点变化整个定位就断了。3.3 主流程代码登录、等待、点击、读结果核心流程拆成四步打开登录页等待登录框出现。填账号密码点登录。等待考勤面板加载完成。找到打卡按钮点击并读取返回结果。关键代码段如下import os import time import logging from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def login(driver): # 账号密码从环境变量读取不写死在代码里 account os.getenv(OA_ACCOUNT) password os.getenv(OA_PASSWORD) WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.ID, loginName)) ) driver.find_element(By.ID, loginName).send_keys(account) driver.find_element(By.ID, password).send_keys(password) driver.find_element(By.ID, loginSubmit).click() # 等待登录完成考勤面板出现 WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.CLASS_NAME, attendance-panel)) ) def check_in(driver): btn WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.ID, checkInBtn)) ) btn.click() # 给页面一点时间展示结果 time.sleep(2) tip driver.find_element(By.CLASS_NAME, result-tip).text logging.info(考勤系统返回%s, tip)这里最核心的一点是不要用固定的time.sleep()去等页面加载要用WebDriverWait配合预期条件。页面网络慢的时候 1 秒弹不出来快的时候 0.2 秒就出来了写死等待时间早晚会出问题。3.4 登录态与验证码能别碰验证码就别碰写到这里你可能会问登录时遇到验证码怎么办我的答案是尽量别让它出现。OA 系统通常在短时间内重复登录时才容易触发验证码。所以我设计的思路是复用登录态第一次登录成功后把浏览器的 Cookie 保存下来下次启动直接加载 Cookie绕过登录页。保存 Cookie 的代码大致如下import pickle # 登录成功后保存 pickle.dump(driver.get_cookies(), open(oa_cookies.pkl, wb)) # 下次启动时加载 for cookie in pickle.load(open(oa_cookies.pkl, rb)): driver.add_cookie(cookie) driver.refresh()这样只要登录态不过期脚本就不需要重新登录自然碰不到验证码。一旦登录态失效我的策略是脚本自动退出并发送通知给人工处理而不是自己去破解验证码。自动化脚本应该把自己限定在合理的范围内不要把心思花在绕过安全机制上。3.5 失败兜底脚本自己不会装死脚本跑在无人值守的时间点最怕的不是报错而是报错之后“安静地失败”。我加上了一层异常捕获和通知逻辑def send_notify(title, content): # 这里是调用某款即时通讯工具的 Webhook 机器人接口 # 把异常信息推送到手机实现快速感知 url os.getenv(WEBHOOK_URL) requests.post(url, json{text: f{title}{content}}, timeout5) try: login(driver) check_in(driver) except Exception as e: logging.exception(打卡流程异常) send_notify(OA打卡失败, str(e)) finally: driver.quit()这层兜底让我从“担心脚本挂了”变成了“挂了会收到通知”。状态的确定性比代码本身的完美度更重要。4. 定时执行让脚本在 8:27 自己醒来4.1 两个调度方案我选了更笨但更直白的一个脚本写好后下一个问题是谁来叫醒它两个主流方案一是Windows 任务计划程序。系统自带界面化配置设定好触发时间后执行python punch.py即可不用常驻后台。二是Python 内的定时调度库比如 APScheduler。可以用BackgroundScheduler在脚本内部起一个定时循环。我最终选了 Windows 任务计划程序。原因很简单这个脚本每天只需要运行一两次任务计划程序足够稳定、足够直观而且即使 Python 脚本崩溃退出系统到点还是会尝试重新拉起不需要我一直开着 Python 进程常驻内存。4.2 不要卡死 8:30 整执行窗口与工作日判断有人会把任务计划设在 8:30:00但这里有个隐藏问题如果那几天系统时间偏差、任务计划排队、网络加载慢脚本晚个几十秒打卡记录就变成迟到了。所以我把触发时间设成了 8:27上班时间是 8:30。脚本到了 8:27 先启动浏览器登录页面等考勤面板加载好再在 8:30 前后完成点击。就算中间有个十几秒延迟也留了缓冲。下班卡同理18:03 触发避免 18:00 整的踩点被系统判定为过早。另外工作日判断必须做。脚本不能在周末也去打卡。我用了datetime判断星期几from datetime import datetime today datetime.now() if today.weekday() 5: # 周六5周日6 send_notify(OA打卡, 今天周末脚本不执行) exit()但这里很快会碰到第二个问题法定节假日。比如国庆放假连休七天星期几判断完全不够用。我的做法是单独维护一个holidays.json文件里面列清楚当年的法定节假日和调休上班日。每年年初花十分钟更新一下比在代码里写死要灵活得多。4.3 日志、通知与“无人值守”的心态建设定时执行最难的其实不是技术而是心态。脚本第一次真正无人值守运行那天我每隔半小时就想看一眼日志。为了让自己少操心我把日志做规范同时把通知做到“只在异常时打扰”正常打卡只写日志不推送。打卡成功但结果文案异常推送一条“请人工确认”。打卡失败或脚本异常立刻推送附带错误信息。日志格式用logging就够了import logging logging.basicConfig( levellogging.INFO, format%(asctime)s %(levelname)s %(message)s, filenamerD:\logs\punch.log, encodingutf-8, )每天打开日志文件看到的应该是类似2025-01-13 08:27:01 INFO 打开OA登录页 2025-01-13 08:27:20 INFO 登录成功 2025-01-13 08:27:35 INFO 考勤系统返回打卡成功 2025-01-13 08:27:36 INFO 打卡流程正常结束盯着这种日志看几次之后我慢慢放下了“必须时刻盯着”的执念。脚本的价值就是把人从重复劳动里解放出来而不是换一种方式继续占用注意力。5. 稳定运行一个月我踩过的五个实际坑这个环节是整篇里最有价值的部分。脚本不是一次写完就结束了真正的问题都在长期运行中暴露出来。5.1 坑一浏览器驱动版本不匹配第一分钟就崩溃现象第一天运行脚本启动后立刻抛异常日志里写着浏览器驱动初始化失败。排查链路先看报错信息确认是WebDriver初始化阶段挂掉。检查浏览器版本和驱动版本。发现浏览器在某个晚上自动更新了新版本驱动还停留在旧版。解决方案下载对应版本的驱动替换旧文件。同时我关掉了浏览器的自动更新策略避免驱动再次失配。这个坑教给我一件事自动化脚本依赖链上的每一个组件都要锁版本。5.2 坑二点击无效因为元素被半透明的“新手指引”盖住了现象脚本找到了打卡按钮click()方法也执行了但结果提示“未检测到打卡动作”。排查链路打开当天运行截图发现页面上覆盖着一层半透明遮罩是系统升级后弹出的“新手指引”。Selenium 执行click()时点击事件被遮罩层拦截压根没落到按钮上。手动情况下用户会先手动关掉这层引导但脚本不知道。解决方案在点击打卡前先检测有没有关闭引导的按钮如果有就优先关闭close_btn driver.find_elements(By.CLASS_NAME, guide-close) if close_btn: close_btn[0].click() time.sleep(0.5)这件事之后我在所有关键操作前都养成了“先排除遮挡层”的习惯。5.3 坑三页面加载慢导致找不到元素不能用 sleep 硬扛现象一天早上脚本报“找不到元素”。排查链路打开日志发现打卡按钮的定位操作在页面加载完成前就执行了。原因是我有一部分代码用了time.sleep(3)等待页面某天网络慢3 秒不够。固定sleep本质上是在赌加载速度赌输一次就失败一次。解决方案把所有“等页面”的逻辑都改成显式等待。WebDriverWait会在元素出现后立即继续最多等满 10 秒网络好时几乎零等待。5.4 坑四节假日判断缺数据假期当天照常打卡现象某天是法定节假日但脚本正常运行在系统里留下了一条打卡记录。排查链路日志显示脚本当天没有终止说明它认为当天是工作日。weekday()只看星期几法定节假日的逻辑没接进来。放假前我忘了把最新的假期配置更新进去。解决方案把节假日数据独立成配置脚本每次运行前读取一次同时给自己设了一个日历提醒每个季度检查一遍配置。偷懒会直接反映在考勤数据里。5.5 坑五登录态半夜过期第二天下班打卡直接失败现象某个周二早上打卡正常傍晚 18:03 脚本报登录状态失效。排查链路检查系统推送的通知错误信息指向“未登录或登录超时”。查日志发现早上登录时保存的 Cookie 当晚被系统服务端清了。我的脚本默认“只要 Cookie 在就一定能用”这个假设不成立。解决方案增加自动重登录逻辑。先尝试用 Cookie 直接进考勤页如果跳回登录页就触发完整登录流程。同时保留“登录页出现验证码就退出并通知人工”的兜底。这样既能自愈常见问题又不会陷入和验证码对抗的泥潭。6. 复盘为什么运行稳定之后我反而决定停用它6.1 三个月的运行数据脚本总共运行了三个多月。我统计了大概的数据上班打卡成功 62 次失败 2 次。下班打卡成功 60 次失败 3 次。失败原因分别是一次驱动失配、一次登录态过期、一次 OA 系统维护无法访问。成功时的平均耗时约 35 秒失败时平均能在我收到通知后 5 分钟内人工处置。从数据上看这个脚本是“合格”的。至少它没有因为自身原因造成迟到或漏卡。6.2 三个维护成本比预期涨得快但三个月里我也发现维护成本比预期高前端改版回归成本。OA 系统每个季度升级一次升级后我必须先跑一遍脚本验证选择器是否还能用。平时不起眼到改版那几天就得专门琢磨。浏览器与驱动版本维护。公司统一推送浏览器安全更新时本机浏览器版本可能被动升级驱动就要跟着换。心理成本。这是我预料之外的部分。每次收到打卡成功通知前我还是会忍不住想看一眼手机。脚本明明是为了省心结果多了新的牵挂。6.3 一个简单判断什么时候该自动化什么时候不该这段经历让我总结出一个简单的判断标准如果手动操作每次只花 15 秒、每天只发生两次却要我用 3 天开发、每周 20 分钟维护那这笔账不划算。真正的自动化应该用在“高频、耗时、人为易错”的场景。考勤点击本身太低频了脚本省下的操作时间远小于我付出的关注成本。它适合作为学习项目未必适合作为长期生产工具。6.4 作为“Python首记”这个项目该谢幕了最终我选择停掉脚本。但我不后悔做这个项目。作为第一个 Python 项目它教会了我几件课本上不写的事一个脚本能跑通 demo 不等于能长期稳定运行真正的工作量在异常处理和排障。工具本身不分善恶边界在人。技术选型的核心不是“哪个最先进”而是“哪个的维护成本我能扛住”。现在回头再看它确实不只是一个自动打卡的脚本更是我第一次完整经历“发现问题 → 设计方案 → 落地实现 → 长期运维 → 复盘取舍”整个闭环。这种经验比每天节省 30 秒有价值多了。如果你也想拿真实场景练手我的建议很直接选一个“影响小、频率低、但能反复折腾”的事情做先让它跑起来再慢慢打磨。过程中犯过的错、踩过的坑都会成为你写下一个项目时的直觉。而直觉恰恰是脚本给不了的。