拓冰网站定制 
简介这是一套面向茅台抢购需求用户的i茅台自动预约工具基于Docker容器化部署适合具备基础运维或开发能力、希望免去每日手动操作的用户。项目采用前后端分离架构后端以Java实现预约逻辑与接口调用前端使用Vue配合JavaScript构建管理界面并通过yml、bat等脚本与配置文件支持一键启动整体结构清晰、便于二次修改。压缩包共542个文件涵盖209个java源码、87个vue组件、84个js脚本、22个xml配置及svg、png等静态资源另有sql、properties、md等辅助文件包体约2.99MB体积轻量。目前已有1484人学习下载。借助该资源读者可获得完整的自动预约项目源码、Docker部署配置与前后端目录结构便于快速搭建运行环境、理解预约流程实现思路并在此基础上进行功能调整与排错参考。1. 从手动抢购到 Docker 托管i茅台自动预约到底在做什么每天定闹钟蹲点 i茅台手指点得比抢红包还快结果申购按钮一灰一天又白搭。这个i茅台app自动预约每日自动预约支持docker一键部署.zip就是冲着这个场景来的——它把「打开 App、选门店、点申购」这套重复动作交给一个跑在容器里的定时任务去完成。你不需要 root 手机也不用装一堆来路不明的插件一台常年开机的 NAS、软路由或者云主机就能托管。适合谁手里有 Docker 环境、想省掉每日手动操作、又愿意花二十分钟把配置跑通的人。它不保证中签只保证「该点的都点了」把运气的事留给概率把执行的事交给脚本。2. 拆包看结构预约逻辑、配置项与 Docker 镜像怎么对上2.1 先搞清楚它凭什么能替你点申购i茅台 App 的申购接口本质上是带鉴权的 HTTP 请求核心参数就三样账号身份token 或登录态、门店编码shopId 或类似字段、申购商品 IDitemId。自动预约脚本干的事就是拿你的登录凭证按固定时间间隔向这几个接口发请求。常见做法是脚本里维护一份账号池和门店池到点遍历执行把结果写日志。这里有个关键认知脚本不是模拟点击屏幕而是直接调接口所以它比手动快但也意味着你的登录态一旦失效脚本会静默失败——这就是后面避坑章要重点说的。2.2 压缩包里的目录长什么样解压后一般能看到这几类文件不同打包者命名略有差异但结构大同小异路径/文件作用你要不要动docker-compose.yml定义容器、挂载卷、环境变量要改填账号和门店Dockerfile构建镜像的指令一般不动config/或.env账号、token、门店、时间配置必改app/或src/预约主逻辑代码看懂即可logs/运行日志挂载点排错时看requirements.txtPython 依赖清单不动提示如果压缩包里只有docker-compose.yml没有Dockerfile说明作者用的是现成镜像直接docker compose up拉取即可别自己瞎构建。2.3 用 docker compose 把服务拉起来假设你已经装好 Docker 和 Docker Compose进入解压目录先看 compose 文件里需要哪些环境变量# docker-compose.yml 关键片段按你包里的实际字段改 services: maotai: image: maotai-auto:latest # 或 build: . 本地构建 container_name: maotai-auto restart: unless-stopped # 开机自启崩了自动拉起 environment: - TZAsia/Shanghai # 时区必须对否则定时全乱 - ACCOUNT你的手机号 - TOKEN抓包拿到的登录态 - SHOP_ID目标门店编码 - ITEM_ID申购商品ID - RESERVE_TIME09:00:00 # 每日执行时刻 volumes: - ./logs:/app/logs # 日志落盘方便排查 - ./config:/app/config # 配置持久化字段说明TZ不设成上海时区容器按 UTC 跑你的 9 点会变成下午 5 点这是血泪经验restart: unless-stopped保证宿主机重启后容器自己回来TOKEN是最容易过期的一项后面单独讲。改完执行docker compose up -d # 后台启动 docker compose logs -f # 实时看日志确认有没有报鉴权失败如果日志里出现login expired或401别急着怀疑脚本先换 token。如果出现connection refused检查容器网络能不能出网docker exec -it maotai-auto ping api.moutai519.com.cn试一下。2.4 定时是怎么触发的两种常见实现一是容器内用cron或APScheduler按RESERVE_TIME触发二是脚本常驻内部sleep到点执行。前者依赖容器时区正确后者依赖进程不崩。你可以在 compose 里加command: python main.py --schedule这类参数切换模式。验证定时是否生效最直接的办法是把RESERVE_TIME临时改成两分钟后看日志有没有打出申购记录确认后再改回真实时间。这一步别省很多人配完就不管结果第二天发现根本没跑。3. 配置参数逐项调优账号、门店与执行时刻怎么设才不翻车3.1 登录态从哪来、怎么续这是整个项目最脆弱的环节。i茅台的登录态token 或 cookie有有效期短则几小时长则几天过期后所有预约请求都会被拒。常见做法有两种一是手动抓包用手机配合抓包工具拿到请求头里的鉴权字段填进配置二是脚本内置账号密码登录自动换取 token。前者稳定但需要你定期更新后者省事但依赖登录接口不变。我一般会先用手动 token 跑通流程确认脚本逻辑没问题再考虑自动登录。抓包时注意只取鉴权字段别把无关的隐私信息一起贴进配置文件。3.2 门店编码和商品 ID 怎么找门店编码不是门店名字是一串数字或字母 ID。获取方式在 i茅台 App 里选好门店抓包看申购请求里的shopId字段或者脚本作者通常会在config里附一份示例你照着格式填。商品 ID 同理不同申购活动对应不同itemId填错会提示「商品不存在」。建议第一次只配一个账号、一个门店、一个商品跑通后再加量。多账号场景下配置文件一般写成数组{ accounts: [ {phone: 138xxxx0001, token: token_a, shopId: 10001, itemId: 20001}, {phone: 138xxxx0002, token: token_b, shopId: 10002, itemId: 20001} ], reserveTime: 09:00:00, retry: 3 }retry是失败重试次数设 3 次比较稳妥太多容易被风控盯上。reserveTime建议比官方放号时间提前 5 到 10 秒给网络延迟留余量但别提前太多否则请求可能落在无效时间窗。3.3 时区、日志与资源限制容器默认 UTC前面强调过TZAsia/Shanghai。日志方面./logs挂载出来后用tail -f logs/app.log看执行流水重点看每次申购的返回码。资源限制可以在 compose 里加mem_limit: 256m和cpus: 0.5这类脚本很轻给太多反而浪费。如果你跑在 NAS 上注意 Docker 的存储路径别放在会休眠的硬盘上否则定时任务可能因为 IO 挂起而错过时间点。3.4 多账号并发与风控边界多账号同时请求同一门店容易触发频控。稳妥做法是给每个账号之间加随机延迟比如 1 到 3 秒配置里通常有interval或delay字段。别把所有账号的reserveTime设成同一秒错开几秒更安全。另外同一 IP 下账号数量不宜过多家庭宽带跑两三个账号问题不大几十个就属于异常流量了。这不是技术限制是使用边界越界了脚本再稳也没用。4. 避坑与排查token 失效、时区错乱、网络不通怎么定位4.1 日志显示 401 或 login expired现象容器正常运行但每次申购都返回鉴权失败。原因token 过期或抓包时复制的字段不完整比如漏了Bearer前缀。解决重新抓包更新 token检查配置里鉴权字段格式是否和请求头一致。如果脚本支持账号密码自动登录确认密码没改、账号没被限制登录。4.2 到点了但日志里没有任何申购记录现象RESERVE_TIME设的 9 点9 点过了日志还是空的。原因容器时区是 UTC实际执行时间偏移了 8 小时或者定时进程根本没启动。解决docker exec -it maotai-auto date看容器时间不是北京时间就补TZ环境变量再确认启动命令带没带调度参数docker compose logs看进程有没有报错退出。4.3 容器内请求超时或 connection refused现象日志里大量网络错误。原因容器 DNS 解析失败、宿主机防火墙拦截、或者目标接口临时不可达。解决进容器ping和curl目标域名确认出网正常检查宿主机iptables或安全组有没有限制如果是 NAS 环境确认 Docker 桥接网络没被隔离。这类问题跟脚本本身无关属于 Docker 网络配置范畴。4.4 多账号配置后只有第一个账号执行现象配置文件里写了三个账号日志只跑了一个。原因配置解析格式不对比如 JSON 数组写成了对象或者脚本只读了第一个元素。解决用python -m json.tool config.json校验格式对照脚本里读取配置的代码确认字段名。别凭感觉猜字段直接看源码里config[accounts]这类取值路径。4.5 更新镜像后配置丢失现象重新docker compose pull再启动账号配置没了。原因配置写在镜像内部而非挂载卷里。解决确认volumes把config目录挂出来了所有需要持久化的东西都必须落在宿主机目录。这是 Docker 使用的基本功但翻车的人真不少。5. 进阶把预约结果推到手机并做一次完整的验证闭环跑通基础预约只是第一步真正省心的是「跑完能告诉你结果」。常见做法是在脚本执行完后加一个通知钩子支持 Server 酱、Bark、钉钉机器人等。以 Bark 为例在配置里加一个notify_url脚本申购结束后把结果拼成文本推过去import requests def push_result(notify_url, success_list, fail_list): # 申购结束后调用把成功和失败分开推送 text f成功: {len(success_list)} 失败: {len(fail_list)} requests.get(f{notify_url}/{text}) # Bark 的 URL 格式按你用的服务改这段逻辑不复杂关键是调用时机——放在所有账号遍历完之后别每个账号推一次否则手机响个不停。参数上notify_url从环境变量读别硬编码在代码里方便换服务。验证闭环怎么做我一般分三步第一步把RESERVE_TIME改成两分钟后观察日志和通知是否都到位第二步故意填一个错误 token确认失败路径也能推送告警而不是静默死掉第三步重启宿主机确认容器自启、定时任务恢复。这三步走完才算真正托管成功。从那以后我每次部署这类定时脚本都强制走一遍「改时间—看日志—重启验证」的流程再也没出现过「以为在跑其实早挂了」的情况。希望帮到你。本文还有配套的精品资源点击获取 Docker一键部署i茅台自动预约：配置、避坑与通知闭环
简介这是一套面向茅台抢购需求用户的i茅台自动预约工具基于Docker容器化部署适合具备基础运维或开发能力、希望免去每日手动操作的用户。项目采用前后端分离架构后端以Java实现预约逻辑与接口调用前端使用Vue配合JavaScript构建管理界面并通过yml、bat等脚本与配置文件支持一键启动整体结构清晰、便于二次修改。压缩包共542个文件涵盖209个java源码、87个vue组件、84个js脚本、22个xml配置及svg、png等静态资源另有sql、properties、md等辅助文件包体约2.99MB体积轻量。目前已有1484人学习下载。借助该资源读者可获得完整的自动预约项目源码、Docker部署配置与前后端目录结构便于快速搭建运行环境、理解预约流程实现思路并在此基础上进行功能调整与排错参考。1. 从手动抢购到 Docker 托管i茅台自动预约到底在做什么每天定闹钟蹲点 i茅台手指点得比抢红包还快结果申购按钮一灰一天又白搭。这个i茅台app自动预约每日自动预约支持docker一键部署.zip就是冲着这个场景来的——它把「打开 App、选门店、点申购」这套重复动作交给一个跑在容器里的定时任务去完成。你不需要 root 手机也不用装一堆来路不明的插件一台常年开机的 NAS、软路由或者云主机就能托管。适合谁手里有 Docker 环境、想省掉每日手动操作、又愿意花二十分钟把配置跑通的人。它不保证中签只保证「该点的都点了」把运气的事留给概率把执行的事交给脚本。2. 拆包看结构预约逻辑、配置项与 Docker 镜像怎么对上2.1 先搞清楚它凭什么能替你点申购i茅台 App 的申购接口本质上是带鉴权的 HTTP 请求核心参数就三样账号身份token 或登录态、门店编码shopId 或类似字段、申购商品 IDitemId。自动预约脚本干的事就是拿你的登录凭证按固定时间间隔向这几个接口发请求。常见做法是脚本里维护一份账号池和门店池到点遍历执行把结果写日志。这里有个关键认知脚本不是模拟点击屏幕而是直接调接口所以它比手动快但也意味着你的登录态一旦失效脚本会静默失败——这就是后面避坑章要重点说的。2.2 压缩包里的目录长什么样解压后一般能看到这几类文件不同打包者命名略有差异但结构大同小异路径/文件作用你要不要动docker-compose.yml定义容器、挂载卷、环境变量要改填账号和门店Dockerfile构建镜像的指令一般不动config/或.env账号、token、门店、时间配置必改app/或src/预约主逻辑代码看懂即可logs/运行日志挂载点排错时看requirements.txtPython 依赖清单不动提示如果压缩包里只有docker-compose.yml没有Dockerfile说明作者用的是现成镜像直接docker compose up拉取即可别自己瞎构建。2.3 用 docker compose 把服务拉起来假设你已经装好 Docker 和 Docker Compose进入解压目录先看 compose 文件里需要哪些环境变量# docker-compose.yml 关键片段按你包里的实际字段改 services: maotai: image: maotai-auto:latest # 或 build: . 本地构建 container_name: maotai-auto restart: unless-stopped # 开机自启崩了自动拉起 environment: - TZAsia/Shanghai # 时区必须对否则定时全乱 - ACCOUNT你的手机号 - TOKEN抓包拿到的登录态 - SHOP_ID目标门店编码 - ITEM_ID申购商品ID - RESERVE_TIME09:00:00 # 每日执行时刻 volumes: - ./logs:/app/logs # 日志落盘方便排查 - ./config:/app/config # 配置持久化字段说明TZ不设成上海时区容器按 UTC 跑你的 9 点会变成下午 5 点这是血泪经验restart: unless-stopped保证宿主机重启后容器自己回来TOKEN是最容易过期的一项后面单独讲。改完执行docker compose up -d # 后台启动 docker compose logs -f # 实时看日志确认有没有报鉴权失败如果日志里出现login expired或401别急着怀疑脚本先换 token。如果出现connection refused检查容器网络能不能出网docker exec -it maotai-auto ping api.moutai519.com.cn试一下。2.4 定时是怎么触发的两种常见实现一是容器内用cron或APScheduler按RESERVE_TIME触发二是脚本常驻内部sleep到点执行。前者依赖容器时区正确后者依赖进程不崩。你可以在 compose 里加command: python main.py --schedule这类参数切换模式。验证定时是否生效最直接的办法是把RESERVE_TIME临时改成两分钟后看日志有没有打出申购记录确认后再改回真实时间。这一步别省很多人配完就不管结果第二天发现根本没跑。3. 配置参数逐项调优账号、门店与执行时刻怎么设才不翻车3.1 登录态从哪来、怎么续这是整个项目最脆弱的环节。i茅台的登录态token 或 cookie有有效期短则几小时长则几天过期后所有预约请求都会被拒。常见做法有两种一是手动抓包用手机配合抓包工具拿到请求头里的鉴权字段填进配置二是脚本内置账号密码登录自动换取 token。前者稳定但需要你定期更新后者省事但依赖登录接口不变。我一般会先用手动 token 跑通流程确认脚本逻辑没问题再考虑自动登录。抓包时注意只取鉴权字段别把无关的隐私信息一起贴进配置文件。3.2 门店编码和商品 ID 怎么找门店编码不是门店名字是一串数字或字母 ID。获取方式在 i茅台 App 里选好门店抓包看申购请求里的shopId字段或者脚本作者通常会在config里附一份示例你照着格式填。商品 ID 同理不同申购活动对应不同itemId填错会提示「商品不存在」。建议第一次只配一个账号、一个门店、一个商品跑通后再加量。多账号场景下配置文件一般写成数组{ accounts: [ {phone: 138xxxx0001, token: token_a, shopId: 10001, itemId: 20001}, {phone: 138xxxx0002, token: token_b, shopId: 10002, itemId: 20001} ], reserveTime: 09:00:00, retry: 3 }retry是失败重试次数设 3 次比较稳妥太多容易被风控盯上。reserveTime建议比官方放号时间提前 5 到 10 秒给网络延迟留余量但别提前太多否则请求可能落在无效时间窗。3.3 时区、日志与资源限制容器默认 UTC前面强调过TZAsia/Shanghai。日志方面./logs挂载出来后用tail -f logs/app.log看执行流水重点看每次申购的返回码。资源限制可以在 compose 里加mem_limit: 256m和cpus: 0.5这类脚本很轻给太多反而浪费。如果你跑在 NAS 上注意 Docker 的存储路径别放在会休眠的硬盘上否则定时任务可能因为 IO 挂起而错过时间点。3.4 多账号并发与风控边界多账号同时请求同一门店容易触发频控。稳妥做法是给每个账号之间加随机延迟比如 1 到 3 秒配置里通常有interval或delay字段。别把所有账号的reserveTime设成同一秒错开几秒更安全。另外同一 IP 下账号数量不宜过多家庭宽带跑两三个账号问题不大几十个就属于异常流量了。这不是技术限制是使用边界越界了脚本再稳也没用。4. 避坑与排查token 失效、时区错乱、网络不通怎么定位4.1 日志显示 401 或 login expired现象容器正常运行但每次申购都返回鉴权失败。原因token 过期或抓包时复制的字段不完整比如漏了Bearer前缀。解决重新抓包更新 token检查配置里鉴权字段格式是否和请求头一致。如果脚本支持账号密码自动登录确认密码没改、账号没被限制登录。4.2 到点了但日志里没有任何申购记录现象RESERVE_TIME设的 9 点9 点过了日志还是空的。原因容器时区是 UTC实际执行时间偏移了 8 小时或者定时进程根本没启动。解决docker exec -it maotai-auto date看容器时间不是北京时间就补TZ环境变量再确认启动命令带没带调度参数docker compose logs看进程有没有报错退出。4.3 容器内请求超时或 connection refused现象日志里大量网络错误。原因容器 DNS 解析失败、宿主机防火墙拦截、或者目标接口临时不可达。解决进容器ping和curl目标域名确认出网正常检查宿主机iptables或安全组有没有限制如果是 NAS 环境确认 Docker 桥接网络没被隔离。这类问题跟脚本本身无关属于 Docker 网络配置范畴。4.4 多账号配置后只有第一个账号执行现象配置文件里写了三个账号日志只跑了一个。原因配置解析格式不对比如 JSON 数组写成了对象或者脚本只读了第一个元素。解决用python -m json.tool config.json校验格式对照脚本里读取配置的代码确认字段名。别凭感觉猜字段直接看源码里config[accounts]这类取值路径。4.5 更新镜像后配置丢失现象重新docker compose pull再启动账号配置没了。原因配置写在镜像内部而非挂载卷里。解决确认volumes把config目录挂出来了所有需要持久化的东西都必须落在宿主机目录。这是 Docker 使用的基本功但翻车的人真不少。5. 进阶把预约结果推到手机并做一次完整的验证闭环跑通基础预约只是第一步真正省心的是「跑完能告诉你结果」。常见做法是在脚本执行完后加一个通知钩子支持 Server 酱、Bark、钉钉机器人等。以 Bark 为例在配置里加一个notify_url脚本申购结束后把结果拼成文本推过去import requests def push_result(notify_url, success_list, fail_list): # 申购结束后调用把成功和失败分开推送 text f成功: {len(success_list)} 失败: {len(fail_list)} requests.get(f{notify_url}/{text}) # Bark 的 URL 格式按你用的服务改这段逻辑不复杂关键是调用时机——放在所有账号遍历完之后别每个账号推一次否则手机响个不停。参数上notify_url从环境变量读别硬编码在代码里方便换服务。验证闭环怎么做我一般分三步第一步把RESERVE_TIME改成两分钟后观察日志和通知是否都到位第二步故意填一个错误 token确认失败路径也能推送告警而不是静默死掉第三步重启宿主机确认容器自启、定时任务恢复。这三步走完才算真正托管成功。从那以后我每次部署这类定时脚本都强制走一遍「改时间—看日志—重启验证」的流程再也没出现过「以为在跑其实早挂了」的情况。希望帮到你。本文还有配套的精品资源点击获取