面试不是一次你必须把所有知识装进脑袋然后按题目吐出来的测试，而是为了对用人单位和候选人未来负责的一次面对面交流、互相试探的对话。特别是跨平台开发这种工作，面试官更想看到你能在多条技术路径之间做出合理选择、能把复杂限制转成可执行方案的人。你不用把自己当成答题机，把每个问题当成展示你思考过程的机会，这会比背书更有杀伤力。
心态准备好，想清楚你的定位是怎么样的
很多候选人把自己定位为“技术执行者”，只想着把某个功能做出来。在跨平台面试里，面试官更想找的是“能够独立提出解决方案的人”。这意味着你要把重点从纯实现细节搬到“为什么这么做、这方案能解决哪些业务问题、有哪些风险和权衡”。用一句话来记：别只告诉我你会用哪个API，告诉我为什么选它、选它的成本是什么，你会怎么验证效果。
我们举个简单的例子来说明，回答问题的时候可以这样开口：「我会先确认一下需求层面的优先项，是性能更重要还是时间上线更重要？在这一前提下我会选择X方案，因为……，如果条件是Y，我会改用Z」。这类开场会让面试官立刻知道你在用产品和业务的思维看技术，而不是机械地罗列API。
核心技术考察，要展现出你的深度与广度的平衡
面试常考两个维度，也就是你对主流框架的理解（深度）和你把这些框架应用到真实业务中的能力（广度）。当被问到“React Native、Flutter、uni-app怎么选？”时，别只念出优缺点表格，要做场景化判断。
如果你实在想不出好的回答方式，可以参考：先列评估维度——性能、开发效率、团队经验、生态成熟度、原生能力需求、上线成本与维护成本。接着带入场景：如果目标是短期验证、团队主要是Web前端，uni-app或React Native能快速产出；若追求原生级别动画和一致高帧率，Flutter会更合适；需要大量与现有原生模块集成或长生命周期维护时，倾向选择React Native或原生混合开发，并把原生桥设计成插件化。别忘了讲你对趋势的关注：比如Flutter在UI一致性上有优势，但原生生态和大型企业插件支持仍在追赶；React Native的TurboModules和Fabric会在性能上改进，但升级成本和原生版本兼容是现实问题。
对于跨平台开发来说，性能优化绝对是必考项，面试官会希望你能从“现象”跳到“本质”。常见的问题包括：界面掉帧、冷启动慢、内存泄漏、网络抖动导致渲染阻塞。
回答时用STAR模型把事情讲清楚：描述场景（S），你的目标（T），你采取的行动（A），以及产出（R）。比如某项目在Android上List滚动掉帧：现象是主线程卡顿，排查发现是JS线程大量同步计算导致UI线程等待。行动包括：把计算迁移到后台Worker/Isolate，减少跨桥通信次数，使用虚拟化列表和按需渲染；结果是平均帧时间从33ms降到12ms，滚动体验显著改善。把量化数据挂在结尾，会更具说服力。
跨平台的重要能力，架构设计与工程化能力
面试里很可能被问到混合开发如何处理原生交互。一个靠谱的回答包含三部分：边界划分、接口契约、回退方案。示例：需要摄像头高级功能时，我会定义一层原生模块抽象（接口契约），所有跨平台调用只能通过这层，模块内部再决定是直接用Native camera API还是走第三方库；并提供能力检测和降级策略（当某平台不支持某特性时，回退到最小可用版本）。强调可维护性很重要：把与平台相关的代码封装在清晰的模块里，写好文档和单元测试，避免业务逻辑散落在各个平台代码中。
工程化实践是考察重点之一。跨平台项目容易出现依赖地狱、版本不一致、构建时间长等问题。面试官想知道你有没有完整的流程意识：如何保证代码质量、如何自动化构建、怎样做发布与回滚。可以讲具体措施：统一代码规范并用Lint/Formatter强制执行；组件化把大应用拆成可独立发布的包；CI流水线自动化打包并跑单元测试、集成测试和E2E（比如Flutter的golden tests或React Native的Detox/E2E）；使用Fastlane来自动化签名和发布；上传符号表到崩溃平台等。说明你如何在团队推广这些实践会让回答更有分量。
面试官常常会让你深入讲一个过去实际参与过的项目，这里别把时间浪费在功能清单上，你的功能再多对面试官来说一点都不重要，记得把重点放在你做的关键技术决策、遇到的难题、取舍和最后的验证数据。选1到2个最能体现跨平台特点的案例准备好，把它们讲成故事。遇到失败不要回避，坦诚描述问题和你的复盘，会比装作完美更有人格魅力。
在考研个人协作能力时，不要刻意去掩盖过去曾发生过的团队冲突，沟通冲突几乎不可避免，被问到和原生团队意见不同怎么办时，你可以展示你的说服与同理能力的套路：先把对方的顾虑复述一遍，确认共同目标（例如稳定性或上线时间），提出可验证的折中方案（比如先做小规模Spike验证，再决定全面替换），并把技术决策写成文档和接口契约，给出时间表和回退计划。这种方法能把技术讨论从情绪化拉回到工程化。
跨平台领域的技术特点就是更新特别快，这对于企业来说就希望能找到善于不断学习提升自己的人。说出你具体的学习方法会比空泛的“我会持续学习”有用：比如每周花固定时间阅读官方Changelog、每月做一个小项目验证新特性、把遇到的问题写成博客或内部Wiki、参与开源或提交PR来加深理解。展示你有产出（博客、GitHub项目、开源贡献）能显著提升可信度。
所以遇到不会的问题不重要，重要的是你能够有自己的方式快速学习，诚实比瞎编重要。可以先把你已知的相关点说出来，再给出你会如何验证或补足知识的计划。设计题回答要有套路：先澄清需求和约束（Q&A），再给出多种解法（快速方案、稳妥方案、长期方案），最后说明权衡点和实现细节的落地步骤。
在最后的反问环节，不要聚焦在询问公司待遇和福利这类不重要的方向，而是需要在提问题中，透露出你所侧重的方向：团队当前最大的技术挑战是什么？公司对跨平台技术的长期规划如何？这个岗位在未来一年内能带来哪些成长机会？这些问题会让面试官觉得你在认真考虑双方的长远匹配，而不是只看眼前的薪水和福利。
另外几个容易犯的陷阱提醒你：不要把跨平台等同于“能省很多时间就行”，面试官会考你对维护成本、性能、平台一致性和长期可扩展性的理解；别在技术细节上夸大自己的角色，讲清楚你负责的范围更可信；避免只谈框架优点而忽视生态与运维成本。平时多做mock面试，把项目讲成故事，会让你在真实场景下更从容。
