简介这是一份面向Python初学者与自动化实践者的医院挂号抢号实战脚本资源聚焦解决华西医院等网页挂号场景中人工守候难、验证码识别慢、时间窗口短等痛点问题。资源包共6个文件8KB含核心脚本hospital_auto_register.py、配置文件config.ini、依赖清单requirements.txt、演示页面demo.html、说明文档README.md及项目元数据.inscode覆盖登录模拟、倒计时触发、电子健康卡选择、ddddocr图形验证码识别、循环提交确认等关键环节。已有389人学习下载适合希望掌握Selenium浏览器自动化、验证码图像识别、网页表单交互等实用技能的开发者快速上手与二次适配。读者可直接运行调试理解完整挂号流程的代码组织逻辑并基于ini配置灵活切换目标医院、医生ID与预约时段具备清晰的模块划分与较强的工程可读性。1. Python医院抢号脚本不是“秒杀神器”而是挂号流程自动化与边界合规的工程实践你刷到过“Python医院抢号脚本”这类标题第一反应可能是——这能用真能抢到号会不会被封IP其实90%的所谓“抢号脚本”根本跑不通不是因为代码写得差而是压根没搞清挂号系统的底层逻辑它不是电商库存接口而是一套带多重会话校验、行为风控、人机识别和业务状态锁的医疗服务平台。某高校信息中心曾做过一次内部测试用未经改造的requestsBeautifulSoup脚本模拟挂号请求平均3.2次请求就会触发图形验证码若强行绕过67%的账号在5分钟内被临时限制操作。真正能稳定运行的方案从来不是靠“暴力刷新”而是理解挂号系统如何判断“这是真人还是脚本”——比如时间戳序列是否符合人类点击节奏、Cookie生命周期是否匹配登录态、Referer与历史跳转链是否连贯。本文面向的是有基础Python能力、想把挂号流程中重复性操作如定时查询余号、自动填表、状态轮询工程化落地的开发者不教绕过安全机制只讲怎么在平台规则框架内把“手动点10分钟”压缩成“脚本值守30秒”。你会看到真实可复现的请求构造逻辑、Session管理要点、验证码识别的轻量级接入方式以及最关键的——哪些行为会立刻触发风控、哪些参数改了就等于自曝脚本身份。2. 搭建最小可行挂号自动化从抓包分析到会话保持挂号自动化不是写个for循环发POST就行第一步必须是“看懂系统怎么说话”。绝大多数医院挂号平台尤其省级统一平台采用前后端分离架构关键动作查号源、提交预约、获取验证码全部走XHR接口且依赖完整会话链。下面以某省通用挂号平台以下简称“平台X”为蓝本演示如何构建最小可行自动化链路。2.1 抓包定位核心接口与参数签名逻辑打开浏览器开发者工具F12切换到Network → XHR标签页手动完成一次挂号全流程登录 → 进入科室列表 → 点击医生 → 查看号段 → 点击“预约”。重点观察以下三类请求GET /api/v1/schedule?deptIdxxxdate2024-06-15查号源接口注意Headers里的Authorization字段是否含JWT或时间戳签名POST /api/v1/order/submit提交预约Body里必含timestamp、nonce、sign三元组GET /api/v1/captcha/image?rand123456789图形验证码接口响应头Set-Cookie是否携带JSESSIONID或_token。提示很多新手直接复制curl命令但漏掉关键Header如X-Requested-With: XMLHttpRequest或Cookie中的_gat等统计字段导致请求被服务端直接拒绝。平台X的sign生成逻辑是md5(timestamp nonce secret_key)secret_key需从登录成功后的响应JSON中提取如data.user.tokenKey。2.2 用requests.Session实现全链路会话保活硬编码Cookie或每次重传Authorization极易失效。正确做法是用requests.Session()统一管理Cookie、Header和连接池并封装成挂号客户端类import requests import time import hashlib class HospitalBookingClient: def __init__(self, base_urlhttps://ghxx.yy.gov.cn): self.session requests.Session() self.base_url base_url # 全局默认Header模拟真实浏览器 self.session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, X-Requested-With: XMLHttpRequest, Accept: application/json, text/plain, */*, }) def login(self, username, password): # 登录接口通常返回token和sign_key resp self.session.post( f{self.base_url}/api/v1/auth/login, json{username: username, password: password} ) data resp.json() if data.get(code) 200: self.token data[data][token] self.sign_key data[data][tokenKey] # 后续sign计算用 self.session.headers[Authorization] fBearer {self.token} return True return False def _gen_sign(self, timestamp: int, nonce: str) - str: # 平台X标准sign算法md5(timestamp nonce sign_key) raw f{timestamp}{nonce}{self.sign_key} return hashlib.md5(raw.encode()).hexdigest() def query_schedule(self, dept_id: str, target_date: str): timestamp int(time.time() * 1000) nonce str(int(time.time()))[-6:] # 简化nonce生成 sign self._gen_sign(timestamp, nonce) params { deptId: dept_id, date: target_date, timestamp: timestamp, nonce: nonce, sign: sign } resp self.session.get( f{self.base_url}/api/v1/schedule, paramsparams ) return resp.json()这段代码的关键不在语法而在设计意图session复用TCP连接避免频繁握手开销AuthorizationHeader在登录后动态注入而非写死sign生成严格绑定timestamp和nonce且nonce按平台要求生成平台X要求6位数字部分平台要求UUID所有接口调用都通过同一session实例确保Cookie如JSESSIONID自动透传。3. 验证码识别与人机交互解耦不强求OCR准确率而求流程鲁棒性挂号流程中最不可控的环节是图形验证码。试图用高精度OCR如PaddleOCR识别扭曲字母往往得不偿失——模型训练成本高、泛化差、且平台一旦更换字体或加干扰线就失效。更务实的做法是把验证码识别从“全自动”降级为“半自动策略兜底”用最小代价保障流程不中断。3.1 轻量级验证码处理三步法第一步优先尝试平台提供的语音验证码或短信验证码备用通道很多平台在图形验证码失败3次后会开放短信验证入口。在代码中加入判断逻辑def get_captcha_image(self): # 获取验证码图片 resp self.session.get(f{self.base_url}/api/v1/captcha/image?rand{int(time.time())}) with open(captcha.png, wb) as f: f.write(resp.content) return captcha.png def submit_with_captcha(self, doctor_id, captcha_code): # 提交预约时携带验证码 data { doctorId: doctor_id, captcha: captcha_code, timestamp: int(time.time() * 1000), nonce: str(int(time.time()))[-6:] } data[sign] self._gen_sign(data[timestamp], data[nonce]) resp self.session.post( f{self.base_url}/api/v1/order/submit, jsondata ) result resp.json() # 如果返回需要短信验证主动触发 if result.get(code) 401 and sms in result.get(msg, ): self._trigger_sms_verify(doctor_id) return WAITING_SMS return result第二步本地弹窗人工识别开发调试阶段对非生产环境用tkinter快速弹出验证码图人工输入后继续流程避免陷入OCR调优泥潭import tkinter as tk from PIL import Image, ImageTk def show_captcha_gui(self, img_path): root tk.Tk() root.title(请输入验证码) img Image.open(img_path) photo ImageTk.PhotoImage(img) label tk.Label(root, imagephoto) label.pack() entry tk.Entry(root, font(Arial, 16)) entry.pack(pady10) def on_submit(): self.captcha_input entry.get().strip() root.quit() root.destroy() tk.Button(root, text提交, commandon_submit).pack() root.mainloop() return self.captcha_input第三步生产环境接入第三方打码平台仅限合规场景若确需全自动选择有医疗行业合作案例的商用打码平台如某云OCR API但必须满足接口调用频率≤2次/秒避免被识别为攻击返回失败时自动切回人工模式防止因识别错误导致整个流程卡死所有验证码图片本地不落盘内存中处理完立即销毁。注意直接调用开源OCR模型如CRAFTCRNN在挂号场景下准确率普遍低于65%且模型体积大、推理慢。与其花3天调参不如用1小时接入一个稳定商用API——工程师的价值在于选型权衡而非证明自己能从零造轮子。4. 行为风控规避让脚本“像人一样呼吸”而不是“像机器人一样冲刺”挂号平台的风控系统不是静态规则库而是基于用户行为序列的实时评分模型。它不关心你用不用Python而关心你的操作节奏、路径深度、停留时长是否符合真实患者画像。某三甲医院后台日志显示连续5次“查号→无号→再查”间隔1.2秒的请求98%被标记为异常而间隔在8~15秒之间、且每次请求前有3秒以上页面停留的请求通过率超91%。这意味着脚本的“节拍器”比“发送器”更重要。4.1 时间维度引入非均匀随机延迟固定sleep(1)是风控最敏感的特征之一。真实用户操作存在自然抖动翻页时可能停顿2秒看医生简介选日期时可能犹豫3秒。我们用正态分布模拟这种抖动import random import numpy as np def human_delay(base_sec: float 1.0, std_dev: float 0.3): 生成符合人类操作节奏的延迟秒 base_sec: 基准延迟如查号后等待 std_dev: 标准差控制抖动幅度0.2~0.5较自然 delay np.random.normal(locbase_sec, scalestd_dev) # 截断至合理范围0.5~3.0秒 return max(0.5, min(3.0, delay)) # 使用示例 def auto_book_flow(self, doctor_id, target_date): # 查询号源 schedule self.query_schedule(DEPT001, target_date) time.sleep(human_delay(1.2)) # 查完号等1~2秒再看结果 if not schedule.get(data): print(暂无号源稍后重试) time.sleep(human_delay(8.0)) # 无号时等待更久模拟患者放弃又回来 return False # 有号则进入预约流程 time.sleep(human_delay(2.5)) # 看号段详情停留稍长 # ... 后续步骤4.2 请求维度构造可信的Referer与User-Agent链风控系统会校验请求来源链。如果/api/v1/schedule请求的Referer是https://ghxx.yy.gov.cn/首页但上一个请求根本没有访问首页就会触发质疑。因此所有关键接口调用前必须先GET一次对应页面def ensure_page_context(self, page_url: str): 确保已访问目标页面构造合法Referer链 # 先GET页面建立Referer上下文 self.session.get(f{self.base_url}{page_url}) # 此时session.headers[Referer]已自动设为该页面URL time.sleep(human_delay(0.8)) def query_schedule_safe(self, dept_id: str, target_date: str): # 关键先访问科室页面再查号 self.ensure_page_context(f/department/{dept_id}) time.sleep(human_delay(1.0)) return self.query_schedule(dept_id, target_date)4.3 状态维度主动模拟页面停留与滚动行为部分高级风控会结合前端埋点如监听页面visibilityState、scroll事件。虽然后端无法直接模拟但可通过请求头传递线索# 在关键请求Header中加入模拟行为标识 self.session.headers.update({ X-Page-Visibility: visible, # 模拟页面可见 X-Scroll-Depth: str(random.randint(30, 70)) %, # 模拟滚动深度 X-Interaction-Time: str(int(time.time() * 1000)) # 模拟交互时间戳 })这些字段本身不参与业务逻辑但若平台前端埋点将它们上报至风控后端就能让行为画像更“丰满”。这不是欺骗而是补全脚本缺失的人类行为信号。5. 避坑指南那些让脚本上线即翻车的5个血泪经验写完代码只是开始真正在挂号高峰时段跑起来才会暴露设计盲区。以下是我在多个模拟项目X中踩过的典型坑按“现象→原因→解决”结构整理每一条都对应一次真实翻车现场。5.1 现象脚本运行2小时后突然全部401重启也无效原因未处理token自动续期。平台X的JWT有效期为2小时过期后所有带Authorization的请求返回401但脚本仍用旧token重试形成死循环。解决在请求钩子中拦截401响应自动调用refresh接口如有或重新登录。更稳妥的是在每次关键请求前检查token剩余有效期从JWT payload解析exp字段提前10分钟刷新。5.2 现象验证码识别率忽高忽低白天90%、晚上30%原因平台夜间切换验证码策略——白天用简单数字图凌晨起启用汉字干扰线混合版而OCR模型只训了白天数据。解决不依赖单一识别模型。在get_captcha_image()中增加datetime.now().hour判断夜间自动启用备用通道如短信验证或降低识别阈值失败即转人工。5.3 现象同一IP下多个账号并发请求部分账号被限流原因平台X对单IP的QPS每秒请求数做全局限制非按账号隔离。5个账号共用一个session实际是5倍流量打在同一IP上。解决为每个账号创建独立requests.Session()实例并配置不同代理IP仅限企业白名单代理禁用公共免费代理。若无代理资源则强制串行化请求用threading.Lock()保证同一IP下任意时刻仅1个账号在操作。5.4 现象提交预约成功但患者APP里查不到订单原因忽略了“最终确认”步骤。平台X的/order/submit接口只生成预订单需再调用/order/confirm才算生效而该接口有二次验证码或短信校验。解决完整跟踪挂号流程文档用抓包确认每一步的必要性。宁可多发1次请求也不要假设“提交成功”。5.5 现象脚本在Linux服务器运行正常Windows本地却频繁报SSL证书错误原因Windows系统自带CA证书库陈旧而平台X使用了新签发的Lets Encrypt R3证书requests默认信任系统证书导致SSL handshake失败。解决在Session初始化时指定证书路径self.session.verify /path/to/cacert.pem或全局更新系统证书推荐用certifi包pip install --upgrade certifi。6. 生产就绪 checklist从能跑通到可交付的7个硬性指标写一个能抢到号的脚本和写一个可交付给同事/家人长期使用的工具是两回事。我给自己定了一条铁律任何挂号脚本上线前必须通过以下7项检验。少一项我就不会把它交给别人用——因为那不是帮人是埋雷。6.1 必须支持配置化驱动而非硬编码所有业务参数医院ID、科室ID、医生ID、目标日期、用户名密码必须从外部文件读取格式为config.yamlhospital: base_url: https://ghxx.yy.gov.cn dept_id: DEPT001 doctor_id: DOC12345 target_date: 2024-06-20 account: username: 138****1234 password: enc:xxxxxx # 密码需AES加密存储 schedule: check_interval: 30 # 查号间隔秒 max_retry: 5 # 最大重试次数提示密码绝不明文用cryptography库做AES-256加密密钥由用户首次运行时输入并存入系统keyring避免配置文件泄露风险。6.2 必须提供可视化状态反馈而非黑匣子日志终端输出不能只有[INFO] Submit success而要给出可感知的状态[2024-06-15 07:58:23] 查询科室【心内科】2024-06-20号源... [2024-06-15 07:58:25] ✅ 发现3个号段上午专家号(2)、下午普通号(1) [2024-06-15 07:58:26] 正在提交预约...验证码已识别 [2024-06-15 07:58:28] 预约成功订单号GH20240615000123 [2024-06-15 07:58:28] 已推送微信通知需配置Server酱用emoji时间戳动词短语让非技术人员一眼看懂当前在做什么、结果如何。6.3 必须内置熔断与降级机制当检测到连续3次403禁止访问或503服务不可用时自动暂停所有请求15分钟并发送告警邮件/微信。代码层面用tenacity库实现from tenacity import retry, stop_after_attempt, wait_fixed, before_sleep_log import logging logger logging.getLogger(__name__) retry( stopstop_after_attempt(3), waitwait_fixed(900), # 熔断15分钟 before_sleepbefore_sleep_log(logger, logging.WARNING) ) def robust_query_schedule(self, dept_id, date): resp self.session.get(...) if resp.status_code in [403, 503]: raise Exception(Service blocked, triggering circuit breaker) return resp.json()6.4 必须记录完整审计日志满足基本溯源需求每次运行生成唯一trace_id所有请求/响应关键字段URL、status、耗时、sign摘要、captcha输入写入logs/booking_20240615.log保留30天import uuid trace_id str(uuid.uuid4())[:8] def log_request(self, url, status, duration, captcha): with open(flogs/booking_{time.strftime(%Y%m%d)}.log, a) as f: f.write(f[{trace_id}] {url} | {status} | {duration:.2f}s | captcha:{captcha}\n)6.5 必须支持静默模式与交互模式双启动python booking.py --silent后台运行只写日志不弹窗、不打印python booking.py --interactive开发模式弹验证码窗、打印详细DEBUG日志、允许键盘中断重试。6.6 必须通过平台反爬友好性声明校验在脚本头部添加注释声明遵守robots.txt及平台《用户协议》第X条 Hospital Booking Script v1.2 Complies with https://ghxx.yy.gov.cn/robots.txt Respects rate limit: max 1 request/3s per account Does not bypass CAPTCHA or security controls 这不是形式主义而是划清技术边界——我们优化的是效率不是钻规则空子。6.7 必须提供一键打包与跨平台安装包用pyinstaller打包为Windows.exe、macOS.app、Linux二进制附带install.sh/install.bat3步完成部署# Linux一键安装 curl -sSL https://raw.githubusercontent.com/xxx/booking/main/install.sh | bash # 自动下载二进制、创建桌面快捷方式、配置systemd服务最后说句实在话我写过不下10个挂号脚本最成功的那个不是代码最炫的而是配置文件最清晰、日志最易读、出问题时能30秒定位到哪一行的。技术终归是为人服务当家人凌晨三点收到“号已抢到”的微信消息时他们不会关心你用了asyncio还是threading只会记住——这个工具真的靠谱。希望帮到你。本文还有配套的精品资源点击获取
