先数输入项：三步以内用对话流程，超过五项倾向 Mini App
对话流程的单位是消息。用户每做一次选择或输入，就产生一轮往返，步骤越多，聊天记录越长，出错后回退越难。经验上，固定选项加一两个自由文本、总共三步以内能完成的任务，比如订阅开关、领取权益、确认订单，用内联按钮加状态机就够了。超过五个字段、字段之间有联动校验，或者用户需要在提交前总览全部内容，表单类界面的优势就很明显。这不是硬阈值，但可以作为第一道筛子：如果你在设计稿里已经写出「上一步」「修改第 2 项」，说明对话形态在对抗任务本身。
回改与浏览需求决定成本，比字段数更关键
有两类需求会把对话流程推到极限。一是回改：用户填完第四步想改第一步，机器人要么重发整套流程，要么维护复杂的编辑态。二是浏览：商品列表、筛选、分页、对比，这些在聊天里只能靠翻页按钮和 editMessageText 勉强模拟。内联按钮的 callback_data 长度有限（目前文档规定为 1 到 64 字节），复杂筛选条件很难塞进去，只能在服务端存会话再用短 ID 引用，状态管理随之变重。遇到这两类需求，Mini App 的开发量通常反而更低，因为你得到的是完整的页面状态，而不是在消息里拼状态。
Mini App 不是免费升级：鉴权、入口与数据回传要单独设计
Mini App 本质是跑在 Telegram 内的网页，需要 HTTPS 托管。身份来自客户端传入的 initData，服务端必须用机器人令牌按官方文档的方法校验签名，不能直接信任前端传来的用户 ID。入口可以是菜单按钮、内联按钮或键盘按钮，不同入口能用的能力不同，例如通过键盘按钮打开时可以用 sendData 把少量数据回传给机器人，但有大小上限，且之后会话会关闭。另外，Mini App 自己不能主动给用户推消息，提醒和通知仍要靠机器人发送。具体限制以 Telegram 当前文档为准，上线前逐项核对。
群聊、转发与低频触达场景，对话流程更稳
如果核心场景发生在群里，比如投票、抢单、管理员命令，机器人命令和按钮是天然入口，而 Mini App 在群内的打开方式和身份上下文更受限。另外，对话流程几乎没有加载成本，弱网环境下也能工作；Mini App 要加载前端资源，首屏慢会直接影响转化。用户每次只花十几秒的轻操作，比如查询、签到、确认，不值得为此让用户进入一个网页。判断标准可以更简单：用户停留时长不到半分钟、且无需视觉布局，就优先留在聊天里。
混合方案通常最合理：机器人负责入口与通知，Mini App 负责重交互
实际项目里常见的拆法是：机器人处理启动、命令、状态通知和支付结果回调，把一个复杂环节交给 Mini App，完成后由服务端向机器人发确认消息。这样保留了触达能力，也避免把整个产品做成网页。要注意两边共用同一套用户标识和订单状态，数据以服务端为准，不要依赖聊天消息作为事实来源。如果产品涉及 Telegram 内的付款，数字商品相关规则和可用支付方式会变化，应以平台当时的官方说明为准，不要按旧经验设计计费。
需要后台任务、设备能力或应用商店分发时，才考虑原生 App
Mini App 和机器人都不需要应用商店账号，这是它们的优势。但如果产品需要稳定的系统级推送、后台运行、蓝牙或相机等深度设备能力，或者要靠应用商店获客，就应评估原生 App，Android 侧即上架 Google Play。此时开发者账号的主体、收款资料、是否已有应用历史会影响上架节奏，下单购买或交接账号前要核对持有人、权限和已有 App，而不是只看账号是否可用。决策线很清楚：能在聊天与网页内完成的，不要为了「像个 App」去背商店审核和账号维护成本。