简介这是一套面向茅台抢购场景的i茅台App自动预约工具适合具备一定技术基础、希望免去每日手动操作的用户。项目以Java后端与Vue前端构建通过Docker一键部署即可在支持容器化的平台上快速运行实现每日定时自动完成预约流程降低人工值守成本。压缩包共542个文件约2.99MB以209个java源码、87个vue组件、84个js脚本为主体辅以22个xml配置、9个scss样式及yml、bat、sql等部署与数据库文件前后端结构完整便于二次开发与本地调试。目前已有1484人学习下载。借助该资源读者可获得一套可直接部署的自动化预约方案理解接口调用、定时任务与容器化编排的实现思路并参考其目录组织快速定位配置与启动脚本适合作为Docker实战与自动化脚本学习的参考案例。1. i茅台自动预约这件事真正难的不是抢是每天记得打开i茅台 App 的申购机制本质上是「每日固定时段、固定门店、固定规格拼手速也拼坚持」。很多人第一次申购没中第二天忘了第三天想起来已经过了时段一个月下来实际参与次数不到十次。自动预约要解决的核心问题不是「破解」或「加速」而是把「每天按时提交申购」这件事从人的记忆里剥离出来交给一个常驻服务去执行。这个方案适合三类人一是每天忙到记不住时段的上班族二是手里有几台闲置设备、想用 Docker 统一管理定时任务的人三是想学容器化部署、拿一个真实小项目练手的运维新手。它不承诺中签率只保证「不漏约」。下面从 Docker 环境准备讲到容器编排、参数配置和踩坑排查全部按可复现的路径写。2. 用 Docker 跑定时预约环境、镜像与最小启动命令2.1 为什么选 Docker 而不是直接装 Python 脚本直接在本机跑 Python 脚本第一个问题是环境依赖不同系统上requests、schedule、selenium的版本冲突能折腾一下午。第二个问题是常驻脚本挂在终端里关掉窗口就断用nohup或系统计划任务迁移到另一台机器又要重配一遍。Docker 把 Python 运行时、依赖库和启动脚本一起封进镜像换机器只需要docker compose up -d这是「一键部署」真正的价值。另一个现实原因是权限隔离。预约脚本需要保存账号凭证和本地日志直接跑在宿主机上文件散落在用户目录里时间一长自己都找不到。容器用 volume 把配置和日志映射到固定目录删容器不丢数据重建容器直接复用。提示本文只讨论定时提交申购请求的工程实现不涉及任何绕过平台风控或篡改请求的手段。脚本行为应控制在正常用户操作范围内。2.2 安装 Docker 与 Docker Compose 的最小步骤Ubuntu 环境下官方推荐用 apt 仓库安装不要用系统自带的旧版本。下面这套命令在 Ubuntu 20.04/22.04 上验证过# 卸载可能存在的旧版本 sudo apt remove docker docker-engine docker.io containerd runc # 安装依赖 sudo apt update sudo apt install -y ca-certificates curl gnupg lsb-release # 添加 Docker 官方 GPG key sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \ sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 添加稳定版仓库 echo deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] \ https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable | \ sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 安装 Docker Engine 和 Compose 插件 sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin # 把当前用户加入 docker 组避免每次 sudo sudo usermod -aG docker $USER newgrp docker逻辑说明前两步清理旧版本和装依赖第三步导入官方签名密钥第四步写入仓库地址第五步安装引擎和 Compose 插件。最后把用户加入docker组是为了后续执行docker ps不用加sudo。参数上$(lsb_release -cs)会自动取当前系统代号比如jammy不用手改。Windows 11 用户走 Docker Desktop 路线安装包从官网下载后一路下一步注意安装时勾选 WSL2 后端。装完在 PowerShell 里执行docker version能看到 Client 和 Server 两段信息才算成功。如果报virtualization support not detected去 BIOS 里开虚拟化再在「启用或关闭 Windows 功能」里勾上「虚拟机平台」和「适用于 Linux 的 Windows 子系统」。2.3 拉取镜像与最小启动命令镜像来源通常有两种作者发布的公开镜像或者自己用 Dockerfile 构建。假设已经拿到镜像名最小启动命令如下# 创建配置和日志目录 mkdir -p /opt/imt/config /opt/imt/logs # 启动容器映射配置目录和日志目录 docker run -d \ --name imt-reserve \ --restart unless-stopped \ -v /opt/imt/config:/app/config \ -v /opt/imt/logs:/app/logs \ -e TZAsia/Shanghai \ imt-reserve:latest逻辑说明-d后台运行--restart unless-stopped保证宿主机重启后容器自动拉起这是「每日自动」的前提。两个-v把容器内的配置和日志目录挂到宿主机改配置不用进容器看日志直接tail。-e TZAsia/Shanghai很关键容器默认 UTC 时间不设时区预约时段会整体偏移 8 小时这是最常见的翻车点之一。参数上/app/config和/app/logs是镜像内约定的路径不同镜像可能不同启动前用docker inspect 镜像名看WorkingDir和Entrypoint确认。如果镜像要求用环境变量传账号把-e参数补上即可但更推荐写进配置文件避免docker inspect泄露凭证。3. 用 docker compose 编排配置文件、时段参数与多账号管理3.1 compose 文件怎么写才方便日常维护单容器用docker run够用但一旦要加定时触发、日志轮转或者多账号compose 的可读性优势就出来了。下面是一份可直接改的docker-compose.ymlversion: 3.8 services: imt-reserve: image: imt-reserve:latest container_name: imt-reserve restart: unless-stopped environment: - TZAsia/Shanghai - RUN_AT09:00 - RETRY3 volumes: - ./config:/app/config - ./logs:/app/logs logging: driver: json-file options: max-size: 10m max-file: 3逻辑说明RUN_AT控制每天触发时间RETRY控制失败重试次数这两个参数是「每日自动预约」的核心。logging段限制日志文件大小避免跑几个月把磁盘写满。restart: unless-stopped和单容器命令里的含义一致。参数上RUN_AT建议设在申购时段开始前 1 到 2 分钟给网络请求留出缓冲。RETRY不要设太大3 次足够设 10 次反而可能触发平台频控。改完配置执行docker compose up -d重建容器docker compose logs -f实时看输出。3.2 账号配置文件的字段与安全处理配置文件一般是 JSON 或 YAML字段通常包括账号、密码或 token、门店编码、商品规格。以 JSON 为例{ accounts: [ { mobile: 13800000000, token: 从抓包或登录接口获取的凭证, shop_id: 门店编码, item_id: 商品规格编码, enabled: true } ], schedule: { time: 09:00, jitter: 30 } }逻辑说明accounts数组支持多账号每个账号独立控制enabled临时停用某个号不用删配置。jitter是随机延迟秒数让每次请求时间有轻微浮动避免每天精确到同一秒提交这是降低被判定为机器行为概率的常见做法。参数上shop_id和item_id需要自己从 App 里确认不同城市、不同门店编码不同填错会提示「门店不存在」或「商品不可申购」。token有过期时间一般几天到几周过期后日志会报 401需要重新获取。配置文件权限建议设成600chmod 600 config/account.json别用默认的 644。注意不要把配置文件提交到公开仓库。如果用了 Git 管理把config/加进.gitignore。3.3 定时触发的两种实现方式与选择第一种是容器内用schedule库或cron常驻容器启动后自己等到设定时间执行。第二种是宿主机用cron定时docker exec进容器触发一次。两种都能用区别在维护成本。容器内常驻的好处是自包含迁移时不用改宿主机 crontab坏处是容器时区、休眠恢复后的时间跳变要自己处理。宿主机 cron 的好处是时间由系统保证容器只负责执行坏处是每台机器都要配一遍 crontab。我一般选容器内常驻配合TZ环境变量和restart: unless-stopped宿主机重启后容器自动恢复定时逻辑不受影响。如果选宿主机 cron写法是# 编辑 crontab crontab -e # 每天 8:58 触发容器内脚本 58 8 * * * docker exec imt-reserve python /app/main.py /opt/imt/logs/cron.log 21逻辑说明58 8 * * *表示每天 8 点 58 分执行提前 2 分钟给容器调度留余量。把输出追加到日志21把错误输出也重定向进去否则报错信息会丢。参数上时间字段依次是分、时、日、月、周别写反。4. 避坑与排查时区、权限、网络和凭证过期4.1 预约时间对不上总是晚 8 小时现象配置里写 09:00日志显示实际执行时间是 17:00 或 01:00。原因容器默认使用 UTC 时区脚本按 UTC 解析RUN_AT而你在东八区。解决启动参数加-e TZAsia/Shanghaicompose 文件里在environment段补上。改完docker compose up -d重建进容器执行date确认输出是 CST 时间。4.2 permission denied while trying to connect to the Docker API现象执行docker ps报permission denied while trying to connect to the Docker API at unix:///var/run/docker.sock。原因当前用户不在docker组里没有权限访问 Docker 守护进程的 socket。解决sudo usermod -aG docker $USER然后newgrp docker或重新登录。如果还不行检查/var/run/docker.sock的属组是不是docker用ls -l看。别图省事直接chmod 777那等于把 Docker 控制权开放给所有用户。4.3 容器起来了但日志没有任何输出现象docker ps显示容器 Updocker logs空的预约没执行。原因常见有三种——脚本在等定时时间还没到触发点配置文件路径映射错了容器读不到账号镜像的Entrypoint不是常驻进程执行完就退出但被restart反复拉起。解决先docker exec -it imt-reserve sh进容器ls /app/config看配置在不在。再看docker inspect imt-reserve | grep -A5 Entrypoint确认启动命令。如果是配置路径问题改 volume 映射如果是 Entrypoint 问题换镜像或自己写 Dockerfile 覆盖。4.4 token 过期导致每天静默失败现象前几天正常某天开始日志报 401 或「登录失效」但容器状态正常不主动看日志发现不了。原因凭证有有效期过期后请求被拒脚本如果没做失败告警就变成「看起来在跑实际没约」。解决在脚本里加失败重试和日志标记每天执行完 grep 一下日志里有没有success关键字。更稳妥的做法是配一个简单的告警比如失败时往某个 webhook 发消息。凭证更新后重启容器即可不用重建镜像。4.5 多账号同时提交触发频控现象配了 3 个账号同一秒提交部分账号返回「操作频繁」或直接失败。原因请求时间过于集中被平台判定为异常流量。解决配置文件里的jitter调大比如 30 到 60 秒让每个账号的提交时间错开。或者在脚本里对账号列表做顺序执行每个之间sleep几秒。别用多线程同时打省那几秒不值得。5. 进阶把「不漏约」做成可观测的日常服务跑到稳定之后真正要解决的不是「能不能约」而是「怎么知道它今天约了、约的结果是什么」。我自己的习惯是在日志目录上再加一层轻量监控每天固定时间用一条命令汇总当天结果输出成一行摘要方便一眼扫过去。# 汇总当天预约结果输出成功/失败账号数 grep $(date %Y-%m-%d) /opt/imt/logs/app.log | \ awk /success/ {s} /failed/ {f} END {print success:s failed:f}逻辑说明先按日期过滤当天日志再用awk统计success和failed出现次数。参数上date %Y-%m-%d要和日志里的日期格式一致不一致就改成匹配格式。这条命令可以挂到 crontab 里每天跑一次输出重定向到一个摘要文件。再进一步可以把摘要写进一个简单的 HTML 页面用nginx容器挂出来手机浏览器随时看。但别过度工程化一个 grep 加一个文件已经能解决 90% 的「不知道跑没跑」焦虑。几个我踩过的坑值得单独说。第一别把restart设成always就不管了容器反复重启但脚本本身报错日志会被刷得看不清unless-stopped更合适。第二宿主机磁盘满会导致容器写日志失败进而脚本异常定期df -h看一眼。第三Docker 镜像更新后配置格式可能变升级前先备份config目录这是唯一的后悔药。第四别在容器里存明文密码能用 token 就用 tokentoken 也比密码好轮换。最后说一个验证方法手动把RUN_AT改成当前时间加 2 分钟重启容器盯着docker logs -f看完整执行流程。跑通一次再改回正式时段。这个动作我每次换机器部署都会做一遍比任何文档都可靠。希望帮到你。本文还有配套的精品资源点击获取