H5与原生App选型
H5 与原生 App 主题中心
从架构选型到上架维护，判断团队真正能承接的交付方案
本栏目面向需要在 H5、套壳方案与原生 App 之间做决策的产品负责人、技术团队和项目管理者，按“能力边界、成本周期、版本治理、上架合规”梳理关键问题。这里不以单次开发报价判断方案优劣，而是结合业务能力、团队配置、发布流程和长期维护成本，帮助团队选择能够持续交付的多端架构。
架构选型：明确 H5 与原生能力边界
先确认推送、后台任务、设备能力、性能体验和应用商店分发是否属于核心需求，再决定继续使用 H5、采用混合方案或建设原生双端。
成本与周期：计算完整交付链路
原生开发成本不仅来自首版编码，还包括双端测试、设备兼容、证书账号、上架沟通和后续迭代。项目排期也应覆盖需求冻结、联调、审核与返工。
版本治理：评估团队的长期承接能力
架构选择最终会转化为持续维护责任。团队需要明确多端版本同步、灰度发布、兼容测试、紧急回滚和人员交接机制，避免上线后无人稳定维护。
上架与审核：提前处理平台规则和返工风险
应用商店审核不是发布前的最后一步，而应在产品设计阶段纳入账号主体、隐私权限、支付规则、功能完整性和素材一致性检查，并为被拒后的修正预留时间。
常见问题
什么情况下不应继续用 H5 或简单套壳方案？
当核心流程持续依赖系统级推送、后台任务、硬件能力、复杂动画或稳定的高性能交互，并且这些能力直接影响业务结果时，应重新评估原生或混合架构。
原生 App 上线后，为什么维护成本仍然很高？
双端系统和设备持续更新，业务版本还涉及兼容测试、商店审核、证书管理、灰度发布与紧急修复。首版上线只完成了交付起点，并未结束维护责任。
有外包团队是否就不需要内部版本治理能力？
不是。需求优先级、验收标准、发布权限、数据与账号归属、故障决策和供应商退出仍需由内部负责，否则容易形成交付依赖和版本失控。
