SubTrack 部署教程：用 Cloudflare 管理自己的订阅账单

AI 声明：本文由 AI 辅助撰写，根据 SubTrack 当前仓库的说明、配置和源码整理，并参考 Cloudflare 官方文档。文中的部署步骤未在你的 Cloudflare 账号中实际执行，控制台界面和第三方服务要求可能变化，请以实际环境为准。示例中的数据库 ID、密码和令牌需要自行替换，不要直接用于生产环境。

视频会员、云服务器、网盘、开发工具，单独看每笔费用不多，订阅一多就容易忘记什么时候续费、这个月花了多少钱。

SubTrack 用来记录这些订阅的金额、计费周期和到期时间，查看月度账单，并在到期前发送提醒。这篇教程从 Cloudflare 部署开始，带你完成首次配置、添加订阅和通知测试；如果想先在本地试用，也可以直接看第八节。

一、先了解项目能做什么

SubTrack 是一个单管理员使用的订阅管理系统，没有开放注册和多用户账号体系，适合个人记账。

它提供几个常用页面：

• 概览：查看总消费金额、月度预算剩余额度和即将到期的订阅。
• 订阅：添加、编辑、删除订阅，记录续期，调整订阅状态。
• 账单：按自然月查看费用，并点开查看明细。
• 提醒：查看即将到期或已过期的记录，手动检查提醒。
• 设置：调整预算、币种、时区，以及通知渠道和移动端显示方式。

前端使用 Vue 3 和 Vite，后端使用 Cloudflare Worker，数据存储在 D1。构建后的网页和 API 随同一个 Worker 部署，不需要再单独建一个 Pages 项目，也不需要自行维护服务器进程。

SubTrack 不会替你向服务商付款，也不会读取银行卡扣款记录。账单来自你填写的订阅信息和系统记录的续期信息，实际扣费仍需与服务商核对。

二、部署前准备

准备好以下内容：

1. 一个 Cloudflare 账号，可以创建 Workers 和 D1 数据库。
2. 一个 GitHub 账号，用于 Fork 项目并连接 Cloudflare 的 Git 构建。
3. 一组自己设置的管理员密码和随机签名密钥。

项目地址：https://github.com/qiuyuxc/SubTrack

打开仓库，点击 Fork，将项目复制到自己的 GitHub 账号下。后面修改配置时，操作的是自己的仓库。

这套部署方式不要求先在本地安装 Node.js。是否产生费用取决于 Cloudflare 当前套餐和实际用量，部署前可以在控制台确认 Workers、D1 的额度与计费规则。

三、部署到 Cloudflare

1. 创建 D1 数据库

进入 Cloudflare 控制台，找到 存储和数据库 → D1，创建一个数据库，比如命名为：

subtrack_db

创建完成后，复制数据库的 Database ID。

打开自己 Fork 的仓库，编辑根目录下的 wrangler.toml，找到 [[d1_databases]] 这一段：

[[d1_databases]]
binding = "DB"
database_name = "subtrack_db"
database_id = "替换为你自己的 Database ID"

其中，database_name 要与刚创建的数据库名称一致，database_id 必须替换成自己的 ID。仓库中已有的 ID 不属于你的账号，不能原样使用。

保留 binding = "DB" 不变，后端通过这个绑定名访问数据库。这里只替换对应字段，不要用这段内容覆盖整个配置文件，其他静态资源和定时任务配置也需要保留。

保存修改并提交到自己的仓库。项目会在首次请求时自动创建所需数据表，正常部署不需要手动执行 schema.sql，也不会自动向线上数据库填入演示数据。

2. 连接 Git 仓库

在 Cloudflare 控制台进入 Workers 和 Pages，创建 Worker，选择连接 Git 仓库的方式，授权并选中刚才 Fork 的项目。

控制台入口名称可能调整，关键是使用 Workers 的 Git 构建部署，不要把项目只作为静态网页发布。

构建配置按下面填写：

Root directory 不要填写 frontend 或 worker。根目录的 wrangler.toml 同时指定了后端入口、数据库绑定、静态资源和定时任务，部署命令需要从这里读取完整配置。

如果修改了 Worker 名称，也要同步修改仓库中的 name。非生产分支命令只在启用相应分支构建时使用，首次部署可以先关注生产分支。

3. 配置管理员账号和密钥

在 Worker 的 设置 → 变量和机密 中，确认以下运行时配置：

ADMIN_USERNAME 和 ALLOWED_ORIGIN 已在 wrangler.toml 的 [vars] 中声明，需要长期修改时建议同步修改仓库配置，避免后续部署与控制台值不一致。

密码和签名密钥使用控制台的机密类型，不要写进 Git 仓库，也不要只配置成构建环境变量。应用在处理请求时需要读取它们。

可以用密码管理器生成签名密钥。如果本机安装了 OpenSSL，也可以执行：

openssl rand -hex 32

将输出填入 AUTH_SECRET。不要与管理员密码共用同一个值，也不要把输出贴到公开文章、截图或问题反馈里。

本教程沿用项目默认的 ALLOWED_ORIGIN = "*"；它不是登录保护，受保护的接口仍需 Token。如果只允许自己的前端跨域访问，可以改为完整站点来源，比如 https://你的实际域名。

保存配置，并按控制台提示部署使其生效。如果首次构建完成后才添加机密，完成配置后再检查登录。

4. 确认部署结果

构建成功后，打开控制台提供的 Worker 访问地址。未启用落地页时，首页会进入登录页。

再访问同一域名下的：

/api/health

正常情况下会返回 JSON，其中包含 "ok": true。这个接口可以确认 Worker 路由正常，但不代表数据库和通知渠道已经验证通过。

用自己配置的管理员账号登录，尝试保存设置、添加一条订阅，才能继续确认 D1 的读写是否正常。线上没有内置的默认管理员密码，不能直接使用本地演示账号登录。

四、完成首次设置

登录后打开「设置」，先配置日常使用需要的几个选项：

修改后点击「保存设置」。通知渠道有各自的配置弹窗，需要在对应弹窗里单独保存。

剩余额度按「月度预算减去本月订阅支出」计算。账单按自然月归集费用，年付订阅会计入相应扣费月份，不是简单地每月摊销十二分之一。

项目支持填写不同币种，但当前汇总逻辑没有汇率换算。需要依赖总额和预算做判断时，建议统一记账币种；混用币种时不要把汇总数当作换算后的金额。

五、添加第一条订阅

打开「订阅」页面，点击「添加订阅」。可以先用一条示例熟悉表单：

日期以服务商账单为准。表单提供快捷日期和按周期计算的操作，保存前仍应确认实际到期日，避免把所有月付服务都当成固定 30 天。

还要留意「自动续费」开关：开启后，系统会在读取相关订阅数据时，将已过期的周期性订阅顺延到当前周期。它用于维护记录，不会真的付款。如果这项服务需要你手动续费，可以关闭开关，在实际付款后使用手动续期功能。

手动续期会顺延一个计费周期，并记录对应付款信息；一次性买断的订阅不支持这一操作。

保存后，回到概览和账单页查看记录。如果添加的是测试数据，测试结束后可以删除，再录入真实订阅。

六、配置到期提醒

项目支持站内提醒、浏览器推送、Webhook、Telegram Bot 和邮件。建议先配置一个能收到消息的外部渠道，再逐步增加其他渠道。

1. 站内提醒

站内提醒默认开启，不需要填写额外凭据。扫描到符合条件的订阅后，「提醒」页会生成记录，并显示未读提示。

它适合登录后集中查看，但不会单独把消息送到手机系统通知栏。

2. 浏览器推送

在「设置」中打开「浏览器推送」卡片：

1. 开启这个通知渠道。
2. 点击「在此设备开启推送」。
3. 在浏览器询问时允许通知。
4. 保存配置，点击「发送测试消息」。

每台设备都需要单独授权。线上使用 HTTPS 地址；浏览器、系统版本和通知权限也会影响能否接收。部分移动端环境需要先将站点添加到主屏幕，再开启推送，具体以浏览器支持情况为准。

App 模式只改变移动端界面，不等于自动获得通知权限，也不代表所有页面都能离线使用。

3. Webhook

如果已有群机器人或推送工具，可以打开「Webhook」卡片，选择对应服务类型。当前支持通用 Webhook、企业微信、钉钉、飞书、ntfy、Bark 和 Server 酱。

填写服务提供的推送地址，按所选类型补充签名密钥或访问令牌，然后开启渠道并发送测试消息。这里应填写实际的消息接收地址，不是服务商官网首页。

钉钉或飞书机器人启用了自定义关键词时，可以将关键词设为「订阅提醒」，与项目提醒正文匹配。启用了签名校验时，则需要填写对应密钥。

推送地址可能包含可直接发送消息的凭据，不要在截图或公开仓库中暴露完整地址。

4. Telegram 和邮件

Telegram 渠道需要 Bot Token 和 Chat ID，并确保机器人有权限向目标会话发送消息。

邮件渠道可以选择 SMTP、Resend 或自定义 HTTP 网关，填写发件人、收件人及对应凭据。SMTP 使用服务商支持的加密配置，项目支持 465 隐式 TLS 和 587 STARTTLS，不要使用 25 端口。

每个渠道弹窗中的「发送测试消息」都会先保存当前表单再尝试投递。测试失败时，查看界面展示的原因，确认收件目标、权限和凭据，而不是反复触发订阅扫描。

七、验证提醒是否真正生效

渠道测试通过后，再验证一次订阅到提醒的完整流程：

1. 确认要测试的通知渠道已启用。
2. 新建一条测试订阅，状态设为「生效中」，到期日设为明天，提前提醒天数设为 3。
3. 为了避免日期在测试中被顺延，关闭这条订阅的自动续费。
4. 打开「提醒」页，点击「立即检查提醒」。
5. 确认页面出现提醒记录，并检查目标设备或服务是否收到消息。

同一订阅、同一到期日、同一种提醒只会生成一次。再次点击检查没有新增记录，可能是去重生效，不一定是故障。如果第一次投递失败，重复扫描也不会重新发送已有记录；排查渠道时使用「发送测试消息」，需要重测完整流程时再创建新的测试订阅。

线上自动扫描由 wrangler.toml 中的 Cron 配置触发：

[triggers]
crons = ["0 1 * * *"]

这表示每天 UTC 01:00 执行，也就是北京时间 09:00。应用里的时区用于判断「今天」和到期日期，修改它不会自动修改 Cron 的触发时间。若要调整扫描时刻，需要修改 Cron 表达式并重新部署。

暂停和取消的订阅不会进入到期提醒扫描。自动续费的周期性订阅会先按规则顺延日期，因此测试「已过期」提醒时，也应关闭自动续费。

八、可选：先在本地试用

本地运行需要 Git、npm，以及支持内置 node:sqlite 的 Node.js。建议使用 Node.js 24 LTS，旧版本遇到 SQLite 模块错误时先升级。

克隆项目并进入目录：

git clone https://github.com/qiuyuxc/SubTrack.git
cd SubTrack

如果已经下载或克隆了项目，直接在项目根目录执行后续命令即可。

安装前端依赖：

npm run install:web

可选，向本地 SQLite 写入演示订阅：

npm run seed:demo

构建并启动：

npm run serve

打开 http://localhost:8787，本地默认用户名是 admin，密码是 admin12345。

本地服务使用 Node.js 和 SQLite 运行 Worker 代码。演示数据只写入本地数据库，默认位置为 .data/subtrack.db，不会同步到 Cloudflare D1。

默认账号仅用于本地试用。不要把使用默认凭据的服务开放到公网或不可信网络；需要对外使用时，自行设置 ADMIN_USERNAME、ADMIN_PASSWORD 和 AUTH_SECRET 环境变量。

改动前端后使用 npm run serve 重新构建并启动；npm start 只启动服务，不会重新构建页面。本地服务也不会自动模拟线上每日 Cron，测试提醒时使用页面上的「立即检查提醒」。

九、常见问题与数据安全

页面能打开，但接口异常

先访问 /api/health。如果返回网页或找不到接口，检查是否误部署成纯静态站点，以及 Root directory 是否错误地填成了 frontend。

如果健康接口正常，但登录后无法读取或保存数据，检查 D1 绑定名是否为 DB、数据库 ID 是否属于当前 Cloudflare 账号，并查看 Worker 日志。健康接口本身不验证数据库读写。

提示服务端未配置管理员账号

确认 ADMIN_USERNAME 和 ADMIN_PASSWORD 已作为 Worker 运行时变量或机密生效，不是只放在构建环境中。设置完成后按控制台提示部署，再尝试登录。

通知测试成功，实际订阅却没有提醒

检查订阅是否处于「生效中」、到期日是否进入提醒窗口、渠道是否启用，以及这次到期是否已经生成过同类型提醒。还要检查自动续费是否已将日期顺延。

手动扫描正常但定时扫描没有执行时，检查 Worker 的 Cron 配置与执行日志，并按 UTC 时间核对计划。刚修改的 Cron 可能需要一段时间才生效。

部署后看不到演示数据

线上空库是正常情况。npm run seed:demo 只作用于本地开发数据库，线上需要自行添加订阅。

哪些数据需要保密和备份？

管理员密码和签名密钥放在 Worker 机密中。通过应用配置的通知凭据则存储在 D1，当前是明文存储；接口不会把已保存的机密明文回传给前端，但拥有数据库访问权限的人仍能读取它们。

因此，不要公开数据库导出文件、完整推送地址或包含凭据的截图。正式使用后，定期通过 Cloudflare 提供的方式备份 D1；本地使用时也要妥善备份 SQLite 数据。备份文件同样应按敏感数据保管。

线上不要开启 DEBUG_ERRORS=1，避免接口响应暴露内部错误信息。更换服务或怀疑凭据泄露时，及时在对应平台撤销旧凭据并重新配置。

参考资料

• SubTrack 项目仓库
• 项目 README
• Cloudflare Workers Git 构建配置
• Cloudflare D1 入门
• Cloudflare Cron Triggers

总结

部署 SubTrack 的关键是把自己的 D1 数据库绑定到 Worker，从仓库根目录构建部署，再配置管理员账号和签名密钥。登录后，先录入一条测试订阅，跑通「保存记录、检查提醒、收到通知」的流程，再整理真实订阅。

日常使用时，重点维护金额、到期日和续费状态，定期核对账单并备份数据。SubTrack 可以帮你集中查看支出、减少遗漏到期时间的情况；是否继续订阅、是否已经付款，仍需要结合服务商的实际记录确认。