简介这是一套面向茅台抢购需求用户的i茅台自动预约解决方案基于Docker容器化部署适合具备基础运维或开发能力的技术爱好者使用。压缩包共542个文件约2.99MB以Java源码209个为核心业务实现Vue与JavaScript文件87个vue、84个js构成前端界面另有svg图标、xml配置、scss样式及yml、bat部署脚本整体是一套前后端分离的完整工程。项目通过Docker一键启动省去手动配置环境的繁琐可每日定时自动执行预约任务。资源内含完整源码目录与部署脚本读者可据此了解自动预约的接口调用逻辑、任务调度方式与容器化打包流程并在此基础上自行调整预约参数与运行策略。目前已有1483人学习下载适合希望研究自动化预约实现思路、学习Docker部署实战的开发者参考。1. i茅台每日自动预约把重复点击交给容器把时间留给正事每天九点整手指悬在屏幕上点进小程序、选门店、选规格、确认、再确认一套动作重复几十天中签率却依旧看运气。i茅台app自动预约这件事本质上不是抢而是把一套固定流程做成定时任务每天到点自动完成预约动作结果通过通知告诉你。它解决的是人会忘、人会懒、人会手抖点错这三个问题而不是提高中签概率——这点必须先说清楚否则预期就歪了。适合谁每天要手动预约、又不想被时间绑住的人手上有一台常年开机的 NAS、软路由、云主机或旧笔记本的人愿意花半小时把环境跑起来、之后基本不用管的人。标题里支持docker一键部署是关键卖点它意味着你不用在宿主机上装一堆依赖镜像拉下来、挂个配置、起容器任务就跑起来了。下面按先搞懂它在干什么 → 再动手部署 → 再排坑的顺序讲透新手能照着走熟手能看清边界。2. 自动预约到底在自动化什么从登录态到定时触发2.1 拆开看一次预约由哪几段组成把自动预约当成一个黑匣子它内部其实只有四段拿到有效登录态、构造预约请求、在正确的时间发出、把结果落盘或推送。任何一环断了任务都会静默失败——这也是很多人部署成功了但没预约上的根因。第一段是登录态。i茅台这类小程序/App 的接口调用依赖一个有时效的凭证常见是 token 或 cookie 组合。这个凭证会过期过期后所有请求都会被拒。所以自动预约方案的核心难点从来不是发请求而是凭证怎么持续有效。常见做法有两种一种是手动抓一次凭证填进配置到期了自己换另一种是用账号密码走登录流程自动刷新。前者简单但需要人维护后者省心但对账号安全和风控更敏感。我一般建议先用第一种把流程跑通确认整条链路没问题再考虑要不要上自动刷新。第二段是请求构造。预约接口通常需要几个固定参数商品/门店标识、预约数量、时间戳、以及一个签名或校验字段。签名往往是最容易翻车的地方——它可能依赖请求体、时间戳和某个密钥按特定顺序拼接再哈希。参数错一个返回就是参数错误而不是预约失败两者排查方向完全不同。第三段是时间。预约通常有固定开放时间服务器时间和本地时间不一致会导致提前太多被拒或晚了没名额。容器里默认是 UTC 时区这是新手最常踩的坑之一后面会专门讲。第四段是结果处理。预约成功、失败、凭证过期这三种状态要能区分并通知你否则你永远不知道任务到底跑没跑。2.2 为什么用 Docker 而不是直接跑脚本直接python main.py也能跑但你会遇到依赖版本冲突、Python 版本不对、换台机器要重装一遍、开机自启要自己配 systemd。Docker 把这些打包进镜像换来三个实际好处环境一致本地能跑服务器就能跑、隔离不污染宿主机、易迁移换个机器拉镜像即可。代价也有镜像体积、时区、网络、权限这几个容器特有的问题会冒出来。所以一键部署不等于零配置它省的是装依赖的功夫配置和排错还是得自己做。理解这一点后面看报错就不会慌。2.3 部署前必须确认的三件事动手前先确认宿主机能正常访问目标服务网络通不通决定了后面所有请求的成败宿主机时间准确date命令看一眼偏差超过一分钟就要校准你有一份可用的凭证或账号信息。这三件事任何一件没搞定容器起来也是白起。提示先把凭证、时区、网络这三样在宿主机上验证通过再进容器能省掉一大半排查时间。3. Docker 一键部署实操从拉镜像到跑通第一次预约3.1 环境准备Docker 与 Docker Compose 装好Linux 上用官方脚本装最省事Windows 用户装 Docker Desktop 即可需要开启 WSL2否则会报 virtualization support not detected 之类的启动失败。装完先验证# 确认 docker 与 compose 都可用 docker --version docker compose version # 确认守护进程在跑能拉镜像 docker info如果docker info报failed to connect to the docker api at npipe://...Windows或Cannot connect to the Docker daemonLinux说明守护进程没起来或当前用户没权限。Linux 下把用户加入 docker 组sudo usermod -aG docker $USER然后重新登录。这一步不做后面每条 docker 命令都要加 sudo很别扭。3.2 用 compose 起容器一份可抄的配置比起一长串docker run我更推荐 compose配置可读、可版本管理、重启方便。下面是一份通用模板字段按你实际镜像和路径改services: moutai: image: your-image:latest # 替换为实际镜像名 container_name: moutai-auto restart: unless-stopped # 崩溃或重启后自动拉起 environment: - TZAsia/Shanghai # 关键容器时区别用默认 UTC - CRON0 9 * * * # 每天 09:00 触发按实际开放时间改 volumes: - ./config:/app/config # 凭证与参数配置持久化到宿主机 - ./logs:/app/logs # 日志落盘排查全靠它 network_mode: bridge启动与查看# 后台启动 docker compose up -d # 看容器状态确认是 Up 而不是 Restarting docker compose ps # 实时看日志第一次务必盯着 docker compose logs -f --tail100逻辑说明restart: unless-stopped保证宿主机重启后容器自动回来TZ决定容器内定时任务按哪个时区触发这是到点没执行的头号原因volumes把配置和日志挂出来容器删了数据还在。参数说明CRON是标准五段式分 时 日 月 周0 9 * * *表示每天 9:00如果你的预约开放时间是 9:30就写30 9 * * *别照抄。3.3 配置凭证与参数改哪几个字段配置一般放在./config下的一个 yaml 或 json 里。典型字段包括账号标识、凭证token/cookie、目标门店或商品 ID、预约数量、通知方式。改完不用重建镜像重启容器即可生效# 改完 config 后重启让新配置加载 docker compose restart # 确认配置被正确读取日志里通常会打印加载到的门店/时间 docker compose logs --tail50参数说明门店/商品 ID 一定要用你实际想约的那个填错会约到别的门店凭证字段注意不要有多余空格或换行复制粘贴时最容易带上通知配置如 webhook 地址建议先单独测一次确认能收到消息否则任务成功了你也不知道。3.4 验证第一次预约是否真的发出去了别等到第二天看结果手动触发一次最快。多数镜像支持手动执行入口# 进容器手动跑一次观察完整输出 docker compose exec moutai python /app/main.py --once看输出里有没有请求已发送返回码 200预约成功/失败这类关键行。如果返回的是鉴权错误说明凭证问题如果是参数错误回去核对门店 ID 和签名相关字段如果卡住不动多半是网络不通。这一步跑通定时任务基本就稳了。注意手动触发和定时触发走的是同一套逻辑手动能成定时大概率也能成手动都不成别指望定时能救。4. 避坑与排查那些让任务静默失败的细节4.1 现象容器是 Up但到点没任何动静原因九成是时区问题。容器默认 UTC你按北京时间设的 9 点实际在 UTC 9 点北京时间 17 点才触发或者干脆错位。解决在 compose 里显式设TZAsia/Shanghai重启后进容器date确认输出是北京时间。另一个可能是 cron 表达式写错用在线 cron 解析器核对一遍。4.2 现象日志报鉴权失败 / 401 / token 过期原因凭证有时效手动填的那份过期了。解决重新抓取凭证更新到 config重启容器。如果想省事就上自动刷新登录态的方案但要清楚这会让账号在非官方客户端登录风控风险自担。我的习惯是凭证快到期前手动换一次稳且可控。4.3 现象请求发出但返回参数错误原因签名或时间戳不对。签名依赖的字段顺序、编码方式、时间戳精度秒还是毫秒任何一处不符都会失败。解决对照抓包结果逐字段核对重点看时间戳单位和签名字符串拼接顺序。这类问题没有捷径只能一个字段一个字段比。4.4 现象容器内访问不了外部接口宿主机却正常原因容器网络配置问题常见于自定义网络或 DNS 没配好。解决先docker compose exec moutai ping 目标域名测连通性不通就检查network_mode必要时显式指定 DNS在 compose 里加dns: 223.5.5.5。宿主机能通不代表容器能通这是两套网络栈。4.5 现象镜像拉取慢或超时原因默认镜像源在境外网络抖动。解决配置国内镜像加速器在 Docker Desktop 设置或/etc/docker/daemon.json里加 registry-mirrors重启 Docker 服务后重试。这一步只影响拉取速度不影响运行。提示把每次失败的日志片段留下来比记我试过不行有用得多。排查的本质是缩小范围日志就是缩小范围的依据。5. 让它长期稳定跑监控、通知与凭证续期的一个小技巧部署跑通只是开始真正省心的是跑一个月不用管。这里给三个我实际在用的做法。第一加健康检查。在 compose 里给容器配healthcheck或者用一个独立的定时脚本每天检查日志最后修改时间超过 25 小时没更新就说明任务没跑发通知给自己。这比等你想起来去看强得多。第二通知要分级。预约成功、凭证过期、连续失败这三种消息重要性不同。成功可以静默或低优先级凭证过期和连续失败必须高优先级推送因为它们需要你立刻处理。很多人把所有消息都设成一样结果消息一多就麻木真正该看的反而漏了。第三凭证续期的小技巧。如果你不想上自动登录可以设一个日历提醒在凭证预计过期前两三天手动更新。更稳的做法是把凭证有效期也写进配置让脚本在临近过期时主动发通知提醒你换而不是等它失效后任务失败才发现。这个提前量是我踩过几次坑之后固定下来的习惯——失败一次可能就错过一整天的预约窗口。验证方法上我一般会连续观察三天的日志第一天确认触发时间对第二天确认凭证没掉第三天确认结果通知正常。三天都稳基本可以放手。如果中间任何一天异常回到第 4 章对应条目排查。最后说句实在的自动预约能帮你省下每天那几分钟的重复操作但它改变不了中签本身的随机性。把它当成一个不会忘事的助手而不是必中的工具心态就对了。环境搭一次之后基本不用碰这份投入是划算的。希望帮到你。本文还有配套的精品资源点击获取