简介这是一套面向茅台爱好者与技术用户的i茅台自动预约解决方案通过程序化方式每日自动完成App预约流程省去手动操作并支持Docker一键部署降低环境搭建门槛。资源包共542个文件约2.99MB以Java源码209个为核心后端逻辑配合Vue组件87个与JavaScript脚本84个构建前端界面另有SVG图标、XML配置、SCSS样式及yml、bat等部署与启动脚本整体结构接近一个完整的前后端分离项目。目前已有1483人学习下载说明该方案在自动预约场景中具备一定参考价值。读者可从中获取可运行的预约程序源码、Docker容器化部署配置、前后端模块划分方式以及环境变量与构建脚本示例适合具备Java、Docker基础并希望研究自动化预约实现思路的开发者参考但需自行确认使用行为是否符合平台规则。1. i茅台每日自动预约从手动抢不到到 Docker 一键跑起来每天九点整i茅台 App 的申购页面会准时刷新然后就是熟悉的「当前申购人数过多请稍后再试」。手动点了一个月一瓶没中这不是运气问题是手动操作在时间精度和并发上根本打不过脚本。所谓 i茅台自动预约本质是用程序在每天固定时间窗口内自动完成登录态复用、门店与商品选择、申购请求提交这一整套动作把「人守着点」换成「容器守着跑」。它适合两类人一类是有基本 Linux 或 Docker 基础、想自己掌控运行环境的开发者另一类是手里有 NAS、软路由或一台常开小主机的折腾党。Docker 一键部署的价值在于把 Python 运行环境、依赖库、定时任务、配置文件全部封进镜像换台机器照样跑不用再经历一遍装依赖装到怀疑人生的过程。这一章先把这件事的边界讲清楚后面再拆怎么落地。2. 自动预约到底在自动什么请求链路与登录态拆解2.1 一次申购请求里藏着哪些环节把 i茅台的一次申购拆开看它并不是「点一下按钮」这么简单。完整链路大致是App 启动后校验本地登录凭证拉取当日可申购的商品列表和门店列表用户选定商品与门店后提交申购请求服务端返回申购结果。自动预约脚本要复现的就是这条链路里除了「人选门店」之外的所有环节。其中最关键的是登录态也就是请求头里携带的凭证信息。手动操作时这个凭证由 App 自己维护脚本要做的就是把这个凭证提取出来在有效期内反复使用。这里有个容易被忽略的点凭证是有有效期的短则几小时长则几天过期后所有请求都会返回未登录。所以一个能长期跑的自动预约方案必须处理凭证失效后的重新获取或者至少能在失效时给出明确告警而不是默默失败。很多新手第一次跑脚本第二天发现没申购成功排查半天才发现是凭证过期了这就是典型的「黑匣子」问题。2.2 为什么用 Docker 而不是直接跑 Python 脚本直接在一台机器上跑 Python 脚本当然可以但你会遇到几个现实问题。第一是环境依赖脚本可能依赖特定版本的 requests、schedule 等库和你机器上已有的 Python 环境冲突。第二是定时任务用系统 cron 也能做但 cron 的环境变量和你的登录 shell 不一致经常出现「手动跑没问题cron 跑就报错」的玄学。第三是迁移换台机器要重新配一遍环境。Docker 把这些问题一次性解决镜像里锁死了 Python 版本和依赖版本容器内的定时逻辑不依赖宿主机 cron换机器只需要把镜像和配置文件搬过去。这也是为什么热词里 docker 一键部署、docker compose 出现频率这么高——大家要的就是「一次配好到处能跑」。2.3 最小可跑的 Docker 部署流程下面给出一套通用的部署流程。由于具体镜像名称和仓库地址需要以你实际拿到的为准这里用占位符表示重点是流程和参数含义。# 1. 拉取镜像镜像名以实际为准 docker pull your-image:latest # 2. 准备配置目录存放凭证和商品门店配置 mkdir -p /opt/imt/config cd /opt/imt # 3. 首次运行挂载配置目录设置时区为东八区 docker run -d \ --name imt-auto \ --restart unless-stopped \ -e TZAsia/Shanghai \ -v /opt/imt/config:/app/config \ your-image:latest这段命令里--restart unless-stopped保证容器异常退出后自动拉起这是长期运行的关键-e TZAsia/Shanghai让容器内时间与北京时间一致否则定时任务会在错误的时间触发-v把配置目录挂载出来这样修改配置不用进容器。首次运行后通常需要进入容器或查看日志按提示完成一次凭证录入。# 查看运行日志确认是否正常启动 docker logs -f imt-auto # 如果需要进入容器手动录入凭证 docker exec -it imt-auto /bin/sh日志是排查问题的第一入口。正常启动会打印下次预约时间如果一直报未登录说明凭证没配好。参数方面TZ必须设对--restart策略建议用unless-stopped而不是always方便你手动停掉调试。2.4 docker compose 方式与一键脚本的取舍如果你更习惯 compose可以把上面的命令翻译成docker-compose.ymlversion: 3 services: imt-auto: image: your-image:latest container_name: imt-auto restart: unless-stopped environment: - TZAsia/Shanghai volumes: - ./config:/app/configcompose 的好处是配置即文件版本管理方便改完docker compose up -d即可。一键脚本的好处是门槛更低适合完全不想碰 YAML 的人。我的建议是如果你只有这一台机器跑这一个服务一键脚本够用如果你机器上还跑着别的容器用 compose 统一管理更清爽。两者不冲突选一个顺手的就行。3. 凭证、定时与门店配置三个必须调对的参数3.1 凭证获取与刷新最容易翻车的一步凭证是整个方案的地基。常见做法是手动抓取一次请求头里的关键字段填入配置文件。这个过程需要你用到抓包工具具体工具不展开核心是找到申购请求的 Request Headers把其中标识用户身份的字段复制出来。注意凭证里往往包含时间戳和签名直接复制可能只有很短的有效期。更稳妥的做法是让脚本支持凭证自动刷新但这依赖对登录流程的完整复现难度更高。对于大多数只想稳定跑起来的用户我一般建议先用手动凭证跑通确认整个链路没问题再考虑要不要上自动刷新。手动凭证的刷新频率取决于实际有效期建议每天检查一次日志发现失效及时更新。注意凭证属于个人敏感信息配置文件不要提交到公开仓库也不要在群里截图分享。3.2 定时时间怎么设才不白跑i茅台的申购有固定时间窗口脚本的定时任务必须落在这个窗口内。设早了商品还没上架设晚了名额可能已经满了。常见做法是把触发时间设在窗口开启后的几秒内留出网络请求的缓冲。# 定时逻辑示意实际以镜像内实现为准 import schedule import time def job(): # 这里调用申购流程 do_reserve() # 每天 9:00:02 触发避开整点瞬间的拥堵 schedule.every().day.at(09:00:02).do(job) while True: schedule.run_pending() time.sleep(1)参数上09:00:02这个秒数不是随便写的。整点瞬间是请求高峰稍微错开一两秒反而更容易成功。但也不能太晚具体窗口长度以实际为准。如果你的容器时间不对这个定时就是白设所以前面强调的TZ一定要配对。3.3 门店与商品配置选错等于没跑自动预约需要指定申购哪个商品、哪个门店。配置通常是一个列表脚本会按顺序尝试。这里有个策略问题热门门店中签率低但价值高冷门门店中签率高但可能不是你想要的产品。常见做法是配置多个备选脚本依次提交。配置项含义建议item_id商品标识以实际抓取为准不要手写猜测shop_id门店标识可配多个按优先级排列retry失败重试次数2 到 3 次太多会触发风控interval重试间隔秒数1 到 2 秒太短容易被限流配置完成后先手动触发一次看日志里返回的结果确认商品和门店都正确再交给定时任务。很多人跳过这一步结果跑了一周才发现门店 ID 填错了血泪经验。4. 避坑与排查跑不起来时先看这几条4.1 容器启动就退出现象docker ps看不到容器docker ps -a显示已退出。原因通常是配置文件缺失或格式错误脚本启动时读取失败直接退出。解决先docker logs看报错多半是配置文件路径不对或 JSON 格式有误。检查挂载目录里文件是否真的存在JSON 是否有多余逗号。4.2 日志显示未登录但凭证刚更新过现象明明刚填了新凭证日志还是报未登录。原因可能是凭证字段复制不全或者容器时间与服务器时间偏差过大导致签名校验失败。解决重新抓取完整请求头确认TZ设置正确用date命令在容器内核对时间。4.3 定时到了但没有任何请求发出现象日志显示等待中到了设定时间却没有申购记录。原因通常是容器内时区不对或者定时表达式写错。解决进容器执行date确认时间检查定时配置的时区基准。这是最隐蔽的坑因为脚本本身没报错。4.4 请求频繁被限流现象日志里出现大量失败提示请求过于频繁。原因重试间隔太短或重试次数太多。解决把interval调到 2 秒以上retry降到 2 次。自动预约不是并发越高越好稳定比激进更重要。4.5 换机器后跑不起来现象原来机器上正常迁移到新机器就失败。原因新机器没装 Docker或者 Docker 服务没启动或者镜像没拉全。解决先确认docker info能正常输出再确认镜像存在。Windows 用户注意Docker Desktop 需要 WSL2 支持如果提示 virtualization support not detected要去 BIOS 开启虚拟化。5. 让自动预约更稳的两个进阶技巧第一个技巧是加一层结果通知。脚本跑没跑成功你不看日志就不知道但每天手动看日志不现实。常见做法是接入一个通知渠道申购成功或凭证失效时推送一条消息。实现上就是在申购流程结束后判断返回码命中特定状态就发通知。这样你只需要在收到「凭证失效」时去更新一次其余时间不用管。def notify(msg): # 伪代码替换成你实际使用的通知方式 requests.post(WEBHOOK_URL, json{text: msg}) result do_reserve() if result[code] SUCCESS: notify(申购提交成功) elif result[code] AUTH_FAIL: notify(凭证失效请更新)第二个技巧是给容器加健康检查。Docker 支持HEALTHCHECK指令定期执行一个命令判断服务是否正常。如果脚本卡死健康检查失败后配合--restart策略可以自动重启。这比你自己盯着强。HEALTHCHECK --interval1h --timeout10s \ CMD python /app/healthcheck.py || exit 1参数上interval不用太短一小时一次足够因为预约本身一天就一次。timeout给 10 秒避免误判。最后说个我自己的习惯每次更新凭证后我会手动触发一次申购流程看日志确认返回正常再让它自己跑。这个动作花不了一分钟但能避免「以为在跑其实早就挂了」的情况。自动预约这件事稳定运行比功能花哨重要得多把凭证、时间、门店这三个参数管好基本就不会出大问题。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/9/29 4:01:01 · 阅读 1.2k i茅台自动预约实战：Docker一键部署与避坑指南
简介这是一套面向茅台爱好者与技术用户的i茅台自动预约解决方案通过程序化方式每日自动完成App预约流程省去手动操作并支持Docker一键部署降低环境搭建门槛。资源包共542个文件约2.99MB以Java源码209个为核心后端逻辑配合Vue组件87个与JavaScript脚本84个构建前端界面另有SVG图标、XML配置、SCSS样式及yml、bat等部署与启动脚本整体结构接近一个完整的前后端分离项目。目前已有1483人学习下载说明该方案在自动预约场景中具备一定参考价值。读者可从中获取可运行的预约程序源码、Docker容器化部署配置、前后端模块划分方式以及环境变量与构建脚本示例适合具备Java、Docker基础并希望研究自动化预约实现思路的开发者参考但需自行确认使用行为是否符合平台规则。1. i茅台每日自动预约从手动抢不到到 Docker 一键跑起来每天九点整i茅台 App 的申购页面会准时刷新然后就是熟悉的「当前申购人数过多请稍后再试」。手动点了一个月一瓶没中这不是运气问题是手动操作在时间精度和并发上根本打不过脚本。所谓 i茅台自动预约本质是用程序在每天固定时间窗口内自动完成登录态复用、门店与商品选择、申购请求提交这一整套动作把「人守着点」换成「容器守着跑」。它适合两类人一类是有基本 Linux 或 Docker 基础、想自己掌控运行环境的开发者另一类是手里有 NAS、软路由或一台常开小主机的折腾党。Docker 一键部署的价值在于把 Python 运行环境、依赖库、定时任务、配置文件全部封进镜像换台机器照样跑不用再经历一遍装依赖装到怀疑人生的过程。这一章先把这件事的边界讲清楚后面再拆怎么落地。2. 自动预约到底在自动什么请求链路与登录态拆解2.1 一次申购请求里藏着哪些环节把 i茅台的一次申购拆开看它并不是「点一下按钮」这么简单。完整链路大致是App 启动后校验本地登录凭证拉取当日可申购的商品列表和门店列表用户选定商品与门店后提交申购请求服务端返回申购结果。自动预约脚本要复现的就是这条链路里除了「人选门店」之外的所有环节。其中最关键的是登录态也就是请求头里携带的凭证信息。手动操作时这个凭证由 App 自己维护脚本要做的就是把这个凭证提取出来在有效期内反复使用。这里有个容易被忽略的点凭证是有有效期的短则几小时长则几天过期后所有请求都会返回未登录。所以一个能长期跑的自动预约方案必须处理凭证失效后的重新获取或者至少能在失效时给出明确告警而不是默默失败。很多新手第一次跑脚本第二天发现没申购成功排查半天才发现是凭证过期了这就是典型的「黑匣子」问题。2.2 为什么用 Docker 而不是直接跑 Python 脚本直接在一台机器上跑 Python 脚本当然可以但你会遇到几个现实问题。第一是环境依赖脚本可能依赖特定版本的 requests、schedule 等库和你机器上已有的 Python 环境冲突。第二是定时任务用系统 cron 也能做但 cron 的环境变量和你的登录 shell 不一致经常出现「手动跑没问题cron 跑就报错」的玄学。第三是迁移换台机器要重新配一遍环境。Docker 把这些问题一次性解决镜像里锁死了 Python 版本和依赖版本容器内的定时逻辑不依赖宿主机 cron换机器只需要把镜像和配置文件搬过去。这也是为什么热词里 docker 一键部署、docker compose 出现频率这么高——大家要的就是「一次配好到处能跑」。2.3 最小可跑的 Docker 部署流程下面给出一套通用的部署流程。由于具体镜像名称和仓库地址需要以你实际拿到的为准这里用占位符表示重点是流程和参数含义。# 1. 拉取镜像镜像名以实际为准 docker pull your-image:latest # 2. 准备配置目录存放凭证和商品门店配置 mkdir -p /opt/imt/config cd /opt/imt # 3. 首次运行挂载配置目录设置时区为东八区 docker run -d \ --name imt-auto \ --restart unless-stopped \ -e TZAsia/Shanghai \ -v /opt/imt/config:/app/config \ your-image:latest这段命令里--restart unless-stopped保证容器异常退出后自动拉起这是长期运行的关键-e TZAsia/Shanghai让容器内时间与北京时间一致否则定时任务会在错误的时间触发-v把配置目录挂载出来这样修改配置不用进容器。首次运行后通常需要进入容器或查看日志按提示完成一次凭证录入。# 查看运行日志确认是否正常启动 docker logs -f imt-auto # 如果需要进入容器手动录入凭证 docker exec -it imt-auto /bin/sh日志是排查问题的第一入口。正常启动会打印下次预约时间如果一直报未登录说明凭证没配好。参数方面TZ必须设对--restart策略建议用unless-stopped而不是always方便你手动停掉调试。2.4 docker compose 方式与一键脚本的取舍如果你更习惯 compose可以把上面的命令翻译成docker-compose.ymlversion: 3 services: imt-auto: image: your-image:latest container_name: imt-auto restart: unless-stopped environment: - TZAsia/Shanghai volumes: - ./config:/app/configcompose 的好处是配置即文件版本管理方便改完docker compose up -d即可。一键脚本的好处是门槛更低适合完全不想碰 YAML 的人。我的建议是如果你只有这一台机器跑这一个服务一键脚本够用如果你机器上还跑着别的容器用 compose 统一管理更清爽。两者不冲突选一个顺手的就行。3. 凭证、定时与门店配置三个必须调对的参数3.1 凭证获取与刷新最容易翻车的一步凭证是整个方案的地基。常见做法是手动抓取一次请求头里的关键字段填入配置文件。这个过程需要你用到抓包工具具体工具不展开核心是找到申购请求的 Request Headers把其中标识用户身份的字段复制出来。注意凭证里往往包含时间戳和签名直接复制可能只有很短的有效期。更稳妥的做法是让脚本支持凭证自动刷新但这依赖对登录流程的完整复现难度更高。对于大多数只想稳定跑起来的用户我一般建议先用手动凭证跑通确认整个链路没问题再考虑要不要上自动刷新。手动凭证的刷新频率取决于实际有效期建议每天检查一次日志发现失效及时更新。注意凭证属于个人敏感信息配置文件不要提交到公开仓库也不要在群里截图分享。3.2 定时时间怎么设才不白跑i茅台的申购有固定时间窗口脚本的定时任务必须落在这个窗口内。设早了商品还没上架设晚了名额可能已经满了。常见做法是把触发时间设在窗口开启后的几秒内留出网络请求的缓冲。# 定时逻辑示意实际以镜像内实现为准 import schedule import time def job(): # 这里调用申购流程 do_reserve() # 每天 9:00:02 触发避开整点瞬间的拥堵 schedule.every().day.at(09:00:02).do(job) while True: schedule.run_pending() time.sleep(1)参数上09:00:02这个秒数不是随便写的。整点瞬间是请求高峰稍微错开一两秒反而更容易成功。但也不能太晚具体窗口长度以实际为准。如果你的容器时间不对这个定时就是白设所以前面强调的TZ一定要配对。3.3 门店与商品配置选错等于没跑自动预约需要指定申购哪个商品、哪个门店。配置通常是一个列表脚本会按顺序尝试。这里有个策略问题热门门店中签率低但价值高冷门门店中签率高但可能不是你想要的产品。常见做法是配置多个备选脚本依次提交。配置项含义建议item_id商品标识以实际抓取为准不要手写猜测shop_id门店标识可配多个按优先级排列retry失败重试次数2 到 3 次太多会触发风控interval重试间隔秒数1 到 2 秒太短容易被限流配置完成后先手动触发一次看日志里返回的结果确认商品和门店都正确再交给定时任务。很多人跳过这一步结果跑了一周才发现门店 ID 填错了血泪经验。4. 避坑与排查跑不起来时先看这几条4.1 容器启动就退出现象docker ps看不到容器docker ps -a显示已退出。原因通常是配置文件缺失或格式错误脚本启动时读取失败直接退出。解决先docker logs看报错多半是配置文件路径不对或 JSON 格式有误。检查挂载目录里文件是否真的存在JSON 是否有多余逗号。4.2 日志显示未登录但凭证刚更新过现象明明刚填了新凭证日志还是报未登录。原因可能是凭证字段复制不全或者容器时间与服务器时间偏差过大导致签名校验失败。解决重新抓取完整请求头确认TZ设置正确用date命令在容器内核对时间。4.3 定时到了但没有任何请求发出现象日志显示等待中到了设定时间却没有申购记录。原因通常是容器内时区不对或者定时表达式写错。解决进容器执行date确认时间检查定时配置的时区基准。这是最隐蔽的坑因为脚本本身没报错。4.4 请求频繁被限流现象日志里出现大量失败提示请求过于频繁。原因重试间隔太短或重试次数太多。解决把interval调到 2 秒以上retry降到 2 次。自动预约不是并发越高越好稳定比激进更重要。4.5 换机器后跑不起来现象原来机器上正常迁移到新机器就失败。原因新机器没装 Docker或者 Docker 服务没启动或者镜像没拉全。解决先确认docker info能正常输出再确认镜像存在。Windows 用户注意Docker Desktop 需要 WSL2 支持如果提示 virtualization support not detected要去 BIOS 开启虚拟化。5. 让自动预约更稳的两个进阶技巧第一个技巧是加一层结果通知。脚本跑没跑成功你不看日志就不知道但每天手动看日志不现实。常见做法是接入一个通知渠道申购成功或凭证失效时推送一条消息。实现上就是在申购流程结束后判断返回码命中特定状态就发通知。这样你只需要在收到「凭证失效」时去更新一次其余时间不用管。def notify(msg): # 伪代码替换成你实际使用的通知方式 requests.post(WEBHOOK_URL, json{text: msg}) result do_reserve() if result[code] SUCCESS: notify(申购提交成功) elif result[code] AUTH_FAIL: notify(凭证失效请更新)第二个技巧是给容器加健康检查。Docker 支持HEALTHCHECK指令定期执行一个命令判断服务是否正常。如果脚本卡死健康检查失败后配合--restart策略可以自动重启。这比你自己盯着强。HEALTHCHECK --interval1h --timeout10s \ CMD python /app/healthcheck.py || exit 1参数上interval不用太短一小时一次足够因为预约本身一天就一次。timeout给 10 秒避免误判。最后说个我自己的习惯每次更新凭证后我会手动触发一次申购流程看日志确认返回正常再让它自己跑。这个动作花不了一分钟但能避免「以为在跑其实早就挂了」的情况。自动预约这件事稳定运行比功能花哨重要得多把凭证、时间、门店这三个参数管好基本就不会出大问题。希望帮到你。本文还有配套的精品资源点击获取