2026年如何构建 Telegram Mini App:从原型到日活 60,000 用户

Telegram Mini Apps 已从实验性功能成长为真正的分发平台:每月有 2 亿用户打开它们,这是在即时通讯应用内发布产品最快增长的方式。我们于 2024 年初推出 The Open Earn,在 18 个月内将其发展到日活 60,000 用户和 500,000+ 完成的任务。本指南讲述我们做了什么,以及第一天我们会告诉自己的事情。

Mini App vs 普通机器人:何时选哪个

Telegram Bot 是基于消息的聊天界面。Telegram Mini App 是在 Telegram 内部打开的完整 Web 应用,可以访问即时通讯应用的 API。

普通机器人足够的情况:

• 流程是线性的:命令 → 回复(托管机器人、通知机器人)
• UI 复杂度最低
• 原型速度很重要

需要 Mini App 的情况:

• 具有导航、表单、列表的复杂 UI
• 实时交互
• 通过 Telegram Payments 或 Stars 支付
• 产品目录、用户资料、信息流

在 The Open Earn 中我们两者都用:用机器人处理通知和入门,用 Mini App 作为主界面(余额、提现、统计)。

技术栈:我们实际使用的

The Open Earn 的生产技术栈,无营销废话:

Frontend (Mini App):

• Next.js 16 (App Router, SSR) — 用于快速首屏渲染和落地页 SEO
• React 19 + TypeScript
• @twa-dev/sdk — Telegram Web Apps SDK 的封装(主题、viewport、事件)
• TonConnect SDK — 用于连接用户的 TON 钱包

Backend:

• Python 3.12 + FastAPI — API 服务器
• aiogram 3.x — 机器人
• PostgreSQL 16 — 主存储
• Redis — 会话缓存、限流、worker 的 pub/sub
• Celery — 后台任务(支付、任务验证)

基础设施:

• 一台独立服务器 (8 GB RAM, 4 vCPU)
• nginx 作为反向代理
• Node 进程用 PM2,Python 用 systemd
• SSL 用 Let's Encrypt

这能处理 50–100K DAU。我们只在突破 60K 时才不得不升级 — 我们将 Postgres 迁移到了一个 managed instance。

认证:initData 和服务端校验

最常见的新手错误:信任 Telegram.WebApp.initDataUnsafe。它在 DevTools 中是可伪造的。

正确的流程:

1. Mini App 在启动时通过 JS SDK 从 Telegram 接收 initData(raw string)
2. 它通过 Authorization: TelegramInitData ... 将其发送到您的后端
3. 后端用以 bot token 为密钥的 HMAC-SHA256 校验签名
4. 在签名有效时 — 提取 user.id 并发放会话 token

Python 中的校验:

import hmac, hashlib
from urllib.parse import parse_qs

def validate_init_data(init_data: str, bot_token: str) -> dict:
    parsed = parse_qs(init_data)
    received_hash = parsed.pop("hash")[0]
    data_check = "\n".join(f"{k}={v[0]}" for k, v in sorted(parsed.items()))
    secret = hmac.new(b"WebAppData", bot_token.encode(), hashlib.sha256).digest()
    expected = hmac.new(secret, data_check.encode(), hashlib.sha256).hexdigest()
    if not hmac.compare_digest(expected, received_hash):
        raise ValueError("Invalid signature")
    return parsed

也要检查 auth_date — 丢弃超过 24 小时的会话(防重放保护)。

支付:Stars、TON、USDT

2026 年 Telegram 生态系统内收款的三种实际方式:

1. Telegram Stars(用于数字商品) — 通过带有 currency: "XTR" 的 Bot API: sendInvoice。仅限无形商品购买。Telegram 抽取约 30%。

2. TON 直接 — 通过 TonConnect:用户连接钱包并签署交易。手续费仅为美分的几分之一。

3. TON 上的 USDT (Jetton) — 与 TON 相同,但作为稳定币。适用于 B2B 和固定价格计费。

在 The Open Earn 中,我们通过 TonConnect 以 USDT 支付收益 — 用户看到的是美元金额,而非波动的 TON 价格。最低提现:$1。

部署和扩展

前 10K DAU 最简单的生产布局:

[Cloudflare] → [nginx] → [Next.js on :3000] → [FastAPI on :8000] → [Postgres]
                                                  ↓
                                              [Redis]

我们在 30K DAU 时遇到的问题以及如何修复:

• Postgres connection pool 用尽 — 添加了 pgbouncer 并拆分了读/写
• Redis OOM 在峰值期 — 提高了 maxmemory,切换到 allkeys-lru
• 机器人 webhook 延迟 — 将重检查移到 Celery
• 静态资源 CDN — 推送到 Cloudflare R2

唯一重要的规则:测量,不要猜测。第一天就用 Sentry 处理错误,Grafana + Prometheus 处理指标。

我们会做不同的事情

如果第一天重新开始:

1. 从一开始就拆分为 2 个服务 — 公共 API (Mini App) 和私有(admin/workers)。合并比之后拆分便宜。
2. 从第一天开始发布 feature flags(Unleash、GrowthBook)— 在增长期间对 A/B 测试会很有用。
3. 使用 Next.js Server Actions 而不是为简单表单自定义 REST 层。代码更少。
4. 第一天跳过漂亮的动画 — 用户为功能而来,不是为打磨。打磨在 product-market fit 之后才有意义。
5. 从第一天就构建 i18n — 12 种语言的翻译让我们的流量翻了 4 倍,但事后改造很痛苦。

接下来

2026 年的 Mini Apps 不再是"Telegram 的实验"— 它们是真正的分发渠道。如果您的产品与即时通讯应用的活跃受众重叠,至少值得做一个原型。起步技术栈很小,风险比原生移动应用更低。

如果您想看看它在生产中的样子 — 打开 The Open Earn 或直接进入 机器人。