结论先说：高频使用、需要设备能力或强留存，做 APP；低频服务、微信内获客和轻交易，做小程序；活动页、表单和轻量展示，用 H5。很多项目是组合，而不是三选一。
| 维度 | 原生 / 跨平台 APP | 小程序 | H5 |
|---|---|---|---|
| 体验 | 最好，接近系统原生 | 较好，受平台容器限制 | 一般，依赖浏览器 |
| 开发成本 | 高，双端和维护成本更高 | 中，按平台分别开发 | 低，一套网页多端访问 |
| 上线周期 | 较长，需商店审核 | 较短，平台审核 | 最短，部署即可访问 |
| 分发入口 | 应用商店、桌面图标 | 微信/支付宝/抖音内搜索与分享 | 链接、二维码、广告落地 |
| 能力边界 | 设备、推送、离线、后台能力完整 | 部分原生能力，受平台规则限制 | 能力最有限 |
| 留存 | 最强，可推送和桌面留存 | 中等，依赖平台入口 | 最弱 |
| 适合 | 高频、复杂交互、软硬件结合 | 低频服务、门店、预约、轻交易 | 活动、表单、内容展示 |
例如：小程序负责获客和轻交易，APP 服务高频用户，H5 承接广告落地页，三端共用一套后端和业务数据。关键是 API 和数据模型先设计好，避免每端各写一套逻辑。
以上为常见项目经验总结，具体选型需结合用户频次、功能边界、预算和运营方式评估。
可以，而且常见。先用小程序验证需求和获客路径，再把验证过的核心功能迁移到 APP。前提是后端接口和数据结构设计得足够通用，避免小程序逻辑写死。我们通常建议一开始就把 API 层独立出来。
取决于使用频次和能力需求。低频服务、预约、门店、轻交易，小程序足够；高频使用、离线、复杂推送、蓝牙/定位/音视频等深度能力，APP 更合适。不要为了“有个 APP”而做 APP。
H5 是网页，任何浏览器都能打开，分发和更新最灵活；小程序运行在平台内，能调用部分原生能力，入口和支付体验更顺，但受平台规则限制。活动页、表单用 H5 更轻，长期服务和交易更适合小程序。