作为全栈开发者，为什么看到 Shopify 回归原生，我依然选择 React Native
上周三下午，我在家改一个表单联动，飞书弹出客户发来的一条消息，附了篇 Shopify 工程博客的链接，后面跟一句："你们移动端是不是也要回原生了？"
我点开一看，标题起得一点余地都不留——《Native is now the future of mobile at Shopify》。
这事对我来说不算小事。我还是个在读学生，课余远程接项目养活自己，一条产品线的前端、移动端和服务端都压在我一个人身上，客户散在两个时区。我的移动端跑的就是 React Native，而 Shopify 过去六年是 RN 阵营最大的旗手——Shop app 从出生那天就跑在 RN 上，FlashList、React Native Skia 这些我天天在用的库，都是他们维护的。现在旗手宣布退役了，客户拿着新闻来问，很正常。
我把两篇原文读了两遍，又翻了一圈网上的解读。读得越多越觉得，大部分人把这事读歪了。
Shopify 说了什么，和大家都听成了什么
大家听到的版本是：跨平台框架输了，RN 要凉。
但 Shopify 原文里写得很明白：RN 没有变慢，没有失败，他们的 RN 应用性能一直不错。他们推翻的只是一个成本假设——过去"一个功能写两遍，就等于做两倍的工作"，现在 AI 编码代理可以拿着 iOS 版实现直接把 Android 版做出来，写两次的成本被摊薄了，所以当年选跨平台的理由跟着变薄了。
这个推理本身没毛病。但很多人没注意到结论成立需要什么条件。
那 12 周重写 Shop app 的背后，是他们自研的一整套东西：一个叫 Helix 的迁移系统，把每个屏幕切成小段，每段都要过测试、过视觉比对、过两轮对抗式 AI 代码审查，最后还要人签字；一个叫 Tardis 的调试工具，给 AI 提供运行时反馈；业务逻辑还专门改成了 headless 跑在桌面端，让 AI 能毫秒级验证。这些基建在文章里就几段话，实际是几千人公司的工程投入。
还有一句原话值得划出来："Native expertise remained essential"——AI 生成的代码可能功能都对，但藏着重复、架构漂移和性能问题，得靠懂平台的人来审。
我的团队里那个人是谁？是我自己。我一个人。
所以 Shopify 的结论翻译过来其实是：一个有几千工程师、有自研 AI 工具链、养着原生专家的公司，在 2026 年重新算了笔账，算出原生划算。我是三样都没有。这笔账照抄过来，抄错了对象。
一套 TypeScript，是我远程干活的全副家当
我的技术栈是 React + React Native + NestJS，一个 monorepo，一种语言贯穿 Web、移动端和服务端。
我这种远程干活的学生，对"沟通成本"四个字的体感和坐办公室的人不一样。甲方不在身边，问题不能凑过去问一句，课间十分钟回消息、图书馆里改代码是常态，一切都靠文档、消息和代码本身。这种时候，一套类型贯穿全栈的代码库就是最好的沟通工具——接口长什么样、字段是什么意思、哪些值是合法的，全写在类型里，不用开口问。
举个上礼拜的事。给系统加一个"任务提交"功能，我先在共享包里改类型定义和校验 schema，然后 NestJS 按新类型补接口，Web 端和 RN 端各自接上。整个过程里 AI 拿着同一份类型契约在三层之间干活，改服务端时它知道客户端长什么样。有一次它把一个字段的枚举用错了，TypeScript 直接报错，我还没跑代码问题就拦下来了。
要是移动端换成 Swift 和 Kotlin，这条类型链就在客户端断掉。AI 得在两套语言体系里各自理解业务，靠猜保持两边一致。Shopify 怎么解决这个问题的？共享规格文档、Review 关卡、对抗式审查——又是一套基建。他们管这叫"共享层从代码上移到流程"，说得好听，那套流程本身就是钱堆出来的。
我的方式粗糙但便宜：共享层就在代码里，编译器就是免费的审查员。
AI 对我来说不是效率工具，是队友
远程开发有个绕不开的处境：深夜和周末，没有能问的人。对学生来说这层更狠——身边本来就没有能请教的前辈，课堂上学不到移动端选型，实验室的师兄也未必碰过这些。
以前卡在一个问题上，只能发消息等对面睡醒。现在大部分问题，AI 当场就能陪我把方案过一遍，顺便把我不懂的 platform 细节讲明白。这不是"提效百分之多少"的事，是工作形态变了——我实际上有了一个不睡觉、不用约时间、随叫随到的结对搭档，兼一个随叫随到的导师。
而对远程开发者来说，还有一层：AI 最擅长的语言就是 TypeScript。语料最多，工具链最熟，类型系统最适合让它自我校验。我这一年让 AI 写 TS 的体验，明显好于让它碰其他语言。同样是"AI 时代重新选型"，我算出来的答案跟 Shopify 不一样，因为放大器套在两个不同的底子上。
有人会拿 Shopify 文章里"模拟器控制太慢，AI 改代码几秒、验证要几分钟"来说事。这话对了一半。我的日常开发里，大量工作根本不需要 AI 看 UI——接口、状态、表单、数据流，Metro 热更新加 Jest 反馈够快。真要看界面，截一张图丢进对话，现在的模型理解得比想象中好。RN 还有个小便宜：它本质是 React，我跟 AI 说"参考 Web 端那个页面"，它就能跨端复用结构和状态逻辑。原生那边没有现成的参照物可抄。
该认的账我也认
RN 的坑是真的，我不想装看不见。
平台新 API 的跟进永远慢半拍，灵动岛出来那会儿社区等可用方案等了好一阵。桥接层出 bug 的时候调试链路就是长，JS 和原生两边来回翻。复杂动画的上限，不写原生模块就是摸不到。这些我都在自己项目里撞过，不是看别人说的。
所以我的判断标准很简单：如果你的产品核心就是深度平台能力——重度相机、硬件集成、那种 POS 终端场景——Shopify 的选择对你就是对的，别犹豫。他们自己的迁移节奏也有点意思：Shop 和主应用先走，最吃硬件的 POS 排在后面。
但如果你的产品是内容型、交易型、表单型的——绝大多数产品都是——平台差异那点收益，换不来放弃整套 TS 飞轮的损失。尤其是学生和独立开发者，本就没有资源养原生专家、建工具链，"一套代码就是最低沟通成本"这件事，只会越来越值钱。
最后
2020 年选 RN 的人是为了省人力，2026 年还选 RN 的人，理由变了：为了把 AI 的杠杆放到最大。
客户后来又发了条消息，问我到底怎么想的。我把这段话发给了他。他的回复是一个"OK"表情，然后说：那你继续。
同一个事件，两种读法。Shopify 重新算了一笔账，我也算了，我们的数字不一样——他们的分母里有几千个工程师，我的分母里只有我，一个课余远程接活的学生，和我这个不用睡觉的搭档。
参考资料：Shopify Engineering 博客《Native is now the future of mobile at Shopify》《Migrating Shop app from React Native to native》，均发布于 2026 年 9 月 10 日。
