简介这是一套面向茅台抢购需求用户的i茅台自动预约解决方案基于Spring Boot与Vue构建支持Docker一键部署适合具备一定后端与容器化基础的技术人员使用用于每日定时自动完成i茅台App的预约流程减少手动操作成本。压缩包共542个文件约2.99MB以Java源码209个为核心业务逻辑Vue组件87个与JavaScript84个构成前端界面另含SVG图标、XML配置、SCSS样式、YML部署文件及bat启动脚本前后端分离结构清晰便于二次开发与本地调试。目前已有1483人学习下载。资源提供完整可运行的项目源码与容器化部署配置读者可据此理解自动预约的接口调用与任务调度思路掌握Docker快速搭建与配置修改方法并参考目录结构进行功能扩展或排错快速落地属于自己的预约工具。1. i茅台自动预约这件事到底能不能用 Docker 一把梭每天九点整手指头在屏幕上戳到发酸结果申购页面转两圈告诉你“今日申购已结束”——这事我干过整整一周后来才想明白手动抢和脚本抢根本不在一个维度上。i茅台 App 的申购入口每天固定时间开放拼的是请求发出去的那一瞬间人手的反应速度在系统面前基本可以忽略。这份资源就是冲着这个痛点来的一个支持 Docker 一键部署的 i茅台自动预约工具把“每天定点手动点”变成“容器跑着、到点自己发请求”。它适合两类人——一是有台常年开机的 NAS、软路由或者云主机想让预约这件事彻底自动化二是想借这个项目练手 Docker 部署、定时任务和接口调用把它当成一个真实的小型运维场景来拆。需要提前说清楚的是这类工具的本质是替你按点发请求不改变申购本身的随机性别指望装上就中签它的价值在于把“忘记预约”和“手速不够”这两个变量消掉。2. 拆开这个包目录结构、运行链路与 Docker 部署前置条件2.1 从压缩包到容器这个项目里到底装了什么拿到i茅台app自动预约每日自动预约支持docker一键部署.zip之后先别急着解压完就docker run。我一般会先把包解开用tree或者直接看目录确认三样东西在不在Dockerfile、docker-compose.yml、以及一个存放账号信息的配置文件通常是.env、config.json或accounts.json这类。这三样决定了你能不能真正做到“一键”。一个典型的这类项目目录大概长这样i茅台自动预约/ ├── Dockerfile # 镜像构建脚本 ├── docker-compose.yml # 一键编排入口 ├── app/ │ ├── main.py # 预约主逻辑 │ ├── schedule.py # 定时调度 │ └── notify.py # 结果推送可选 ├── config/ │ └── config.example.json # 配置模板需要复制成 config.json └── requirements.txt # Python 依赖看到这个结构心里就有数了它是一个 Python 写的定时任务被打进镜像靠 compose 拉起来。config.example.json是模板你必须复制一份改成自己的否则容器起来也是空跑。这一步是新手最容易漏的——直接docker compose up然后发现日志里全是“未找到账号配置”。运行链路其实不复杂容器启动 → 读取配置里的账号通常是手机号 验证码换来的 token→ 调度器在设定时间触发 → 调用申购接口 → 把结果写日志或推送。理解这条链路后面排查问题就有方向了日志停在哪一环问题就在哪一环。2.2 Docker 环境准备Windows、Linux、NAS 三条路热词里docker安装、docker desktop安装教程、windows安装docker、ubuntu安装docker全都在榜上说明很多人卡在第一步。我按三种常见环境分别说你对号入座。Linux 服务器最省心推荐# Ubuntu/Debian 系 curl -fsSL https://get.docker.com | sh sudo systemctl enable docker sudo systemctl start docker # 验证 docker version docker compose versionget.docker.com这个官方脚本会把 docker engine 和 compose 插件一起装上省得你单独折腾 compose。装完docker version能看到 Client 和 Server 两段才算成功只有 Client 说明守护进程没起来回去看systemctl status docker。Windows 环境装 Docker Desktop前提是开启 WSL2。热词里windows环境安装wsl2和docker、virtualization support not detected都是高频翻车点。virtualization support not detected这个报错九成是 BIOS 里虚拟化没开Intel VT-x / AMD-V进 BIOS 打开再重启。WSL2 装好后 Docker Desktop 才能正常跑 Linux 容器。NAS群晖、威联通直接在套件中心或应用商店装 Docker/Container Manager然后走图形化的 compose 导入。NAS 用户注意路径映射群晖的 docker 目录一般在/volume1/docker映射配置文件夹时别写错。提示国内拉镜像慢是常态热词里docker镜像下载慢不是你的错觉。可以在 Docker Desktop 或/etc/docker/daemon.json里配镜像加速地址配完记得重启 docker 服务。2.3 一键部署实操从改配置到容器跑起来环境好了进入正题。假设你已经解压到/opt/imt操作顺序如下。第一步复制配置模板并填账号cd /opt/imt cp config/config.example.json config/config.json # 用编辑器打开 config.json填入手机号和 token第二步看一眼 compose 文件确认端口、时区、挂载路径services: imt: build: . container_name: imt-auto restart: unless-stopped environment: - TZAsia/Shanghai volumes: - ./config:/app/config - ./logs:/app/logs这里三个参数值得说。TZAsia/Shanghai必须设否则容器默认 UTC你的“每天九点”会变成下午五点这是血泪经验。restart: unless-stopped保证宿主机重启后容器自动拉起不然某天断电你就断了预约。volumes把配置和日志挂到宿主机容器删了配置还在日志也能直接看。第三步构建并启动docker compose up -d --build docker compose logs -f--build是首次必须的它会按 Dockerfile 构建镜像。-d后台运行logs -f实时看日志。日志里出现“调度已启动”“下次预约时间 xxx”这类字样基本就成了。第四步验证定时是否生效。可以临时把预约时间改到几分钟后观察日志是否触发确认无误再改回真实时间。这个“先小步验证再上线”的习惯能帮你避开大部分“以为在跑其实没跑”的坑。3. 账号配置与定时调度token 怎么来、时间怎么设才不翻车3.1 账号凭证的获取与维护token 不是一劳永逸这类工具的核心凭证是登录后的 token或 cookie。i茅台 App 的登录态有有效期token 过期后接口会返回鉴权失败预约自然就断了。所以配置里填的 token 不是填一次管一辈子。常见做法是手动抓一次登录后的 token 填进配置然后靠工具自身的“保活”逻辑定期刷新。如果项目带自动刷新配置里通常会有 refresh_token 字段如果不带你就得接受每隔一段时间手动更新一次。我一般会在日历上设个提醒每周检查一次日志里有没有鉴权失败的记录。配置示例字段名以实际项目为准这里示意结构{ accounts: [ { phone: 138xxxxxxxx, token: 抓包得到的token, refresh_token: 抓包得到的refresh_token, enabled: true } ], reserve_time: 09:00:00, retry: 3, notify: { type: serverchan, key: 你的推送key } }reserve_time是预约触发时间retry是失败重试次数notify是结果推送。推送这块建议配上不然你根本不知道今天到底约没约上只能靠翻日志体验很差。3.2 定时调度的时区与触发精度调度翻车最常见的原因就两个时区和触发精度。时区前面说了容器内必须Asia/Shanghai。验证方法很简单进容器执行datedocker exec -it imt-auto date输出应该是北京时间。如果差 8 小时回去检查 compose 里的 TZ 环境变量。触发精度方面申购入口开放的那一瞬间请求量巨大脚本发太早接口没开发太晚名额没了。项目一般会设置一个提前量比如 09:00:00 开放脚本在 08:59:59.5 就开始轮询。这个提前量在配置里通常叫advance_ms或类似名字别乱改默认值是作者调过的。你要改就小幅度试改大了请求打在未开放接口上会被拒改小了又抢不到先手。# 调度核心逻辑示意非项目原码帮助理解 import schedule import time def job(): for acc in accounts: if acc[enabled]: try: result reserve(acc) # 调用申购接口 log(result) notify(result) except AuthError: log(f{acc[phone]} token 失效需更新) except Exception as e: log(f预约异常: {e}) # 每天定点触发 schedule.every().day.at(config[reserve_time]).do(job) while True: schedule.run_pending() time.sleep(0.5) # 轮询间隔越小触发越准但别设 0这段逻辑说明三件事一是按账号循环多账号可以一起约二是鉴权失败单独捕获方便你定位是 token 问题还是网络问题三是time.sleep别设成 0空转吃 CPU0.5 秒足够。3.3 多账号与结果推送的配置取舍多账号场景下配置里accounts数组加多条就行但要注意两点一是每个账号的 token 独立维护一个过期不影响另一个二是请求之间最好加个小间隔别同一毫秒全发出去容易被风控盯上。项目里如果有interval参数设个 200~500 毫秒比较稳妥。推送这块常见的有 Server 酱、企业微信机器人、Bark、钉钉机器人。选哪个看你手头有什么。企业微信机器人最省事建个群加个机器人拿 webhook 就行。推送内容建议包含账号、预约时间、返回结果。这样你一眼就知道谁约上了、谁 token 挂了。注意推送 key 和 token 一样属于敏感信息别把带真实 key 的配置文件传到公开仓库这是很多人翻车的地方。4. 避坑与排查容器起不来、预约不触发、token 失效怎么查4.1 容器启动即退出日志报配置缺失现象docker compose up -d后docker ps看不到容器或者状态是 Exited。原因九成是config.json没创建或者路径映射不对容器里读不到配置直接退出。解决先docker compose logs看报错。如果是“config not found”检查宿主机./config/config.json是否存在以及 compose 里 volumes 的映射路径是否和容器内读取路径一致。路径映射写错是高频问题./config:/app/config左边是宿主机、右边是容器别搞反。4.2 时间到了但预约没触发现象日志显示调度已启动但到了设定时间没有任何预约记录。原因时区不对最常见或者调度进程被异常卡死。解决先docker exec -it 容器名 date确认时间。时区对了还不动看日志最后一行停在哪如果是卡在某个网络请求上可能是接口地址变了或者网络不通。重启容器docker compose restart往往能恢复但根因要查清楚别养成“重启大法”依赖。4.3 token 失效导致静默失败现象容器在跑日志也没报错但就是约不上翻日志发现鉴权失败。原因token 过期而工具没有自动刷新或刷新失败。解决手动更新 token。如果项目支持 refresh_token 自动刷新检查 refresh_token 是否也过期了。建议在推送里加上“鉴权失败”告警别让它静默失败否则你可能一周后才发现根本没约。4.4 镜像拉取或构建失败现象docker compose up --build卡在拉取基础镜像或者构建时报依赖安装失败。原因网络问题拉不到镜像或者 requirements 里的包源访问不了。解决配镜像加速构建阶段如果卡在 pip install可以在 Dockerfile 里把 pip 源换成国内源。热词里docker镜像下载慢、failed to connect to the docker api都属于这类前者是网络后者多半是 Docker Desktop 没启动或 WSL2 后端异常重启 Docker Desktop 通常能解决。4.5 多账号互相干扰现象配了两个账号只有一个能约另一个总是失败。原因请求间隔太短触发风控或者两个账号共用了同一个 token。解决检查每个账号的 token 是否独立在配置里加大请求间隔。别图快把间隔设成 0风控面前快没有意义。5. 进阶玩法把预约结果接进自己的通知链路跑通基础部署之后我一般会做一件事把预约结果从“翻日志”升级成“主动推送到手机”。项目自带的推送如果够用就用不够用就自己加一个 webhook把结果 POST 到你自己的服务上。这样你能做更多事比如把每天的预约结果存进数据库月底统计一下中签率或者中签时触发一个更醒目的提醒。具体做法是在notify.py里加一个自定义推送函数import requests def push_custom(result): 把预约结果推送到自定义 webhook payload { phone: result[phone], time: result[time], status: result[status], # success / fail / auth_error msg: result.get(msg, ) } try: requests.post( https://你的webhook地址, jsonpayload, timeout5 ) except Exception as e: print(f推送失败: {e})这段代码的关键点是timeout5别不设超时否则推送服务挂了会把主流程卡住。status字段区分成功、失败、鉴权错误方便你后续做不同处理——鉴权错误要立刻去更新 token普通失败明天再约就行。验证方法也简单手动调用一次push_custom看手机收不收得到。收到再挂到主流程里别一上来就全接上出问题不好定位。再进阶一点可以用docker compose把预约工具和一个轻量数据库比如 SQLite 或 MySQL编排在一起每次预约写一条记录。热词里docker安装mysql8.0并使用、docker compose都是这个方向。不过对大多数人来说一个日志文件加推送就够了别为了进阶而进阶稳定跑起来比什么都强。从那以后我每次部署这类定时任务都强制先改时区、再小步验证触发、最后才接推送三步走完才敢让它长期跑。这套习惯帮我省了太多“以为在跑其实没跑”的后悔药。希望帮到你。本文还有配套的精品资源点击获取 Docker一键部署i茅台自动预约工具：从环境搭建到定时调度避坑指南
简介这是一套面向茅台抢购需求用户的i茅台自动预约解决方案基于Spring Boot与Vue构建支持Docker一键部署适合具备一定后端与容器化基础的技术人员使用用于每日定时自动完成i茅台App的预约流程减少手动操作成本。压缩包共542个文件约2.99MB以Java源码209个为核心业务逻辑Vue组件87个与JavaScript84个构成前端界面另含SVG图标、XML配置、SCSS样式、YML部署文件及bat启动脚本前后端分离结构清晰便于二次开发与本地调试。目前已有1483人学习下载。资源提供完整可运行的项目源码与容器化部署配置读者可据此理解自动预约的接口调用与任务调度思路掌握Docker快速搭建与配置修改方法并参考目录结构进行功能扩展或排错快速落地属于自己的预约工具。1. i茅台自动预约这件事到底能不能用 Docker 一把梭每天九点整手指头在屏幕上戳到发酸结果申购页面转两圈告诉你“今日申购已结束”——这事我干过整整一周后来才想明白手动抢和脚本抢根本不在一个维度上。i茅台 App 的申购入口每天固定时间开放拼的是请求发出去的那一瞬间人手的反应速度在系统面前基本可以忽略。这份资源就是冲着这个痛点来的一个支持 Docker 一键部署的 i茅台自动预约工具把“每天定点手动点”变成“容器跑着、到点自己发请求”。它适合两类人——一是有台常年开机的 NAS、软路由或者云主机想让预约这件事彻底自动化二是想借这个项目练手 Docker 部署、定时任务和接口调用把它当成一个真实的小型运维场景来拆。需要提前说清楚的是这类工具的本质是替你按点发请求不改变申购本身的随机性别指望装上就中签它的价值在于把“忘记预约”和“手速不够”这两个变量消掉。2. 拆开这个包目录结构、运行链路与 Docker 部署前置条件2.1 从压缩包到容器这个项目里到底装了什么拿到i茅台app自动预约每日自动预约支持docker一键部署.zip之后先别急着解压完就docker run。我一般会先把包解开用tree或者直接看目录确认三样东西在不在Dockerfile、docker-compose.yml、以及一个存放账号信息的配置文件通常是.env、config.json或accounts.json这类。这三样决定了你能不能真正做到“一键”。一个典型的这类项目目录大概长这样i茅台自动预约/ ├── Dockerfile # 镜像构建脚本 ├── docker-compose.yml # 一键编排入口 ├── app/ │ ├── main.py # 预约主逻辑 │ ├── schedule.py # 定时调度 │ └── notify.py # 结果推送可选 ├── config/ │ └── config.example.json # 配置模板需要复制成 config.json └── requirements.txt # Python 依赖看到这个结构心里就有数了它是一个 Python 写的定时任务被打进镜像靠 compose 拉起来。config.example.json是模板你必须复制一份改成自己的否则容器起来也是空跑。这一步是新手最容易漏的——直接docker compose up然后发现日志里全是“未找到账号配置”。运行链路其实不复杂容器启动 → 读取配置里的账号通常是手机号 验证码换来的 token→ 调度器在设定时间触发 → 调用申购接口 → 把结果写日志或推送。理解这条链路后面排查问题就有方向了日志停在哪一环问题就在哪一环。2.2 Docker 环境准备Windows、Linux、NAS 三条路热词里docker安装、docker desktop安装教程、windows安装docker、ubuntu安装docker全都在榜上说明很多人卡在第一步。我按三种常见环境分别说你对号入座。Linux 服务器最省心推荐# Ubuntu/Debian 系 curl -fsSL https://get.docker.com | sh sudo systemctl enable docker sudo systemctl start docker # 验证 docker version docker compose versionget.docker.com这个官方脚本会把 docker engine 和 compose 插件一起装上省得你单独折腾 compose。装完docker version能看到 Client 和 Server 两段才算成功只有 Client 说明守护进程没起来回去看systemctl status docker。Windows 环境装 Docker Desktop前提是开启 WSL2。热词里windows环境安装wsl2和docker、virtualization support not detected都是高频翻车点。virtualization support not detected这个报错九成是 BIOS 里虚拟化没开Intel VT-x / AMD-V进 BIOS 打开再重启。WSL2 装好后 Docker Desktop 才能正常跑 Linux 容器。NAS群晖、威联通直接在套件中心或应用商店装 Docker/Container Manager然后走图形化的 compose 导入。NAS 用户注意路径映射群晖的 docker 目录一般在/volume1/docker映射配置文件夹时别写错。提示国内拉镜像慢是常态热词里docker镜像下载慢不是你的错觉。可以在 Docker Desktop 或/etc/docker/daemon.json里配镜像加速地址配完记得重启 docker 服务。2.3 一键部署实操从改配置到容器跑起来环境好了进入正题。假设你已经解压到/opt/imt操作顺序如下。第一步复制配置模板并填账号cd /opt/imt cp config/config.example.json config/config.json # 用编辑器打开 config.json填入手机号和 token第二步看一眼 compose 文件确认端口、时区、挂载路径services: imt: build: . container_name: imt-auto restart: unless-stopped environment: - TZAsia/Shanghai volumes: - ./config:/app/config - ./logs:/app/logs这里三个参数值得说。TZAsia/Shanghai必须设否则容器默认 UTC你的“每天九点”会变成下午五点这是血泪经验。restart: unless-stopped保证宿主机重启后容器自动拉起不然某天断电你就断了预约。volumes把配置和日志挂到宿主机容器删了配置还在日志也能直接看。第三步构建并启动docker compose up -d --build docker compose logs -f--build是首次必须的它会按 Dockerfile 构建镜像。-d后台运行logs -f实时看日志。日志里出现“调度已启动”“下次预约时间 xxx”这类字样基本就成了。第四步验证定时是否生效。可以临时把预约时间改到几分钟后观察日志是否触发确认无误再改回真实时间。这个“先小步验证再上线”的习惯能帮你避开大部分“以为在跑其实没跑”的坑。3. 账号配置与定时调度token 怎么来、时间怎么设才不翻车3.1 账号凭证的获取与维护token 不是一劳永逸这类工具的核心凭证是登录后的 token或 cookie。i茅台 App 的登录态有有效期token 过期后接口会返回鉴权失败预约自然就断了。所以配置里填的 token 不是填一次管一辈子。常见做法是手动抓一次登录后的 token 填进配置然后靠工具自身的“保活”逻辑定期刷新。如果项目带自动刷新配置里通常会有 refresh_token 字段如果不带你就得接受每隔一段时间手动更新一次。我一般会在日历上设个提醒每周检查一次日志里有没有鉴权失败的记录。配置示例字段名以实际项目为准这里示意结构{ accounts: [ { phone: 138xxxxxxxx, token: 抓包得到的token, refresh_token: 抓包得到的refresh_token, enabled: true } ], reserve_time: 09:00:00, retry: 3, notify: { type: serverchan, key: 你的推送key } }reserve_time是预约触发时间retry是失败重试次数notify是结果推送。推送这块建议配上不然你根本不知道今天到底约没约上只能靠翻日志体验很差。3.2 定时调度的时区与触发精度调度翻车最常见的原因就两个时区和触发精度。时区前面说了容器内必须Asia/Shanghai。验证方法很简单进容器执行datedocker exec -it imt-auto date输出应该是北京时间。如果差 8 小时回去检查 compose 里的 TZ 环境变量。触发精度方面申购入口开放的那一瞬间请求量巨大脚本发太早接口没开发太晚名额没了。项目一般会设置一个提前量比如 09:00:00 开放脚本在 08:59:59.5 就开始轮询。这个提前量在配置里通常叫advance_ms或类似名字别乱改默认值是作者调过的。你要改就小幅度试改大了请求打在未开放接口上会被拒改小了又抢不到先手。# 调度核心逻辑示意非项目原码帮助理解 import schedule import time def job(): for acc in accounts: if acc[enabled]: try: result reserve(acc) # 调用申购接口 log(result) notify(result) except AuthError: log(f{acc[phone]} token 失效需更新) except Exception as e: log(f预约异常: {e}) # 每天定点触发 schedule.every().day.at(config[reserve_time]).do(job) while True: schedule.run_pending() time.sleep(0.5) # 轮询间隔越小触发越准但别设 0这段逻辑说明三件事一是按账号循环多账号可以一起约二是鉴权失败单独捕获方便你定位是 token 问题还是网络问题三是time.sleep别设成 0空转吃 CPU0.5 秒足够。3.3 多账号与结果推送的配置取舍多账号场景下配置里accounts数组加多条就行但要注意两点一是每个账号的 token 独立维护一个过期不影响另一个二是请求之间最好加个小间隔别同一毫秒全发出去容易被风控盯上。项目里如果有interval参数设个 200~500 毫秒比较稳妥。推送这块常见的有 Server 酱、企业微信机器人、Bark、钉钉机器人。选哪个看你手头有什么。企业微信机器人最省事建个群加个机器人拿 webhook 就行。推送内容建议包含账号、预约时间、返回结果。这样你一眼就知道谁约上了、谁 token 挂了。注意推送 key 和 token 一样属于敏感信息别把带真实 key 的配置文件传到公开仓库这是很多人翻车的地方。4. 避坑与排查容器起不来、预约不触发、token 失效怎么查4.1 容器启动即退出日志报配置缺失现象docker compose up -d后docker ps看不到容器或者状态是 Exited。原因九成是config.json没创建或者路径映射不对容器里读不到配置直接退出。解决先docker compose logs看报错。如果是“config not found”检查宿主机./config/config.json是否存在以及 compose 里 volumes 的映射路径是否和容器内读取路径一致。路径映射写错是高频问题./config:/app/config左边是宿主机、右边是容器别搞反。4.2 时间到了但预约没触发现象日志显示调度已启动但到了设定时间没有任何预约记录。原因时区不对最常见或者调度进程被异常卡死。解决先docker exec -it 容器名 date确认时间。时区对了还不动看日志最后一行停在哪如果是卡在某个网络请求上可能是接口地址变了或者网络不通。重启容器docker compose restart往往能恢复但根因要查清楚别养成“重启大法”依赖。4.3 token 失效导致静默失败现象容器在跑日志也没报错但就是约不上翻日志发现鉴权失败。原因token 过期而工具没有自动刷新或刷新失败。解决手动更新 token。如果项目支持 refresh_token 自动刷新检查 refresh_token 是否也过期了。建议在推送里加上“鉴权失败”告警别让它静默失败否则你可能一周后才发现根本没约。4.4 镜像拉取或构建失败现象docker compose up --build卡在拉取基础镜像或者构建时报依赖安装失败。原因网络问题拉不到镜像或者 requirements 里的包源访问不了。解决配镜像加速构建阶段如果卡在 pip install可以在 Dockerfile 里把 pip 源换成国内源。热词里docker镜像下载慢、failed to connect to the docker api都属于这类前者是网络后者多半是 Docker Desktop 没启动或 WSL2 后端异常重启 Docker Desktop 通常能解决。4.5 多账号互相干扰现象配了两个账号只有一个能约另一个总是失败。原因请求间隔太短触发风控或者两个账号共用了同一个 token。解决检查每个账号的 token 是否独立在配置里加大请求间隔。别图快把间隔设成 0风控面前快没有意义。5. 进阶玩法把预约结果接进自己的通知链路跑通基础部署之后我一般会做一件事把预约结果从“翻日志”升级成“主动推送到手机”。项目自带的推送如果够用就用不够用就自己加一个 webhook把结果 POST 到你自己的服务上。这样你能做更多事比如把每天的预约结果存进数据库月底统计一下中签率或者中签时触发一个更醒目的提醒。具体做法是在notify.py里加一个自定义推送函数import requests def push_custom(result): 把预约结果推送到自定义 webhook payload { phone: result[phone], time: result[time], status: result[status], # success / fail / auth_error msg: result.get(msg, ) } try: requests.post( https://你的webhook地址, jsonpayload, timeout5 ) except Exception as e: print(f推送失败: {e})这段代码的关键点是timeout5别不设超时否则推送服务挂了会把主流程卡住。status字段区分成功、失败、鉴权错误方便你后续做不同处理——鉴权错误要立刻去更新 token普通失败明天再约就行。验证方法也简单手动调用一次push_custom看手机收不收得到。收到再挂到主流程里别一上来就全接上出问题不好定位。再进阶一点可以用docker compose把预约工具和一个轻量数据库比如 SQLite 或 MySQL编排在一起每次预约写一条记录。热词里docker安装mysql8.0并使用、docker compose都是这个方向。不过对大多数人来说一个日志文件加推送就够了别为了进阶而进阶稳定跑起来比什么都强。从那以后我每次部署这类定时任务都强制先改时区、再小步验证触发、最后才接推送三步走完才敢让它长期跑。这套习惯帮我省了太多“以为在跑其实没跑”的后悔药。希望帮到你。本文还有配套的精品资源点击获取