简介这是一套面向Java/Vue全栈开发者与自动化运维实践者的茅台酒线上预约抢购系统源码专为解决官方App抢购成功率低、人工操作耗时费力等痛点而设计。资源包含549个文件主体为209个Java后端服务模块、87个Vue前端页面组件、84个JS交互逻辑脚本及92个SVG图标资源辅以Redis/Nginx配置、Docker部署文件与多环境YML配置整体包体达201.6MB结构完整、开箱即用。已有201人学习下载覆盖从本地单机部署到云服务器集群上线的全流程。提供手把手图文搭建教程内置上千家门店数据与自动新增门店能力支持多账号并发预约压缩包中含run-web.bat、package.bat等一键启停脚本以及.env.development、nginx.conf等关键配置模板显著降低部署门槛适合具备基础Web开发与Linux运维能力的中级以上技术人员快速落地实战项目。 茅台酒的预约难度做过的人都知道。不只是拼手速还拼账户数量、拼网络延迟、拼对放量时间的判断。人工盯两个账户到点开抢已经是极限账户一多手指根本跟不上。所以我当时做这个茅台预约app程序项目的时候核心诉求就一条把“到点手动点预约”这件事变成一套能够统一编排、按计划触发的自动化流程——每个账户独立登录、独立预约、互不干扰所有结果集中汇总。这套多账户自动预约程序源码的雏形本质上就是一个针对预约场景的批量任务调度系统。这篇文章我就把这套系统从设计到落地的完整思路拆开讲。包括多账户的登录态怎么管理、预约任务怎么排程、出现失败怎么重试、结果怎么通知以及最容易被忽略的稳定性问题。代码部分我尽量用简洁的示例还原核心逻辑你可以直接套用到自己的项目里改也可以只看思路。1. 为什么需要一套多账户预约系统人工抢购的痛点拆解1.1 单账户人工预约的真实瓶颈茅台预约的特殊性在于它的规则预约窗口固定、放量不确定、而且名额有限。人工操作时你需要提前打开小程序或App等到预约时间一到立刻完成选择门店、确认信息、提交预约这三个动作。看起来简单实际上三个动作会在关键节点卡住页面加载慢、按钮位置变化、网络请求超时。举个例子一个人同时管理三个账户每个账户都要走一遍完整的预约流程。时间窗口只有一两分钟三个账户切换下来等你回到第一个账户想二次确认时可能已经错过了最佳提交时机。更别提那些需要滚动验证、拼图验证的环节人工操作的失败率相当高。这个问题的本质不是“手速不够快”而是“单线程人肉操作无法并行处理多个独立会话”。一套多账户自动预约程序解决的正是会话隔离与并行调度的问题。每个账户在程序里是一个独立的会话对象路由到独立的任务执行单元互不干扰也不存在“切来切去”的时间损耗。1.2 系统设计目标与边界在设计这套茅台批量预约软件之前我先明确了一件事它不是一个“无视一切约束的万能抢购器”而是一个预约流程自动化工具。换句话说它的职责是替代你完成重复的点击和提交动作而不是破解、绕过或对抗平台的任何安全机制。基于这个定位系统设计上定了四项目标多账户并行管理每个账户独立运行一个账户出问题不影响其他账户。定时触发按照预约窗口倒计时自动发起预约流程。失败重试与告警网络抖动、服务端繁忙时自动重试实在失败就推送通知。结果可追溯所有操作日志留存方便复盘为什么某个账户没预约上。边界也很清晰不做验证码自动识别、不做协议破解、不做高频撞库。预约业务本身是合规的我只是把人工点击的过程自动化这个方向是安全的。实际开发中所有请求频率也控制在正常操作范围内避免给目标服务造成压力。2. 系统整体架构从账户池到任务调度的分层设计2.1 模块划分与职责边界这套系统的代码结构我划分为四个模块职责非常清晰模块职责关键点配置模块读取账户、预约门店、时间段等参数配置文件独立于代码方便维护会话管理模块负责每个账户的登录、Cookie维护、状态检查多账户隔离的核心任务调度模块管理预约触发时间、重试逻辑、并发控制系统的“心脏”结果处理模块记录结果、生产通知、生成日志便于追溯这样的分层方式有几个实际好处。第一新增账户不需要改代码只改配置第二如果平台接口出现变动只需要调整会话管理模块或任务调度模块里的请求逻辑其他模块不受影响第三每个模块可以独立测试排查问题的时候不用整个项目一起翻。2.2 配置驱动的账户池设计我把每个账户的信息放在一个独立的JSON配置文件里。结构大约是这样的{ accounts: [ { name: account_01, username: 手机号/账号, password: 加密后的密码, store_id: 目标门店ID, reserve_time: 09:00, enabled: true }, { name: account_02, username: 手机号/账号, password: 加密后的密码, store_id: 目标门店ID, reserve_time: 09:00, enabled: false } ], global: { task_interval_seconds: 5, max_retry: 3, timeout_seconds: 10, notify: { type: serverchan, token: 你的通知token } } }密码字段我建议不要用明文保存。实际项目里我用的是对称加密后的密文密钥单独放在环境变量里这样即使配置文件泄露也不会直接暴露所有账户的密码。这一点对于多账户系统来说非常重要账户数量越多配置文件的敏感性越高。加载账户池的时候程序会先读取配置然后逐个初始化会话对象。初始化过程的详细逻辑放到下一节这里先记住一个核心原则每个账户的生命周期是独立的一个账户的登录失败不能阻塞其他账户的初始化。2.3 数据流与执行流程一次完整的预约流程是这样的程序启动加载配置初始化所有已启用的账户会话。每个账户注册一个独立的定时任务触发时间等于用户设置的预约时间减去提前量。到达触发时间后调度器向任务队列投递预约任务。执行器从队列中取出任务调用会话模块完成登录校验、提交预约请求。请求完成后无论成功与否结果写入日志成功则推送通知失败则按重试策略处理。我画不出那些复杂的流程图但你可以把整个系统想象成一家餐厅配置模块是菜单会话模块是每个厨师的个人工具箱调度模块是前台排单的领班结果处理模块是结账和顾客反馈流程。每个环节各干各的活出现问题就在对应环节处理不会蔓延到整个系统。3. 登录态管理与账户保活多账户批量操作最容易翻车的环节3.1 登录态的结构化存储多账户预约系统最常见的翻车点就是登录态串了。很多人写多账户脚本时会把Cookie直接放到一个全局变量里第二个账户登录后覆盖了第一个账户的Cookie结果所有请求都变成了第二个账户的身份预约结果自然是错的。我的做法是给每个账户建立独立的会话对象登录态Cookie、Token、会话时间戳全部存放在对象的属性中。下面这段代码是整个会话管理模块的核心骨架import time import requests from threading import Lock class AccountSession: def __init__(self, account_config: dict): self.name account_config[name] self.username account_config[username] self.store_id account_config[store_id] self.reserve_time account_config[reserve_time] self.session requests.Session() self.logged_in False self.login_time None self._lock Lock() # 设置合理的请求头模拟真实客户端 self.session.headers.update({ User-Agent: Mozilla/5.0 (Linux; Android 12) AppleWebKit/537.36, Accept: application/json, text/plain, */*, Content-Type: application/json;charsetUTF-8 }) def login(self, password: str) - bool: 执行登录操作成功后记录登录态 with self._lock: # 登录接口的地址和参数按照实际平台来调整 login_url https://example.com/api/login payload { username: self.username, password: password } try: resp self.session.post(login_url, jsonpayload, timeout10) if resp.status_code 200 and resp.json().get(code) 0: self.logged_in True self.login_time time.time() return True except requests.RequestException as e: print(f[{self.name}] 登录请求异常: {e}) return False def is_logged_in(self) - bool: 判断登录态是否仍然有效 return self.logged_in and (time.time() - self.login_time) 7200 def submit_reservation(self) - dict: 提交预约请求 if not self.is_logged_in(): self.login(self._load_password()) reserve_url https://example.com/api/reserve payload { storeId: self.store_id, reserveDate: time.strftime(%Y-%m-%d) } resp self.session.post(reserve_url, jsonpayload, timeout10) return resp.json()每个AccountSession对象内部有一把独立的锁防止同一个账户的多个任务并发执行时产生竞态条件。不同账户之间因为持有不同的Session实例天然就做到了隔离。3.2 会话失效检测与自动剔除预约场景里最常见的异常是“登录态失效”。原因无非两种一是平台服务端升级、Token过期时间缩短二是多账户的请求IP相同触发了服务端的异常风控导致部分会话被强制下线。针对这种情况我的做法是在每次预约请求前做一次轻量级的登录态校验。调用一个状态查询接口如果返回的code表示未登录就先将这个账户标记为“待重新登录”然后触发一次重新登录流程。如果重登失败就跳过该账户的本次预约并将异常记录到日志中。这比每次请求失败后盲目重试要高效得多。盲目重试等于在一个已经失效的会话上反复做无用功浪费了预约窗口内最宝贵的时间。而精准剔除失效账户可以尽快给其他正常账户留出请求资源。3.3 验证码与设备指纹的本地化处理很多预约平台在登录环节要求输入验证码。这部分我不建议用第三方打码平台因为涉及账号安全和资金安全最好自己做本地化的验证码识别方案。我实测下来简单的图形验证码用模板匹配就可以达到70%以上的识别率如果是滑块验证码就需要做轨迹模拟模拟人类拖拽的加速度变化。不过这里有个重要的策略问题预约动作本身不是高频动作所以即使登录时遇到验证码也不过是偶尔一次。稍微有点耐心的人肉处理方案是把需要验证码的账户单独拎出来在终端输出验证码图片让操作员手动输入。这看似“半自动”实际比纯自动识别更稳定。设备指纹方面我给每个会话绑定了一个固定的device_id参数并且在连续请求之间加入随机延迟避免请求特征单一化。具体的延迟逻辑请参考下一节。4. 预约排程与自动重试时间窗口内的并发控制4.1 时间同步与触发策略预约系统对时间精度有要求。本地时钟如果不准可能在平台还没放量的时候就发出了请求或者在放量之后才发起都会影响成功率。我的做法是启动时进行一次NTP时间校准获取与本地时间的偏差值然后在后续所有定时计算中加上这个偏差。实现代码如下import ntplib import time from datetime import datetime, timedelta def get_time_offset() - float: try: client ntplib.NTPClient() response client.request(ntp.aliyun.com, timeout5) return response.offset except Exception: return 0.0 # 在程序启动时获取偏移量 time_offset get_time_offset() def get_current_accurate_time() - datetime: return datetime.now() timedelta(secondstime_offset)触发策略上我采用了“提前触发预请求预热”的方式。假设预约窗口是09:00:00我不会等到09:00:00才发起请求而是在09:00:00.5左右发起。这里的0.5秒提前量是根据本地网络延迟和服务器处理时间的估算值具体数值需要在实测中调整。其实更稳妥的做法是在接近窗口时先发送一次“状态查询”请求这个请求有两个作用一是确认网络链路畅通二是保持会话活跃。等真正的预约窗口到来时预约请求可以走一条已经被验证过的链路成功率会高不少。4.2 请求调度与限流多账户批量预约带来的直接问题是压力集中。假设你有20个账户每个账户在9点整同时发出预约请求目标服务器同一瞬间收到20个请求这看起来不多但如果这20个请求的UA、设备指纹、操作轨迹完全一致很容易被识别为异常。所以调度模块里我做了两件事全局并发令牌和随机请求间隔。所谓全局并发令牌就是用一个信号量控制同时发出的请求数量避免一拥而上。import random import time from threading import BoundedSemaphore, Thread # 全局并发控制最多同时5个请求 semaphore BoundedSemaphore(5) def submit_with_throttle(account_session: AccountSession) - dict: with semaphore: # 在提交前加入随机延迟降低请求特征一致性 delay random.uniform(0.3, 0.8) time.sleep(delay) result account_session.submit_reservation() # 请求完成后稍作停顿 time.sleep(random.uniform(0.5, 1.2)) return result这里我加在请求前后的随机延迟不是为了恶意占用资源而是让请求节奏更接近人工操作的模式降低触发风控误判的概率。实测下来合理的随机延迟不会明显影响预约成功率反而会让整体执行的稳定性更好。4.3 重试策略与幂等性设计预约请求失败是可预期的。网络抖动、服务端繁忙、参数校验不过都可能失败关键是怎么重试。重试策略我采用的是“指数退避抖动”的方式。第一次失败后等待2秒第二次失败等待4秒第三次失败等待8秒每次重试前再加一个0到1秒的随机偏移。设置最大重试次数为3到5次超过上限就将该账户标记为失败推送告警。这里有个容易被忽视的细节预约请求的幂等性设计。预约操作涉及服务端状态变更如果重试时重复提交相同的预约请求可能会生成重复的预约记录。所以每次提交预约请求时我会在请求体里带上一个由会话ID和当前日期生成的唯一请求号。服务端如果收到相同的请求号会直接返回已处理的成功结果而不是再次创建预约。import hashlib def generate_request_id(account_name: str, reserve_date: str) - str: raw f{account_name}_{reserve_date}_{int(time.time())} return hashlib.md5(raw.encode()).hexdigest()一次预约生成的所有重试请求都复用同一个request_id这是保证幂等的关键。5. 日志、通知与结果落库预约完不等于结束5.1 结果落库与日志设计预约提交完成后很多人直接看返回结果就结束了。但如果预约失败想要复盘原因没有日志就只能抓瞎。所以我为每个账户建立了独立的运行日志文件并按日期切分日志内容包括每次请求的时间戳、请求URL、HTTP状态码、返回内容摘要、耗时。同时结果要落库。我用的方案是SQLite因为单机运行不需要引入重型的数据库服务。表结构很简单CREATE TABLE reserve_records ( id INTEGER PRIMARY KEY AUTOINCREMENT, account_name TEXT NOT NULL, request_id TEXT NOT NULL, status INTEGER NOT NULL, message TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );每次预约请求完成后无论成功与否都会写入一条记录。这样你可以在一天结束后通过SQL查询快速看到所有账户的执行情况哪些成功了、哪些失败了、失败原因是什么。这里的记录也为后续调优提供了数据基础。5.2 多渠道通知预约结果通知我用的是Server酱和邮件双通道。Server酱适合推送简单文本消息速度快邮件适合推送包含详细日志的附件。两条通道互为备份避免单一通道故障导致错过预约结果。通知内容不要只写“成功”或“失败”两个词。我在实际项目中是这样设计的【预约执行完成】2024-05-20 09:00 账户: account_01 状态: 成功 耗时: 1.2s如果失败则追加失败原因和已执行的重试次数。这样即使你不盯着程序看也能在手机上快速判断是否需要人工介入。5.3 对账与复盘预约系统跑完之后最忌讳的是只看到“成功”就直接收工。你需要对账实际预约成功数量是否等于你设置的分店和日期有没有出现“请求成功但服务端返回业务失败”的情况我遇到过一种典型问题HTTP状态码是200返回的JSON里业务code也是0但实际上预约并没有生效因为参数中缺少了某个非必填字段服务端静默忽略了。这种情况只有对账才能发现。我的做法是预约成功后过一段随机时间比如5到10分钟再次调用预约状态查询接口验证该账户的预约记录是否真实存在。如果有预约记录才代表真正成功否则按失败处理。这一步比较容易被忽略但对于预约系统的可靠性提升非常明显。尤其是多账户大量预约时个别账户的“假成功”如果不筛查掉会造成你以为全预约上了实际只预约上了一部分的尴尬局面。6. 部署稳定性与合规使用经验6.1 定时自动启动与守护进程部署方面因为涉及定时任务服务器不能关机。我推荐跑在一台低配云服务器上或者长期在线的家用电脑上用Docker运行。如果用Docker建议把代码打包成镜像然后把配置文件和SQLite数据库通过volume挂载到宿主机方便备份和修改。下面是Dockerfile的关键部分FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple COPY . . CMD [python, main.py]启动时用docker run -d --name moutai-reserve -v /host/config:/app/config -v /host/data:/app/data moutai-reserve即可。如果需要在固定时间重启程序来释放内存或重新初始化会话可以配合crontab实现比如每天凌晨3点重启容器这样能保证预约当天程序处于全新状态。6.2 常见故障排查我在实际使用中遇到的故障主要有以下几类现象可能原因排查方法提交预约请求超时网络问题或服务器压力大查看日志中的耗时分布确认是否集中在某个时间段多个账户登录失败请求体参数变动或验证码策略升级抓取最新的一次真实请求对比参数差异重试触发但始终失败账户被服务端临时限制停止该账户的重试等待一段时间后再手动触发通知收不到Server酱token过期或邮件被当作垃圾邮件检查通知模块日志确认token有效期和邮箱反垃圾策略日志是最好的排查工具。我建议日志中至少包含请求ID、账户名、请求时间、URL、状态码、返回内容片段、耗时。这些信息加齐了绝大多数问题都能定位。还有一点下载源码包之后第一步不是急着运行而是先确认zip压缩包完整。这个看起来像是废话但我真的遇到过解压到一半提示file is not a zip file的情况原因就是压缩包没有下载完整。用Linux命令unzip -t 源码包.zip先测试文件是否完整再解压能省很多事。特别说明解压后先检查源码目录里有没有隐藏的.env或config.local.yaml文件有些项目会引用本地配置直接运行默认配置会产生误导性的报错。6.3 合规使用与风控观察最后说一说合规这个话题。预约系统的本质是预约流程的自动化这是在我理解范围内的正常软件应用。但在实际使用中有几个细节必须注意只使用自己的账户不使用也不收集他人账户信息避免触碰个人信息保护的边界。控制请求频率不做高频请求不给平台服务造成压力。正常预约本来就是短时间的低频操作没有必要也不应该频繁刷接口。遵守平台的使用规则。如果平台的用户协议明确禁止自动化操作那么在分享使用这个项目时就应该限于技术和学习层面不要批量放大使用范围。我自己的体会是这类系统最大的价值不在于“能抢到多少瓶”而在于当你遇到一个完全依赖时间窗口和重复操作的任务时如何用工程化思维把它变成可控、可追踪、可优化的自动化流程。在这个过程中对并发控制、会话管理、异常处理、日志分析这些基本功的锻炼远比省下来的那几分钟更有意义。如果你也准备动手做一套自己的预约系统我建议从最简版本开始先跑通一个账户的登录和预约接口再逐步叠加多账户和调度逻辑。不要一上来就追求复杂的架构预约场景的接口调用链路并不长把每一步的日志和异常处理做好系统的稳定性自然就有了。本文还有配套的精品资源点击获取