APP 报价单上常有一行"技术路线"，写的是原生、混合或者 H5 封装。这三种东西的差别，不是"贵和便宜"的区别，而是你后面能不能改得动的区别。
我按实际做项目的经验，把三条路摊开说。
原生开发：两个团队，两套代码
原生就是用苹果自己的语言（Swift / Objective-C）写 iOS 端，用安卓的语言（Kotlin / Java）写安卓端。两套代码，各写一遍。
好处：性能最好，调用系统能力最顺，动画和交互最跟手，上架审核也最不容易被卡功能受限。
代价：工作量最大。同样的功能要写两遍，测试要测两遍，改一个逻辑要改两个地方。预算基本是其他路线的 1.6 到 2.5 倍。
什么时候值得：产品体验就是竞争力的时候。比如视频剪辑类、游戏化互动类、对流畅度极度敏感的 C 端产品，或者深度依赖系统能力（蓝牙、相机、传感器高频调用）的应用。
混合开发：一套代码，两个端跑
用 React Native、Flutter、uni-app 这类框架，写一套代码，编译出 iOS 和安卓两个包。业务页面用前端技术写，需要性能或系统能力的地方再写原生插件。
好处：一套代码管两端，开发速度明显快，改需求只改一处。对大多数业务型 APP（下单、打卡、审批、查询、内容浏览）来说，体验和原生几乎看不出差别。
代价：遇到框架没覆盖的系统能力，还是要写原生插件，这时就要求团队有原生能力；框架本身也有版本升级的问题，长期维护要看框架生态是否活跃。
什么时候合适：绝大多数企业内部应用和业务型 C 端应用。我们的判断线是——如果这个 APP 的卖点不是"极致流畅的动画"，混合开发通常就是性价比最高的选择。
H5 封装：套壳，前端页面装进 APP
本质上是一个浏览器壳子里跑网页。用户看到的界面全是 HTML 页面。
好处：最便宜，最快。因为网页本身还能一套代码同时给手机浏览器用。
代价：说重一点——体验的天花板很低。页面切换有延迟感，下拉刷新、手势返回、原生弹窗这些都不太对劲。更要命的是审核风险：苹果对"只是网页套壳"的 APP 一向不友好，被拒的理由通常是"内容与网页重复、缺乏原生功能"。而且用户能感觉出来这是网页，信任度会打折。
什么时候能接受：内部工具、给已经签约的客户用、或者短期活动类应用，不上架只做企业分发。对外正面推的产品，不建议走这条。
一张表看清差别
| | 原生 | 混合（RN/Flutter/uni-app） | H5 封装 |
|---|---|---|---|
| 代码量 | 两份 | 一份 | 一份（可复用网页） |
| 相对成本 | 1.6～2.5 | 1.0（基准） | 0.6～0.8 |
| 体验 | 最好 | 接近原生，复杂动画偏弱 | 明显有网页感 |
| 系统能力 | 无限制 | 大部分可，特殊项要写插件 | 弱，很多能力用不了 |
| 上架风险 | 低 | 低 | 高，容易被判套壳 |
| 改需求速度 | 慢（两处都改） | 快 | 快 |
| 长期维护 | 跟随系统版本适配 | 跟随框架版本 | 最轻，但体验债会累积 |
说三个实际做项目时的判断经验
第一，别为了省成本选 H5 封装，选了就得接受它长不大。 我们见过客户前期图便宜做了套壳版，一年后要做会员体系和推送，发现整个壳子得推倒重做，前面的钱基本白花。要省就省功能，别省技术路线。
第二，混合开发不是"低配版"。 很多客户的顾虑是"混合是不是不专业"。恰恰相反，Flutter 和 RN 已经是行业主流选择，Instagram、闲鱼这类高流量产品里都有混合技术的身影。判断标准是团队有没有能力处理原生插件，而不是框架本身行不行。
第三，技术路线要在报价前定，不能边做边改。 中途从 H5 换成混合，等于重做；从混合换成原生，等于重做两遍。这一项必须在需求阶段就写进方案，签进合同。
怎么问出服务商到底打算怎么做
三个问题，问完基本能判断：
- 1. "我这个 APP 用的是什么技术路线？为什么选它？" —— 答不出具体框架名的，大概率是套模板。
- 2. "我的某个功能（说出你最在意的那个）在这个路线上怎么实现？" —— 让他说具体实现方式，说不清的后面一定会返工。
- 3. "以后我要加一个你们框架没覆盖的功能，怎么办？" —— 答"加不了"的，说明团队没有原生能力，你以后就被拴住了。
第三问最关键。它测的不是现在，是两年后你还改不改得动。
选技术路线这事，我们给客户的原则一直很简单：先看你两年后要走到哪，再决定现在买哪条路。如果你已经把未来两三年的功能规划想清楚了，把清单发给我们，我们给你三条路线的实际工作量和成本对比——你自己选，我们不推销贵的那条。
本文为引潮网络原创内容，基于真实项目与本地报价经验撰写，转载请注明出处。
