PWA 和原生应用怎么选才不踩坑？
PWA 和原生应用没有绝对胜负，关键看你的产品最依赖什么。PWA 适合内容、电商、工具、活动页和需要快速试错的业务；原生应用适合高频使用、强交互、重性能、深度调用设备能力的业务。最容易踩坑的决策，是只看开发成本：PWA 省掉了双端开发和商店审核，但如果后期补相机、蓝牙、后台定位、复杂推送，省下的钱可能会在兼容性和体验上还回去。
先看能力边界，再看预算
PWA 的优势是分发轻、更新快、SEO 友好，一条 URL 就能触达用户。它可以离线缓存、添加到桌面、接收推送，并用一套 Web 技术覆盖多端。但它仍受浏览器和系统限制，尤其是 iOS 上的后台任务、推送能力、存储配额和安装引导都比原生更保守。
原生应用的优势是性能稳定、系统能力完整、交互细节可控。地图导航、实时音视频、图片视频编辑、运动健康、IoT 控制、金融安全这类产品，往往需要更深的系统集成。代价是研发、测试、审核、灰度和版本兼容都更重，功能发版不能像 Web 一样随时上线。
function chooseAppType(req) { if (req.needBackgroundLocation || req.needBluetooth) return 'native'; if (req.highPerformanceUI || req.appStoreBusiness) return 'native'; if (req.seoTraffic || req.fastIteration || req.lowBudget) return 'pwa'; return 'hybrid: PWA validate first, native for heavy users'; }
对比时别只看“能不能做”
很多能力 PWA 也能做一部分，例如摄像头、定位、离线缓存和通知，但“能调用 API”和“在所有目标设备上稳定好用”不是一回事。原生应用在权限说明、后台执行、系统通知样式和性能调优上更可控，适合关键链路很长的产品。PWA 更像轻装上阵，适合先把核心价值交付出去，再根据数据决定是否投入原生。预算有限时，PWA 是降低试错成本的好选择；需求已经验证且用户每天高频打开时，原生投入更容易回本。
追问
哪些业务优先选 PWA？
内容站、电商落地页、企业门户、轻量工具和 MVP 更适合先做 PWA。它们的核心诉求通常是“尽快被访问、尽快更新、尽量少安装阻力”，而不是榨干设备性能。取舍是你要接受浏览器能力边界，比如后台同步和推送在不同平台表现不完全一致。如果用户主要来自搜索、广告或分享链接，PWA 往往比先上应用商店更划算。
哪些业务不建议只做 PWA？
高性能游戏、短视频剪辑、实时导航、运动轨迹、蓝牙设备控制、银行支付类应用不建议只靠 PWA。不是 Web 完全做不了，而是稳定性、权限能力和后台可靠性很难达到原生水平。边界判断可以很简单：如果一个关键功能必须在锁屏、弱网、长时间后台或硬件高负载下稳定运行，原生胜率更高。否则上线后会变成“多数功能能用，关键时刻不好用”。
混合方案是不是折中就一定更好？
不一定。混合方案可以用 PWA 做获客和试用，用原生承载高频重功能，也可以用 Capacitor/Ionic 把 Web 能力包进壳里。问题是它会引入两套边界：Web 的兼容性和原生壳的发布复杂度都要维护。适合的场景是业务已经验证成立，但团队暂时不想完全重写；如果需求本来很简单，混合方案反而会把架构做重。
决策时最容易忽略什么？
最容易忽略的是用户获取渠道和更新节奏。靠搜索、社媒、广告投放转化的产品，PWA 的 URL 分发和 SEO 是实际优势；靠会员留存、高频打开、系统通知召回的产品，原生应用更容易建立习惯。还有一个踩坑点是“普通用户不一定知道如何安装 PWA”，所以不能把桌面安装率当成默认结果。上线前最好用真实设备验证安装提示、离线页、推送授权和首屏性能，而不是只在 Chrome DevTools 里看通过率。
用什么指标判断选型是否选对？
如果选 PWA，要重点看首屏加载、安装提示转化、离线访问成功率、搜索流量转化和更新触达率。如果选原生，要看商店下载转化、激活率、留存、崩溃率、推送召回和版本升级覆盖率。不要只用开发周期衡量，因为上线快但留不住用户，依然不是好选型。更靠谱的做法是先列出三条不可失败的业务链路，再判断哪个技术路线更能保护这些链路。
收束
如果产品还在验证阶段、主要靠链接传播、功能以浏览和轻交互为主，PWA 通常更合适。如果业务已经证明高频、强交互、深度依赖设备能力，原生应用更稳。介于两者之间时，可以先用 PWA 验证需求，再把最重的能力迁到原生或混合壳里，不必一开始就把选择做死。