Agent Skills实战：五个高复用技能封装与自定义教程
2026/10/18 16:53:46
campus-imaotai：i茅台自动预约如何做到无人值守，docker一键部署
【免费下载链接】campus-imaotaii茅台app自动预约，每日自动预约，支持docker一键部署（本项目不提供成品，使用的是已淘汰的算法）项目地址: https://gitcode.com/GitHub_Trending/ca/campus-imaotai
campus-imaotai 是一个基于 Java Spring Boot + Vue 的开源i茅台自动预约项目：在 Web 管理后台托管多个 i茅台账号，每天自动选店、自动提交预约请求，并把申购结果推送到你的手机；整套环境用一份 4 容器的 docker-compose 拉起，开机即可跑。
⚠️先说清边界：项目 README 明确写着"本项目不提供成品，使用的是已淘汰的算法"，免责声明要求使用者"24 小时内完成学习和研究，并及时删除本项目中的所有内容"。本文仅作技术学习角度解读，不建议直接用于生产，是否部署、合规风险请自行评估。
i茅台自动预约的一天：5 个定时任务的时间轴
整个项目的核心骨架，就是一个 CampusIMTTask.java 类里挂着的 5 个 Spring@Scheduled任务，把一次预约从"前一天凌晨"到"当天傍晚"该做的事全部排进了时刻表：
| 时刻 | cron | 任务方法 | 做了什么 |
|---|---|---|---|
| 每天 01:10 | 0 10 1 ? * * | updateUserMinuteBatch | 为每个账号重抽"预约分钟（1–59）"；账号超过 60 个时改用均匀分布策略，避免大家挤在同一分钟 |
| 07:10 / 07:55 / 08:10 / 08:55 | 0 10,55 7,8 ? * * | refreshAll | 刷新 i茅台 App 版本号、当日可预约商品、门店列表 |
| 9 点整每分钟 | 0 0/1 9 ? * * | reservationBatch | 捞出"预约分钟"等于当前分钟的账号，逐个发起预约请求 |
| 11 点整每分钟 | 0 0/1 11 ? * * | getTravelRewardBatch | 执行"小茅运"旅行任务：领耐力、首次分享、开启新一轮旅行 |
| 每天 18:05 | 0 5 18 ? * * | appointmentResults | 查询当日申购结果，成功的写日志并推送 |
这里有个值得一提的设计细节：并不是所有账号在 9 点整同时打出去，而是每个账号预先分配了独立的"预约分钟"，分钟级任务只执行分钟匹配的账号，账号之间还固定间隔 3 秒。表面上像分散请求，实现上只是一张i_user表 + 分钟级 cron，非常轻量。另外IMTServiceImpl在应用启动时（@PostConstruct）会先跑一次refreshAll()，保证容器重启后数据也是新的一天。
门店自动选择策略：预约前先替你挑店
申购必须指定门店。IShopServiceImpl.java 提供了两种策略，由账号的shopType字段决定：
| 类型 | 策略 | 兜底逻辑 |
|---|---|---|
| 1 | 本市出货量（库存）最大的门店 | 本市没有库存时，改为选本省距离最近的门店 |
| 2 | 距离自己位置最近的门店 | 用 WGS84 球面公式（地球半径 6378137m）计算经纬度大圆距离 |
添加账号时选择门店，系统会自动回填经纬度、省份、城市，之后每天预约时完全不用人工干预。门店列表页长这样：
请求发出去之前，系统还要过两道"手续"，这也是理解"算法已淘汰"的关键：
- 请求签名：验证码、登录接口用
MD5(密钥 + 参数 + 时间戳)校验； - 报文加密：预约报文里的门店、商品、数量经 AES-CBC 加密后作为
actParam提交。
这两组密钥硬编码在 IMTServiceImpl.java 里——官方接口或密钥一变，这套代码当场失效。还有一个小动作：请求头MT-APP-Version的版本号，是系统自己抓取 App Store 页面解析出 i茅台 App 的最新版本号、再缓存进 Redis 的，保证请求头永远和线上版本一致。
多账号管理：i茅台账号如何添加
后台"用户管理"是整套流程里唯一的人工环节。输入手机号、点"发送验证码"（系统调用 i茅台官方 vcode 接口），填入验证码后点"登录"，该账号的 token、cookie、userId 就落库了；不填设备号时会自动生成一个随机deviceId（UUID）。
几个容易忽略的细节：
- 系统按登录时间记录一个 30 天后到期的"到期时间"（token 的理论有效期），token 失效后需要回后台重新登录刷新；
- 每个账号可用
itemCode指定多个商品（@分隔），预约时逐个商品循环提交，每单之间随机延迟 3~5 秒； - 多管理员场景下，普通管理员只能查看和修改自己创建的账号，仅超管（userId=1）可见全部账号；
- 前端 vue_campus_admin/ 的业务页面就四个：用户管理、预约项目、门店列表、日志管理。
申购结果查询与推送：傍晚六点出结果
18:05 的appointmentResults遍历所有账号查询当日申购记录，命中"成功且 24 小时内"的记录后写入"申购成功"日志，同时触发推送。推送通道是 PushPlus 这类第三方消息服务，账号表里填好各自的pushPlusToken即可，标题会自动带上你给账号起的备注（"xxx-i茅台执行成功/失败"）。
日志判定成败很简单：内容里出现"报错"字样记为失败，否则记为成功。预约、旅行、结果查询的每一次执行都写进i_log表，管理后台有独立页面可追溯。旅行任务本身还有前置条件（耐力值 ≥ 100、9 点至 20 点时段内、当日次数未耗尽），不满足会记为执行失败而不是静默跳过。
一键部署：docker-compose 四容器方案
✅ 部署是这个项目最省事的部分，doc/docker/docker-compose.yml 一共 4 个容器：
| 容器 | 镜像 | 职责 |
|---|---|---|
| mysql | mysql:5.7 | 存账号、门店、商品、日志，自动建库campus_imaotai |
| redis | redis:6.2.12 | 缓存门店列表、sessionId、App 版本号（门店列表缓存 2 小时） |
| nginx-web | nginx:1.23.4 | 托管 Vue 管理端，/prod-api/反向代理到后端 |
| campus-server | campus/campus-imaotai:1.0.13 | Java 后端服务，监听 8160 端口 |
大致两步走：
git clone https://gitcode.com/GitHub_Trending/ca/campus-imaotai- 把 doc/sql/campus_imaotai-1.0.5.sql 导入 MySQL，包含
i_user、i_shop、i_item、i_log四张业务表和一套sys_*后台管理表； - 按 doc/docker/ 的目录约定创建
/docker/mysql、/docker/nginx、/docker/server/conf等挂载目录，放入前端构建产物与外部配置application-prod.yml（compose 里已声明spring.config.additional-location），docker-compose up -d即可。
所有容器都用network_mode: host，nginx 监听 80 端口，直接访问服务器 IP 就是管理后台。后端镜像基于adoptopenjdk/openjdk8，对应 Java 8（Spring Boot 2.5.15 + MyBatis-Plus 3.5.4.1 + hutool）。
重要边界：一个"已退役"的学习项目
动代码之前，请务必把这几条看进去：
- ⚠️ README 第一句就声明："本项目不提供成品，使用的是已淘汰的算法"——它依赖的接口、密钥、签名方式大概率已失效，现在跑起来不一定有结果；
- ⚠️ 免责声明写得很硬："所有直接或间接使用本项目的个人和组织，应 24 小时内完成学习和研究，并及时删除本项目中的所有内容"；
- ⚠️ 自动化批量调用第三方平台接口本身存在平台规则与合规风险，后果由使用者自行承担，项目方对所有数据与后果免责。
所以它的价值在哪？作为一个"逆向 App 接口 + 分钟级调度 + 多租户管理端 + 消息推送"的完整工程样板：常驻服务如何做分钟级错峰、缓存如何刷新、日志如何异步落库、推送如何解耦——这套模式在写其他定时类服务时是可以直接借鉴的。
一句话总结：campus-imaotai = 多账号托管（Web 管理端）+ 门店智能选择 + 24 小时定时自动预约 + 结果推送，docker-compose 一键部署。建议从 CampusIMTTask.java 的 5 个 cron 任务读起建立全局节奏感，再顺着IMTServiceImpl的请求链路看细节，是消化这个项目最快的路径。
【免费下载链接】campus-imaotaii茅台app自动预约，每日自动预约，支持docker一键部署（本项目不提供成品，使用的是已淘汰的算法）项目地址: https://gitcode.com/GitHub_Trending/ca/campus-imaotai
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考