简介：这是一套面向茅台抢购需求用户的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 daemon（Linux），说明守护进程没起来或当前用户没权限。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: - TZ=Asia/Shanghai # 关键：容器时区，别用默认 UTC - CRON=0 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 --tail=100逻辑说明：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 --tail=50参数说明：门店/商品 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 里显式设TZ=Asia/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 章对应条目排查。
最后说句实在的：自动预约能帮你省下每天那几分钟的重复操作，但它改变不了中签本身的随机性。把它当成一个"不会忘事的助手"，而不是"必中的工具"，心态就对了。环境搭一次，之后基本不用碰，这份投入是划算的。希望帮到你。
本文还有配套的精品资源，点击获取
