海外产品开发经验分享

最近这个 Claude Code 非常好用,很多人都有机会去开发自己的产品(我自己在写代码之外的一些用法整理在 我的 Claude Code 实践 里)。我也开发过一些各种各样的东西,想分享一下自己常用的一个技术栈以及涉及到的一些 SaaS 平台,给大家一些参考。

静态网站

这里的静态网站(Static Website)是指纯粹将网页挂在网上,而不包含后端数据库等功能的展示性页面。这种情况在落地页(Landing Page)或个人博客中非常常见,也是需求最简单、几乎可以零成本实现的方式。

技术栈

我个人比较喜欢使用 Next.js 和 Astro 的生态,开发起来相对简单,内容站用 Astro,交互复杂一点的用 Next.js。两者都是开源框架,免费使用。

网站部署平台

常用的平台包括 Vercel 和 Cloudflare Pages。

  • 费用:对于早期的个人项目,这些平台几乎是完全免费的。
    • Vercel:Hobby 免费套餐提供每月 100 万次函数调用、约 4 CPU-小时计算(仅限个人非商业用途)。
    • Cloudflare Pages:免费套餐每月 500 次构建,但带宽和请求数不限量。
  • 备案:无需走国内的阿里云备案等繁琐流程。
  • 访问速度:Cloudflare 的 CDN 非常强大,即便不备案,国内用户通常也能正常访问。
  • 域名:这两个平台都支持自定义域名,且该功能完全免费。

域名购买

域名建议去 GoDaddy 或 Namecheap 购买,这两个是目前使用较多的平台。现在 Cloudflare Registrar 也可以买域名了,它最大的特点是按成本价(注册局批发价 + ICANN 约 $0.18 的费用)售卖、不加价、续费也不涨价,如果域名本来就托管在 Cloudflare,会很省心。

流量分析

Google Analytics

推荐使用 Google Analytics(GA4 标准版对绝大多数网站完全免费)。通过它你可以清晰地看到流量来源及其分布情况,比如哪个国家或地区的人访问了你的哪个页面,其分析功能非常强大。

Google Analytics
Google Analytics 可以清晰看到流量来源及其地理分布。

UTM 标签

如果你在多个渠道做推广(比如发推、投广告、在不同社区分享),想知道每个渠道分别带来了多少流量,就需要用到 UTM 标签。它的原理很简单,就是在链接后面拼一串参数,Google Analytics 识别到之后就能帮你把来源区分开。

常用的几个参数:

  • utm_source:流量来源,比如 twitter、reddit、newsletter。
  • utm_medium:媒介类型,比如 social(社交)、cpc(付费点击)、email。
  • utm_campaign:活动名称,比如某次具体的推广 launch_2026。

拼出来的链接大概长这样:

https://yoursite.com/?utm_source=twitter&utm_medium=social&utm_campaign=launch_2026

把这个带参数的链接发到对应渠道,之后就能在 Google Analytics 里按来源/媒介/活动维度看各个渠道的流量和转化效果,判断哪个渠道更值得投入。手动拼参数容易出错,可以用 Google 官方的 Campaign URL Builder 来生成。UTM 五个参数的完整含义、命名规范以及十几个真实案例,我在 使用 UTM 标签来分析流量来源 里专门写过,想深入的可以看那篇。

多媒体存储(图床)

如果网站的图片或视频较多,直接打包到项目里会导致体积过大,也不利于加载。这时候应该把多媒体文件单独放到对象存储里,再通过 CDN 分发。这里分两层来说:底层的文件存储,和上层的图片处理。

对象存储:R2

底层存储我推荐 Cloudflare 的 R2,它就是用来存放原始文件的地方:

  • 兼容 S3 协议:现有的 S3 SDK、工具基本可以无缝迁移过来,上手没有额外成本。
  • 不收出口流量费:这是它相比 AWS S3 最大的优势,egress(对外流量)完全免费,做图床/CDN 这种读多的场景特别划算。
  • 免费额度够用:每月 10GB 存储、100 万次 Class A 写操作、1000 万次 Class B 读操作,个人项目起步基本是零成本。
  • 可绑定自定义域名:能用自己的域名对外提供文件访问,读写速度也很快。

图片处理与分发:Images

光有存储还不够,前端在不同位置(缩略图、列表、详情页、Retina 屏)往往需要不同尺寸、不同格式的图片。如果都靠自己提前生成、再一份份存起来,既麻烦又占空间。Cloudflare 的 Images 就是来解决这件事的,核心能力是图片变换(transform):

  • 实时变换:你只存一张原图,通过在 URL 上加参数就能实时生成不同版本,比如调整宽高(width/height)、裁剪方式(fit/crop)、压缩质量(quality)等,结果会被缓存到 CDN 边缘节点,后续访问直接命中缓存。
  • 自动选格式:可以根据访问者浏览器的支持情况,自动转成 WebP / AVIF 等更省体积的现代格式,能明显减小图片大小、加快加载。
  • 可处理 R2 或远程图片:变换不要求图片一定托管在 Images 上,存在 R2 里、甚至别的远程地址的图片,都可以直接走 Images 来变换和分发。
  • 计费方式:按「变换次数 + 分发量」计费,远程图片变换每月有 5,000 次的免费额度,起步阶段够用。

举个具体例子,假设你有一张原图:

https://img.yoursite.com/photos/cat.jpg

通过 Cloudflare 的变换 URL(格式是 /cdn-cgi/image/<参数>/<原图地址>),就能用不同链接拿到不同版本,而原图始终只存一份:

# 列表用的 200px 缩略图,质量压到 75
https://yoursite.com/cdn-cgi/image/width=200,quality=75/https://img.yoursite.com/photos/cat.jpg

# 详情页用的 800px 大图,自动转成更省体积的格式(webp/avif)
https://yoursite.com/cdn-cgi/image/width=800,format=auto/https://img.yoursite.com/photos/cat.jpg

# 固定 400x400 正方形头像,裁剪填满不变形
https://yoursite.com/cdn-cgi/image/width=400,height=400,fit=cover/https://img.yoursite.com/photos/cat.jpg

可以看到,你只要改 URL 里的参数(width、height、quality、fit、format 等),就能即时得到对应尺寸/格式的图片,第一次访问后结果会缓存到 CDN,后续访问直接命中。前端只需要按场景拼好链接即可,完全不用提前生成和管理一堆图片文件。

简单说就是:R2 负责把原图存好,Images 负责把图片按需变换、压缩、分发出去,两者搭配就是一套完整、便宜的图床方案。

SEO 优化

如果写博客,尽量使用 Astro 构建静态网站,因为它对 SEO 非常友好(静态页面、加载快、对搜索引擎抓取也友好)。SEO 这块网上有很多成熟的课程,这里我把自己常做的事情分成三块:技术手段、外链、相关工具。

需要先说明的是,最核心的还是内容本身。你只需要负责持续产出高质量内容,搜索引擎会自动来抓取,只要内容扎实,被收录和检索到的几率就很大。下面这些都是在内容之上的”配套工作”。

技术手段

这一块大多是一次性的固定工作,配好之后基本不用再管(Claude Code 就能搞定):

  • 梳理网站结构,编写 robots.txt 和 sitemap(站点地图),让搜索引擎知道哪些页面能抓、站点都有哪些页面。
  • 将站点提交到 Google Search Console,在这里提交 sitemap、查看收录情况和搜索关键词表现。
  • 每个页面配好独立的 title、meta description,以及 Open Graph / Twitter Card 标签(决定链接分享到 X、Slack 等平台时的预览标题和大图)。
  • 文章页加上 Schema.org 的结构化数据(JSON-LD),有机会在搜索结果里拿到富摘要(FAQ、星级等),点击率会更高。
  • 如果做多语言/多地区,记得配 hreflang 标签,这对海外站点是刚需。

其中第 3、4 条落到页面 <head> 里大概长这样,基本是每个页面都要配的一套固定模板(用 Astro 的话直接抽成一个组件,传 props 就行):

<!-- 基础 SEO + 社交分享预览 -->
<title>文章标题 - 站点名</title>
<meta name="description" content="120 字左右的页面摘要" />
<link rel="canonical" href="https://yoursite.com/blog/my-post/" />
<meta property="og:title" content="文章标题" />
<meta property="og:description" content="页面摘要" />
<meta property="og:image" content="https://yoursite.com/og/my-post.png" />
<meta name="twitter:card" content="summary_large_image" />

<!-- 文章页的 JSON-LD 结构化数据 -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "文章标题",
  "datePublished": "2026-06-09",
  "author": { "@type": "Person", "name": "你的名字" }
}
</script>

配完用 Google 的 Rich Results Test 验一下结构化数据能不能被正确识别,再去 Search Console 提交 sitemap 等收录就行。

外链

外链(backlinks,即别的网站链接到你)是新站排名里最难、但也最关键的因素。光有好内容还不够,还需要有人链向你,搜索引擎才会认为你的站点有权重。起步阶段可以做的:

  • 把产品/博客提交到相关的目录站、导航站、Product Hunt 之类的平台。
  • 在相关社区(Reddit、Hacker News、知乎、垂直论坛等)做有价值的分享,自然带上链接。
  • 写一些别人愿意主动引用的内容(教程、数据、工具),这是最健康的外链来源。

相关工具

做关键词研究和竞品分析时,常用的是 Ahrefs 和 Semrush,可以看关键词的搜索量、竞争度,以及竞品都在哪些词上排名——决定”写什么”的时候很有用。

Semrush
Semrush 可以看关键词搜索量、竞争度以及竞品的排名情况。

这两个工具官方订阅都比较贵(动辄上百美元/月)。如果只是个人项目,淘宝上有不少合租 / 镜像账号,价格便宜很多,按需买几天或合租一个月都行,起步阶段够用了。

另外 Google 自带的 Keyword Planner(关键词规划师)是免费的,虽然数据精度不如前两者,但起步先用它也完全可以。

完整前后端应用

带有完整前后端的网站,一般来说在 SaaS 平台中比较常用。它与前面提到的静态网站最大的不同在于,它有一套完整的后端系统,包括后台服务器、数据库等,为前端提供数据服务。

这种类型的内容更多一些,前端部分可以参考 静态网站 章节,后端方面大概可以分为两种技术路线:

Serverless(无服务器)路线

这种模式下没有持续运行的服务器一直挂在后台。每当前端有请求过来时,系统会临时启动一个服务器完成工作,任务结束后立即关闭。

语言上用 TypeScript 最顺手——前端本来就是 TS,后端也写 TS 的话整套技术栈统一,配合 Vercel 还能前后端一把梭、一起部署,省去来回切语言的成本。

  • 优点:比较省钱,完全按照使用量付费。没有请求时不会产生费用。
  • 缺点:不支持后台常驻任务(例如想启动一个线程一直做某件事)。如果硬要实现,可以考虑通过 Cron job 进行周期性调度。
  • 常用平台:
    • Cloudflare Workers:免费版每天 10 万次请求,每次请求 CPU 上限 10ms。
    • Vercel 的后端:底层走的是 AWS Lambda。
    • AWS 原生的 Lambda:永久免费额度每月 100 万次请求 + 40 万 GB-秒计算,不过期。

服务器路线

这是比较常用的一种方式,通常是打一个 Docker 镜像并将其作为一个常驻服务运行。

语言上我一般用 Golang:编译出来就是一个静态二进制,打 Docker 镜像很轻量,性能和并发能力也强,跑常驻服务非常合适。

  • 自建服务器:直接在网上找服务器挂载 Docker 镜像。
    • 优点:花钱最省,胜在便宜可控。
    • 缺点:运维最麻烦,需要自己操心反向代理、扩缩容等琐事。
  • Google Cloud Run:你只需要在 GitHub 上写好 Dockerfile,每次代码更新它都会自动帮你更新镜像。Cloud Run 支持按次收费(运行完销毁)和常驻后台运行两种模式。
    • 免费额度:每月约 200 万次请求、18 万 vCPU-秒、36 万 GiB-秒(限指定区域),下面的费用都是扣掉免费额度之后的。
    • 按次(请求期间才分配 CPU):vCPU 约 $0.000024/vCPU-秒、内存约 $0.0000025/GiB-秒,再加每百万次请求 $0.40。没流量时缩容到零、完全不计费,适合低频或流量波动的场景。
    • 常驻(实例一直分配 CPU):单价更低(vCPU 约 $0.000018/vCPU-秒、内存约 $0.0000020/GiB-秒)且不收请求费,但按实例运行的总时长计费——一个 1 vCPU / 512MB 的实例 7×24 跑满一个月,大概 $45~50 的量级。适合需要常驻、不能接受冷启动的服务。
  • fly.io:适合刚起步的小应用。它能自动处理扩缩容,并与 GitHub 无缝连接形成流水线,还自带 Grafana 看板,监控起来非常方便。
    • 费用:现在已经取消了免费套餐,改为纯按量付费,小应用实际最低大约 $5/月起。
  • 其他平台:AWS 的 EKS 等产品也可以尝试。
    • 费用:控制平面按 $0.10/小时计费(约 $73/月),节点另算。

总的来说,这两条路线的主要差别在于:一个是 Serverless,一个是常驻的服务器。

需要补充一句:AWS、GCP、Azure 这些云厂商对早期项目和 startup 都有数量可观的 credit「羊毛」可薅(动辄几千到几万美元),很多还不需要 VC 背书就能直接申请。怎么薅、哪些档位零门槛,我在 startup 的相关福利 里专门梳理过,起步阶段能省下不少真金白银。

接口规范

只要是前后端分离,接口怎么对齐就是个绕不开的问题——最烦的就是那种前后端字段对不上、类型不一致导致的低级 bug。怎么解决,要分两种情况看:

如果是 TS 一把梭,其实根本不需要 OpenAPI。前后端都是 TypeScript,直接把请求/响应的类型定义放进一个共享包里(monorepo 里两边 import 同一份 types),共用一套类型,改一处两边一起变,编译期就能发现对不上的地方。这种情况再套一层 OpenAPI 反而是多余的。

如果后端是 Golang(或其他非 TS 语言),前后端语言不同、没法直接共享类型,这时候才需要用 OpenAPI(以前叫 Swagger)当「契约」:用一份描述文件把接口的路径、参数、请求/响应结构都定义清楚,前后端都照它来,就不会跑偏。

我自己的实践是这么一条链路:

  • 后端用 Huma 这个 Go 框架写接口,它能直接从 Go 代码生成 openapi.json——不用单独手写、手维护那份 spec,接口改了重新跑一下就同步了。
  • 前端再用 openapi-typescript 把这份 openapi.json 转成 TypeScript 类型,配合它的 openapi-fetch 直接得到一个类型安全的请求客户端。

后端这边用 Huma 写接口大概是这个样子——入参/出参都是普通的 Go struct,字段约束、示例直接用 struct tag 标注,Huma 会据此自动生成 OpenAPI,并把 openapi.json 挂在固定路由上:

package main

import (
	"context"
	"net/http"

	"github.com/danielgtaylor/huma/v2"
	"github.com/danielgtaylor/huma/v2/adapters/humago"
)

// 入参:路径参数 name,带上校验和示例,这些都会进 OpenAPI
type GreetingInput struct {
	Name string `path:"name" maxLength:"30" example:"world"`
}

// 出参:HTTP body 包在 Body 字段里
type GreetingOutput struct {
	Body struct {
		Message string `json:"message" example:"Hello, world!"`
	}
}

func main() {
	mux := http.NewServeMux()
	api := humago.New(mux, huma.DefaultConfig("My API", "1.0.0"))

	// 注册一个 GET 接口,handler 是强类型的:入参出参都不用手动解析
	huma.Get(api, "/greeting/{name}", func(ctx context.Context, in *GreetingInput) (*GreetingOutput, error) {
		resp := &GreetingOutput{}
		resp.Body.Message = "Hello, " + in.Name + "!"
		return resp, nil
	})

	// 启动后:openapi.json 自动挂在 /openapi.json,交互式文档在 /docs
	http.ListenAndServe(":8888", mux)
}

前端这一步基本就两行,接口改了重跑一次即可:

# 把后端导出的 openapi.json 生成 TS 类型
npx openapi-typescript ./openapi.json -o ./src/api/schema.d.ts

# 之后业务代码里用 openapi-fetch,路径、参数、返回值全程类型安全
# import createClient from "openapi-fetch";
# import type { paths } from "./api/schema";
# const api = createClient<paths>({ baseUrl: "https://api.yoursite.com" });
# const { data, error } = await api.GET("/users/{id}", { params: { path: { id } } });

Huma 那边则是在服务启动时就把 openapi.json 挂在一个固定路由上(或一条命令导出),前端 CI 拉这份文件重新生成即可。整条链路下来(Go 代码 → openapi.json → 前端类型安全客户端),后端一改接口,前端重新生成一遍,所有受影响的调用在编译期就会报错,基本能把前后端对接的 bug 消灭掉。顺带还白送一份接口文档和在线调试页面,联调很省事。

如果后端是别的语言、或者要生成的不止 TS 客户端,可以换成更通用的 openapi-generator,它支持几十种语言,前端 SDK、后端骨架都能生成。

数据库与用户管理

后端基本离不开数据库,很多场景还会配套一套用户鉴权。这两块经常放在一起考虑,下面分成数据库和身份验证两部分。

数据库

  • Supabase:基于 PostgreSQL,除了数据库本身还打包了一整套后端能力(鉴权、存储等),上手很快,是个人项目起步的热门选择。
    • 费用:免费额度够个人项目起步——数据库 500MB、文件存储 1GB、每月 5 万月活跃用户(MAU)的鉴权额度。
  • Neon:serverless 的 PostgreSQL 数据库,按用量计费、可自动休眠。
    • 费用:免费版每月 100 计算小时、约 5GB 存储,并强制 scale-to-zero。
  • AWS 和 Google Cloud:如果你追求更正规、更稳健的方案,它们的托管 PostgreSQL(AWS 的 RDS、GCP 的 Cloud SQL)会更稳。和前面那些”免费起步”的产品不同,这类是按实例时长付费的——小规格入门档大概每月 $10~40 的量级,跑生产更稳但起步就要花钱。

身份验证(Authentication)

鉴权既可以用数据库自带的方案,也可以交给专门的服务:

  • Supabase Auth:如果你已经用了 Supabase,它自带身份验证功能,可以把整个鉴权逻辑直接托管在上面,帮你管理用户和登录情况,不用额外接别的服务,非常方便。
    • 费用:跟着 Supabase 项目走,免费版每月 5 万月活跃用户(MAU);Pro 计划($25/月起)含 10 万 MAU,超出按约 $0.00325/MAU 计费。
  • Clerk:专门做鉴权的公司,除了后端管理,甚至会提供现成的前端登录页面,直接用就行。
    • 费用:免费额度是每个应用每月 5 万月活跃用户(MAU/MRU),超出后 Pro 计划从 $25/月起按量计费。

缓存服务

后端除了常用的 PostgreSQL 数据库,通常还会用到 Redis 之类的缓存。

  • 云厂商提供:各大云服务商都有托管 Redis(AWS 的 ElastiCache、GCP 的 Memorystore),按节点规格/容量时长计费,小规格大概每月 $10~35 的量级。你也可以买台服务器自己搭建,更省钱但要自己运维。
  • Upstash:这是一个现成的供应商,提供开箱即用的 Redis。它还会提供监控页面,方便你查看读写情况。它相当于把 Redis 封装好了,用起来更省心。
    • 费用:有免费额度,每月 50 万次命令、256MB 数据、每月前 200GB 带宽。

支付与订阅逻辑

如果涉及到收费逻辑,一般首选 Stripe。

  • 优势:他们的 SDK 设计得非常漂亮,无论是管理订阅用户还是处理支付逻辑都很好用。
  • 服务:Stripe 的整体服务质量很高,是一个非常适合程序员的收款平台,口碑一直不错。
  • 费率:没有开通费和月费,按笔抽成,美国本土卡为 2.9% + $0.30 每笔,国际卡会再加跨境等费用。

AI 服务

现在做应用基本绕不开 AI 能力。这块我按任务类型整理一下常用的服务。下面的价格都是 2026 年 6 月前后采集的,AI 模型迭代很快,具体请以官网为准。

文本(LLM)

按任务复杂度和诉求来选:

  • 简单任务(翻译、总结、分类等):
    • 追求便宜:DeepSeek 等国产模型,性价比极高、中文也好。价格大概在每百万 token 输入 $0.14 / 输出 $0.28 这个量级,还带缓存命中价更低。
    • 追求速度:Groq,自研 LPU 推理芯片,速度极快(开源模型常能跑到 500+ tokens/秒),价格也便宜。注意它只托管开源模型(Llama、Qwen 等)。
  • 复杂任务(如 Agent、编码):首选 Claude 和 GPT。Claude 在 agent、工具调用和编码上口碑最好(Claude Code 就是基于它);两家旗舰价格都在每百万 token 输入约 $5 / 输出 $25~$30 这个档。
  • 想统一接口:用 OpenRouter。一个 API key(OpenAI 兼容接口)就能调各家 300+ 模型,按原价透传、不在单价上加价(只在充值时收一次平台费),方便比价、切换和故障兜底。

Embedding

做向量检索(RAG、语义搜索)需要 embedding,常用 OpenAI 的 embedding 模型:

  • text-embedding-3-small:$0.02/百万 token,默认 1536 维,性价比最高,一般首选。
  • text-embedding-3-large:$0.13/百万 token,默认 3072 维,精度更高,适合对检索质量要求高的场景。
  • 两者都支持用 dimensions 参数降维,省存储、加快检索。旧的 ada-002 效果和性价比都不如 3-small,新项目不用了。

图像生成

  • Nano Banana Pro(Google,基于 Gemini 3 Pro,2025 年 11 月发布,初代 Nano Banana 是 Gemini 2.5 Flash Image):擅长多角色/物体一致性、影棚级光影构图、图内文字渲染清晰,可上采样到 4K,约 $0.13/张(1K/2K)、4K 约 $0.24/张。
  • GPT Image 2(OpenAI,模型 gpt-image-2,2026 年 4 月发布):把推理能力引入图像生成的”Agentic”模型,生成前会先规划画面、还能联网做事实核验,多语言文字渲染和复杂版式(信息图、多格漫画)很强,原生支持到 2K。按 token 计费,换算单张约 $0.006(低质)到 $0.21(高质)。还有更便宜的 GPT Image 1 Mini 可选。

视频生成

  • Veo 3.1(Google,当前最新,没有 Veo 4):高质量文生/图生视频,原生同步生成音频,支持 1080p/4K。按秒计费跨度较大,从最经济的 Veo 3.1 Lite 约 $0.05/秒,到标准/Quality 档(4K + 音频可达 $0.6/秒)。
  • Seedance 2.0(字节跳动,2026 年 2 月发布、4 月开放 API):统一多模态架构,原生音画同步、支持多镜头叙事,单次请求可混合输入多张图/视频/音频,效果在文生/图生视频评测里居前列。约 $0.2–0.3/秒(720p),快速档更便宜。

语音

  • ElevenLabs:业界领先的 TTS 和语音克隆,自然度很高,支持多语言、配音(dubbing)和对话式 AI。免费档每月约 1 万 credits(无商用授权),付费从 $5/月(Starter)起。

其他简单处理

图像识别、抠图、风格化这类”拿来即用”的任务,直接去 Replicate 上找现成模型:一行 API 调用、按运行时间付费、上手很快(一张图通常几厘到几分钱),缺点是私有模型有冷启动延迟。

自己部署模型

如果要部署自己的模型,主要看两种取向:

  • 稳定、网速快、要正规:用 AWS 或 Google Cloud(GCP)。两家都是企业级,稳定性、合规和网络都是顶配,可以调托管大模型(AWS Bedrock、GCP Vertex AI 按 token 付费),也可以开 GPU 实例自己跑。缺点是贵、运维门槛高——单卡 GPU 大致在每小时几美元到十几美元的量级(A100 一档约 $3/小时、H100 约 $10/小时起)。
  • 想要 serverless 的按量计费:走 RunPod 或 Replicate。计费逻辑是按每次请求实际占用 GPU 的时长(精确到秒)来收——请求处理完就停止计费,没请求时缩容到零、完全不花钱,特别适合流量波动或低频调用的场景。代价是有冷启动延迟(第一个请求进来要先把模型加载起来)。

移动端应用

移动端基本就是手机上的各种 App,大概可以分为两类:一类是苹果生态,另一类是谷歌(Google)生态。

平台与分发

分发渠道就这两个,各自需要先注册对应的开发者账号才能上架:

账号注册下来后,就可以在对应平台上架、分发自己的应用了。

技术栈

移动端我的建议很简单:直接上 React Native + Expo 这套组合就行,不用在选型上纠结。

React Native 是底层基础,它让你用 React 的方式同时开发 iOS 和安卓——主要写 React 语法,不用去碰原生的 Swift 或 Kotlin,上手成本很低。很多大厂 App 都在用,比较有代表性的有 Shopify(移动 App 已全面迁移到 RN)、Discord(iOS/Android 主体都用 RN)、Coinbase(2021 年起整体从原生切到 RN)。

Expo 则是构建在 React Native 之上的框架和工具链:你写的还是 RN,但开发、构建、分发这些环节都被它打包好了,开箱自带路由和各种调用原生能力的 SDK,还能用它的云服务(EAS)直接打包、上传分发,省去自己折腾原生工程的麻烦。费用上也很友好:RN 和 Expo 本身都开源免费,EAS 云构建每月还有免费额度(各 15 次 Android / iOS 构建),起步阶段够用。

日常会用到的命令也不多,从建项目到上架基本就这几条:

# 建项目 + 本地开发(扫码在真机 Expo Go 里实时预览)
npx create-expo-app@latest myapp
npx expo start

# 首次用 EAS 前登录并初始化配置(生成 eas.json)
npm i -g eas-cli
eas login
eas build:configure

# 云端打包:--profile 对应 eas.json 里的构建档(development / preview / production)
eas build --platform ios --profile production
eas build --platform android --profile production
eas build --platform all --profile production   # 两端一起打

# 打包完直接提交到 App Store Connect / Google Play
eas submit --platform ios --latest
eas submit --platform android --latest

# 发布后改了 JS/资源,走 OTA 热更新,不用重新过商店审核
eas update --branch production --message "fix: 修一个文案"

其中 eas update 是 Expo 比较香的一点:只要改动在 JS / 资源层面(没动原生代码),可以直接 OTA 推给已安装用户,绕过商店审核;只有动了原生依赖时才需要重新 eas build 走一次完整发布。

后端与付费逻辑

  • 后端逻辑:跟 完整前后端应用 里讲的几乎一样,因为都是做同样的 API。
  • 付费逻辑:推荐使用 RevenueCat。它会帮你对接 Google Play 和 App Store 的付费能力,用起来有点类似于网页端的 Stripe。
    • 费用:月追踪收入(MTR)低于 $2,500 时完全免费,超出部分按所追踪收入的 1% 收费,对早期项目很友好。

移动端生态的好处在于苹果和谷歌的能力确实很强大。他们能让你把应用同时上架到全世界上百个国家的应用商城,走一个统一的渠道。总的来说,在这两个生态里开发还是比较舒服的。

桌面端应用

桌面端现在基本就是 Windows 和 Mac 两个生态。Mac 上面的认证系统要更加严格一些,Windows 相对会比较松一点。

现在有很多可以跨平台的框架,用的比较多的可能就是 Electron 和 Tauri 这两个:

Electron

Electron 相当于给你套了一个 Chrome 引擎在里面。它的应用非常广泛,像 VS Code 以及 Claude 的桌面端都是用 Electron 写的。

  • 优点:非常成熟,生态完善,没有很多乱七八糟的坑;各平台都用同一个 Chromium,渲染行为一致,初次开发也比较容易上手,不容易踩坑。
  • 缺点:因为内置了一整个 Chrome 引擎,打包出来的文件比较大,内存占用也偏高。

Tauri

Tauri 用的是系统自带的 WebView(Windows 上是 WebView2、Mac 上是 WKWebView),界面还是写 React 那一套,外层的原生壳子用 Rust。日常开发你基本只写前端,只有需要做原生扩展时才会碰 Rust。

  • 优点:不打包 Chromium,安装包小、内存占用也低。
  • 缺点:各系统 WebView 内核不同,跨平台渲染容易出现差异,需要分别测试;生态和现成插件也不如 Electron 丰富。

两者目前都可以跨 Windows 和 Mac。如果是初次开发、求稳,选 Electron;如果在意安装包体积和内存占用,可以试试 Tauri。

  • 技术
  • 商业