上周和一个做SaaS的朋友吃饭，他吐槽说团队花了三个月重构的桌面端，在客户的老款iPad上直接崩了。"我们以为响应式布局就够了，"他苦笑，"结果那台设备的Safari版本比我们测试的低了整整三代。"
这不是个例。用户现在 expect 同一套功能在手机、平板、电脑甚至电视上无缝运行，但背后的技术债务只有开发者自己知道。David Ohnstad 在复盘多个跨平台项目后，把最常见的坑整理成了这份清单。
1. 技术栈选型没有银弹
原生开发性能最好，但 iOS 和 Android 两套代码库意味着双倍人力。React Native、Flutter 这些跨端框架能省时间，却总在某些机型上掉帧，或者调用不了最新的系统 API。Ohnstad 的建议很务实：先想清楚你的核心场景是什么。如果重度依赖摄像头、蓝牙这类硬件能力，别为了省成本硬上跨端方案。
2. 屏幕适配不是"等比缩放"那么简单
桌面端的大屏布局直接塞到手机上，按钮可能小到戳不中。反过来，移动端的上滑手势在电视遥控器上完全失效。真正的响应式设计需要为不同输入方式（触控、鼠标、遥控器方向键）分别设计交互逻辑，而不是只改 CSS 的断点。
3. 浏览器兼容性仍是噩梦
Chrome 和 Safari 对同一个 CSS 属性的解析可能差出几个像素，更别提前端框架依赖的 JavaScript 新特性。Ohnstad 提到一个细节：他们曾发现某款国产安卓机的内置浏览器，对 WebSocket 的支持有 500ms 的延迟，直接导致实时协作功能不可用。
4. 平台限制比你想象的更死
iOS 的后台任务限制、Android 的权限动态申请、Web 端的本地存储容量上限——每个平台都有自己的"家规"。有些限制写在文档里，更多藏在 Stack Overflow 的冷门帖子里。提前做技术预研，比上线后救火便宜十倍。
5. 测试矩阵爆炸是常态
理论上你要测：iOS 最新版 + 前两版、Android 主流厂商的定制系统、Chrome/Firefox/Safari/Edge 的多个版本、不同分辨率组合。Ohnstad 的妥协方案是——用自动化测试覆盖核心路径，人工测试聚焦高频设备和"客户现场那台机子"。
6. 安全和合规要逐个平台过
GDPR 的数据存储要求、App Store 的隐私标签、Google Play 的权限声明格式——合规不是一次性工作，每个平台的审核规则都在变。Ohnstad 建议把合规检查写进 CI/CD 流程，而不是发版前才想起来补材料。
7. 性能优化没有终点
跨端框架的抽象层本身就有开销。Flutter 的渲染管线、React Native 的 Bridge 通信、Web 端的虚拟 DOM——这些"黑盒"在低端设备上可能成为瓶颈。Ohnstad 的经验是：保留 20% 的性能冗余，因为明年客户的设备不会变快，你的功能只会更复杂。
8. 团队结构决定技术上限
最理想的配置是"平台专家 + 跨端通才"的组合，但现实往往是几个人扛所有。Ohnstad 观察到，很多团队的问题不是技术选错了，而是没人真正懂某个平台的底层机制，遇到 bug 只能换框架碰运气。
跨平台开发的本质，是在"一致性"和"平台特性"之间走钢丝。没有完美的方案，只有清晰的取舍。Ohnstad 的总结很直接：先保证核心体验不崩，再谈漂亮话。
热门跟贴