4步部署i茅台自动预约系统campus-imaotai：新手友好的实操指南
【免费下载链接】campus-imaotaii茅台app自动预约，每日自动预约，支持docker一键部署（本项目不提供成品，使用的是已淘汰的算法）项目地址: https://gitcode.com/GitHub_Trending/ca/campus-imaotai
每天9点整，你在i茅台APP里点第十次"申购"，弹出的还是"该门店无货"。抢茅台这件事，拼的是手速和运气。campus-imaotai 是一个做 i茅台自动预约 的开源项目：登录、选门店、提交申购全部交给程序完成，Docker 一键部署后，服务器每天替你完成9点档的预约。
📌 项目速览：campus-imaotai 是什么、适合谁
它基于 Java 生态编写：后端是 Spring Boot + MyBatis-Plus + Redis（构建在 Campus 框架上），前端是 Vue2 + Element-UI，数据库 MySQL，整个系统由管理后台（campus-admin / campus-framework 模块）和业务核心（campus-modular 模块）组成，前端在 vue_campus_admin 目录。
先说清楚适合谁：有服务器（或能开 Docker 的机器）、会用命令行、想完整跑一遍"定时任务 + 接口自动化 + Web 管理后台"这套流程的人。同时要注意项目自带的两句声明——项目描述写明"本项目不提供成品，使用的是已淘汰的算法"，README 的声明部分限定内容仅供学习研究。它更适合作为工程样板，而不是拿来直接盈利的工具。
| 对比角度 | 手动操作APP | campus-imaotai 自动化 |
|---|---|---|
| 时间投入 | 每天9点守着APP手动点 | 09:00–09:59 按分钟自动触发，服务器挂机运行 |
| 多账号 | 一部手机只能操作一个账号 | 多账号表格化管理，每个账号可独立设置门店策略与时间 |
| 过程追溯 | 无记录 | 每次执行写入 i_log 日志，可配 PushPlus 推送结果 |
图：管理后台通过"手机号 + 验证码"把 i茅台 账号纳入系统管理
🚀 部署实战：从零到跑通的4步流程
第1步：克隆仓库
先获取源码（仓库为只读，后续所有操作都在本地进行）：
git clone https://gitcode.com/GitHub_Trending/ca/campus-imaotai验证方式：进入目录执行ls，能看到campus-modular、vue_campus_admin、doc三个关键目录即成功。
第2步：启动服务容器
compose 文件里定义了 MySQL（5.7）、Redis（6.2）、Nginx、后端服务四个容器，全部使用 host 网络模式。执行启动命令：
cd campus-imaotai/doc/docker docker-compose up -d验证方式：docker ps应看到mysql、redis、nginx-web、campus-imaotai四个容器处于 Up 状态。
第3步：初始化数据库
compose 中 root 密码为123456789，建好的空库名为campus_imaotai。把初始化脚本导入该库（脚本路径见 doc/sql/campus_imaotai-1.0.5.sql）：
cd campus-imaotai docker exec -i mysql mysql -uroot -p123456789 campus_imaotai < doc/sql/campus_imaotai-1.0.5.sql验证方式：执行docker exec mysql mysql -uroot -p123456789 -e "use campus_imaotai; show tables;"，出现i_user、i_shop、i_log、sys_user等 16 张表即成功。此时重启一次后端容器让它连上新库结构：docker restart campus-imaotai。
第4步：构建前端并登录后台
compose 里 Nginx 只挂载了空目录/docker/nginx/html，前端需要自己打包后放进去（vue_campus_admin/Dockerfile 也印证了 dist 就是最终页面）。安装依赖并执行生产构建：
cd campus-imaotai/vue_campus_admin npm install && npm run build:prod把产物拷入 Nginx 挂载目录，页面即可访问：
cp -r dist/* /docker/nginx/html/验证方式：浏览器打开http://localhost（Nginx 监听宿主机 80 端口，/prod-api请求代理到 8160 后端，见 nginx.conf），用 SQL 初始数据自带的账号admin/admin123登录，能看到"i茅台"菜单即部署完成。
🧩 功能讲解：最常用到的4个功能
1. 验证码纳管 i茅台 账号
能做什么：i茅台 账号以手机号为主键存在i_user表，登录成功后 token、cookie、设备ID 一并落库，有效期 30 天；支持任意多个账号。
怎么用：后台"用户管理"页点"添加账号"，输入手机号 → 发送验证码 → 回填验证码点"登录"，账号即入库。之后为每个账号设置预约项目 code（多个商品用@分隔）、门店、省市经纬度和分钟数。
代码在哪：接口入口 IUserController.java；验证码与登录的签名逻辑（MD5 签名、MT-Device-ID请求头）在 IMTServiceImpl.java 的sendCode/login方法。
图：用户管理列表，展示账号的省份、城市、经纬度、门店类型与到期时间
2. 双门店策略：出货量最大或距离最近
能做什么：预约前自动挑选门店。shopType=1选本市出货量（库存）最大的门店，本市无门店时自动回退为本省最近的；shopType=2直接用经纬度算距离选最近的。
怎么用：新增/修改用户表单里选"类型"即可；"门店列表"页能看当天全省投放的门店和地址，页面上的"刷新茅台门店列表"按钮触发重新拉取，门店数据在 Redis 中缓存 2 小时。
代码在哪：IShopServiceImpl.java 的getShopId（策略分发）、getMaxInventoryShopId（按库存倒序）、getMinDistanceShopId（WGS84 半径 6378137.0m 球面距离公式）。
图：门店列表页，展示商品ID、省市、经纬度、门店名称等预约决策依据
3. 定时任务驱动的预约：分钟级可控
能做什么：预约不是"9点整一击"，而是 09:00–09:59 每分钟触发一次，每轮只捞出minute等于当前分钟的用户依次执行，用户间隔 3 秒、多商品之间再随机延迟 3–5 秒。除此之外还有一张固定的时间表：01:10 批量刷新随机预约分钟；07:10 / 07:55 / 08:10 / 08:55 刷新 App 版本号、商品和门店数据；11:00–11:59 每分钟批量领取旅行奖励；18:05 查询当日申购结果并记日志。
怎么用：加用户时设置minute（1–59，越界自动回默认 5）和"随机分钟"开关；想不等 9 点先验证流程，用用户管理行内的"预约"按钮手动触发一次。
代码在哪：cron 配置集中在 CampusIMTTask.java，预约主流程在 IMTServiceImpl 的reservationBatch/reservation（预约参数经 AES/CBC 加密为actParam后提交）。
4. 日志与推送：每次尝试都有据可查
能做什么：每次预约、旅行、领耐力值都写入i_log（时间、手机号、返回内容、成功/失败），后台"操作日志"页可按状态和时间检索；用户若填了 PushPlus token，成功或失败都会异步推送到你手机。
怎么用：给用户填pushPlusToken字段；事后在操作日志页点"详情"看接口原始返回，排障主要靠它。
代码在哪：推送在 PushPlusApi.java，日志落库与推送触发在 IMTLogFactory.java。
图：操作日志页，展示每次 i茅台预约 的执行时间、状态与返回详情
⚙️ 进阶技巧：4条来自代码的实战细节
问题：多个账号同一分钟触发，请求过于集中做法：给不同账号设置不同的minute值错峰；或把"随机分钟"设为随机（0=随机，1=固定），系统每天 01:10 会执行updateUserMinuteBatch自动为这类用户重新分配随机分钟，来源见 CampusIMTTask 的注释。
问题：想在 9 点前验证某个账号能否预约成功做法：不要等定时任务，直接用用户管理行内"预约"按钮（对应/imt/user/reservation接口）立刻走一遍完整流程——选门店、加密、提交、写日志，失败原因会直接落到操作日志。
问题：旅行奖励领取失败，日志提示"耐力不足100"或"旅行暂未结束"做法：travelReward有前置校验——活动窗口 9:00–20:00、新开一次旅行要求耐力值 ≥100、上一趟旅行未结束不能重开。系统批量执行安排在 11:00–11:59，手动触发时避开窗口外时间和未结束的旅行。
问题：服务器不在东八区，预约总是差几个小时做法：定时任务按服务器本地时间触发（容器设置了TZ: Asia/Shanghai，但 cron 最终以宿主机时区为准）。部署在非东八区机器时，要么把系统时区调成东八区，要么按差值改 CampusIMTTask 里的 cron 表达式；需要覆盖数据库连接等配置时，在/docker/server/conf放application-prod.yml（参考 doc/docker/server/conf/README.md）。
❓ 常见问题：部署和使用时真实会碰到的4个问题
Q1：为什么部署后 80/3306/6379/8160 端口全被占用？A：docker-compose.yml 中四个服务都配置了network_mode: host，直接监听宿主机端口：MySQL 3306、Redis 6379、Nginx 80、后端 8160。宿主机若已跑 MySQL 或 Nginx，需先停掉或修改 compose；页面入口是 80 端口的 Nginx，后端 API 端口 8160 不用于直接访问。
Q2：日志出现"申购时根据类型获取的门店商品id为空"是什么意思？A：这是getShopId抛出的异常，含义是当天该商品在你账号对应的省市范围内，按所选策略挑不到任何有库存的门店。先到门店列表页确认当天投放情况，或把该账号的门店类型从"本市出货量最大"切换为"位置附近门店"。
Q3：账号是不是要用 30 天就重新输一次验证码？A：是。登录成功后 token/cookie 存进i_user，expireTime按登录当天 +30 天计算（见 IUser 实体构造逻辑）。到期后预约请求会失败，需要回用户管理页重新走"发送验证码 + 登录"流程。
Q4：i茅台 换了接口，这套系统还能用吗？A：要按不可用的预期去准备。项目描述明确写了"使用的是已淘汰的算法"，所有接口地址、AES 密钥（AES_KEY/AES_IV）、MD5 签名规则都集中在 IMTServiceImpl 一个文件里——官方接口变动时，这里就是唯一需要跟进修改的位置，也决定了这类工具的生命周期普遍较短。
🎯 总结
campus-imaotai 是一个结构清晰的"定时任务 + 接口自动化 + Web 管理后台"完整样例：一份 SQL 脚本、一份 compose 文件，就能把 i茅台 自动预约的链路跑起来，代码集中在 campus-modular 的业务包内，读起来不费劲。动手之前记住两点：项目自述算法已淘汰、内容仅供学习研究，实际可用性取决于 i茅台 当前接口状态。想开始的话，克隆仓库，按"部署实战"四步执行，再在用户管理页添加第一个账号即可。
【免费下载链接】campus-imaotaii茅台app自动预约，每日自动预约，支持docker一键部署（本项目不提供成品，使用的是已淘汰的算法）项目地址: https://gitcode.com/GitHub_Trending/ca/campus-imaotai
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
)
