如果你也是那种“上午改一行配置下午排队等 Xcode 上传凌晨还要盯 Google Play 审核”的人那这篇东西应该对胃口。我做跨端 React Native 项目的这几年最烦的从来不是写业务代码而是把同一套东西在 iOS、Android、TestFlight、Google Play、各类国内分发渠道之间来回搬运。后来把 EAS 和 Fastlane 的组合拳彻底打通之后多端自动化打包发布才真正变成一条不需要人盯着跑的流水线。这篇文章就是我搭这套工程化流程的完整记录包括为什么这么拆、怎么配置、踩过哪些坑以及几个值得你直接抄的实践姿势。这套方案的核心思路其实是把“构建环境”和“发布动作”彻底解耦EAS 负责在云端把原生工程变成可上架的 ipa、aab、apk解决的是环境一致和签名管理问题Fastlane 负责在本地或 CI 里把这些产物送到各个商店、渠道顺便处理版本号、截图和通知。两者各干各的又通过构建产物和命令行接口连成一条完整链路。无论你是个人开发者、小团队还是已经有一堆 CI 脚本的中型团队这套组合都能把打包发布这件事的维护成本压到很低。1. 为什么需要“多端自动化打包发布”1.1 传统打包流程的痛点摆在那里我见过太多团队还在用“人肉打包”的方式发版本iOS 这边开发者在自己的 Mac 上打开 Xcodemanage signing、等待 Pod install再点 Product Archive然后跑到 App Store Connect 上传 TestFlightAndroid 那边本地跑 gradlew assembleRelease签好名之后再去 Google Play Console 传 aab顺带还得填一遍“这次更新了什么”。如果只是双端倒也罢了现实往往是还有 develop、staging、production 多个环境还有不同 bundleId 的白标版本一遍遍手动选 scheme、选 target、换签名真的很消磨耐心。更麻烦的是人肉流程一旦交接给别人环境差异就会带来一堆“在我机器上能跑”的问题。比如 A 同事本地装的是 CocoaPods 1.12B 同事还是 1.11打出来的包行为都可能不一样再比如证书放在某某的钥匙串里他休假了发版就得往后拖。这类问题没有技术难度却实实在在消耗团队信任。1.2 EAS 与 Fastlane 的分工逻辑后来我引入了 EAS 和 Fastlane把整件事拆成了两个角色。先说结论EAS 的核心价值是云构建与环境标准化。你在本地只需要提交代码和配置EAS 会在云端一次性装好 Node、Java、Ruby、CocoaPods、Gradle 这些依赖然后基于同一套配置文件产出二进制。这就像把“厨房”整体搬到云端每个人拿到的菜谱一样做出来的菜至少不会因为灶台不同而翻车。Fastlane 的价值则是发布动作的编排。它本身不是构建工具而是一个用 Ruby 写的自动化“车道”系统把签名、上传、截图、版本号更新、通知这些动作串成 lane。打个比方EAS 负责把食材做成半成品Fastlane 负责按不同餐厅的要求摆盘和上菜。你会发现两者并不冲突EAS 里也有 eas submit 可以直接提交商店但对于国内多个渠道、Firebase App Distribution、钉钉/飞书消息通知这些自定义场景Fastlane 的可编程性明显更强。这也是我为什么最终采用“云构建 本地/CI 动作编排”的组合而不是只押注其中某一个工具。职责EASExpo Application ServicesFastlane构建环境云上统一无需本地原生环境主要靠本地/CI 环境但可以做环境校验证书管理EAS 云端 credentials 管理match 统一管理签名证书和描述文件上传 App Store / TestFlight支持 eas submit支持 deliver / upload_to_testflight上传 Google Play支持 eas submit android支持 upload_to_play_store自定义发布动作走 CLI 命令较难扩展lane 内任意脚本扩展性极强适合场景Expo / React Native 云构建多渠道、多商店、复杂发布编排2. EAS 云构建把原生环境问题抛给云端2.1 EAS 到底是什么免费额度够不够EAS 是 Expo 团队提供的应用服务套件包含 EAS Build云构建、EAS Submit提交应用、EAS UpdateOTA 热更新等。你可以在 Expo 的官方文档里把它看成“React Native 世界的 CI 构建服务”。它支持 Expo 托管工作流也能用于 bare workflow 和纯 React Native 项目前提是你的项目结构能被 eas-cli 识别。很多人在决定使用前第一句话问EAS 云端构建免费吗这个我可以明确回答有免费档个人项目完全够用但别把它当无限资源。免费档的 EAS Build 通常会提供每月一定次数的构建配额iOS 和 Android 都会消耗而且并发数不高。高峰期提交构建可能要排队遇到这种情况要么把构建时间错开要么直接升级到付费档。我的建议是练手、开源项目、体量小的产品直接用免费档没问题正式团队流水线就直接选付费计划否则一旦一天内几次构建等免费队列能等到怀疑人生。另外用 EAS 构建 iOS 依然需要你在 Apple Developer 后台有对应权限也需要配置签名证书只是说你可以把证书上传到 EAS 云端统一管理不用再让每个开发者的 Mac 都装一套。Android 也是同样的逻辑keystore 上传到 EAS 之后团队任何人触发构建都能用同一套签名。2.2 eas.json 配置实战先在项目根目录安装 eas-cli 并登录npm install -g eas-cli eas login然后在项目里初始化 EAS 配置。如果你已经有 app.json / app.config.js直接执行eas build:configure它会生成一个 eas.json。我们把它配置成开发、预览、生产三个 profile这是我认为最实用的划分方式{ cli: { version: 3.17.2, appVersionSource: remote }, build: { development: { developmentClient: true, distribution: internal, channel: development, env: { APP_ENV: development } }, preview: { distribution: internal, channel: preview, env: { APP_ENV: preview } }, production: { channel: production, autoIncrement: true, env: { APP_ENV: production } } }, submit: { production: {} } }几个配置项要注意。cli.version建议指定一个范围避免团队里 eas-cli 大版本不同导致行为不一致。appVersionSource设为remote时EAS 会用云端维护的版本号对多端同一版本非常友好如果你更习惯本地 app.json 控制版本就保持默认或者显式设成local。developmentClient用于真机调试场景它会构建一个包含 Expo Dev Client 的开发版客户端preview一般用于测试人员安装可以设成 apk 方便安卓侧直接分发production是我们真正提审商店的配置autoIncrement自动递增 iOS buildNumber 和 Android versionCode这个特性我从用了之后就再没手工碰过版本号。2.3 构建环境、缓存与签名管理的关键细节构建环境方面EAS 默认会拉取项目依赖执行 prebuild如果配置了然后在云端跑原生的编译命令。你可以在 eas.json 里用build.resourceClass指定更强的机器比如 Android 大项目建议选m-medium或更高否则 Gradle 构建会慢到让你怀疑人生。cache配置建议始终保持开启这样 node_modules 和 Gradle 缓存能被复用相同依赖的后续构建能快非常多。签名这块我踩过一个坑刚开始我用 EAS 自动生成和管理证书一个人开发很爽但当 CI 里的构建机器也需要访问同一套证书时我发现如果凭据存在 EAS 云端任何触发 eas build 的账号都能用它。这本来是好事但你得保证所有触发构建的机器/账号都在同一个 Expo 项目空间里。后来团队多了我干脆把证书交给 Fastlane match 管理一部分再配合 EAS 的credentialsSource: remote让 EAS 构建时从远程凭据库拉取这样“证书由团队统一维护构建由云端统一执行”职责最清晰。一个小建议不要在构建脚本里直接 echo 密钥。EAS 提供的 secrets 环境变量默认不会输出到日志但你如果自己写脚本把它们打到控制台那就白瞎了。我在一个项目里就见过有人把 Google 服务账号 JSON 直接 base64 之后打到 log 里等提交到商店被审计发现只能紧急轮换。3. Fastlane从本地脚本到发布流水线的“指挥官”3.1 Fastlane 的核心概念与定位Fastlane 是一个老牌的移动端自动化工具基于 Ruby 编写。它的核心模型是 lane你可以把它理解成一个“发布动作插槽”lane :beta do build_app upload_to_testflight end每个 lane 里可以调用 Fastlane 自带的 action也可以执行任意 shell 命令甚至可以触发 EAS CLI。这就是为什么它适合当整个发布流程的“编排层”——EAS 负责最重的构建Fastlane 则把上传、通知、版本记录、截图处理这些杂活统一收口。3.2 安装与初始化在 macOS 上安装 Fastlane 通常用 Homebrewbrew install fastlane或者装在项目里作为 Ruby gemgem install fastlane进入 iOS 或 Android 工程目录后执行fastlane initFastlane 会生成 fastlane/Fastfile 和 Appfile。Appfile 里定义 app_identifier、team_id 等基本信息Fastfile 里写 lane。注意如果你用的是 monorepoFastlane 目录可能要按平台分开放或者通过环境变量切换。Fastlane 与 EAS 结合的关键在于EAS 构建完成后会返回一个构建 IDFastlane 可以通过 eas-cli 拉取对应产物文件再执行上传。下面这个 iOS lane 是我其中一个项目里在用的它负责把 EAS 构建出来的 ipa 上传到 TestFlightdefault_platform(:ios) platform :ios do before_all do ensure_cli_version end desc 上传 EAS 构建产物到 TestFlight lane :upload_testflight do |options| ipa_path options[:ipa] || Dir[build/EAS*.ipa].last api_key app_store_connect_api_key( key_id: ENV[ASC_KEY_ID], issuer_id: ENV[ASC_ISSUER_ID], key_filepath: ENV[ASC_KEY_FILE] ) upload_to_testflight( api_key: api_key, ipa: ipa_path, app_identifier: ENV[BUNDLE_ID], skip_waiting_for_build_processing: false ) end endAndroid 侧则更直接上传到 Google Play 内部测试轨道platform :android do desc 上传 AAB 到 Google Play 内部测试轨道 lane :upload_internal do |options| aab_path options[:aab] || Dir[build/*.aab].last upload_to_play_store( track: internal, aab: aab_path, json_key: ENV[PLAY_CONSOLE_JSON_KEY] ) end end用skip_waiting_for_build_processing: false会让 lane 一直等到 TestFlight 处理完成再退出这样 CI 不会因为 upload 完就退出而把后续流程带到“还没处理完”的状态。要注意 TestFlight 处理高峰期可能要等十分钟以上对于 CI 任务超时设置要给足余量。3.3 用 Fastlane match 统一管理签名证书如果团队超过一个人强烈建议用 fastlane match 管理签名。match 会把证书和 provisioning profile 加密存储在一个 git 仓库或 Google Cloud 存储中然后按需求自动安装到当前机器。这在配合 EAS 构建时有一个特殊价值如果你某些环节必须在本地签名后再上传match 能保证每一位同事拿到的证书一致。初始化 matchfastlane match init会要求填写存储仓库地址。然后按平台执行fastlane match appstore fastlane match development生成证书后会写入加密仓库之后用fastlane match --readonly也能只读安装。团队里添加新人时只需要让他在项目目录跑一遍 match 即可不再需要找老同事要证书文件。用 match 之后EAS 云端构建和 Fastlane 本地签名之间要格外注意 bundle id 的一致性。我遇到过最无语的问题iOS 的 provisioning profile 里 bundle id 是com.example.appEAS 构建时 app.config.js 却因为某个环境变量给改成了com.example.app.dev结果上传 TestFlight 直接报“Invalid Provisioning Profile”。排查到最后发现是 CI 里有人设置了EXPO_PUBLIC_APP_ENVdev而 app.config.js 里根据这个变量动态改 bundle id。后面我统一把所有 bundle id 映射收敛到 app.config.js 里根本不允许运行时环境变量再改问题才彻底消失。4. 打通多端发布链路EAS Fastlane 的三种组合姿势4.1 姿势一EAS 构建 EAS Submit最小成本搞定双端如果你的目标就是上架 App Store 和 Google Play没有太多国内渠道最简单可靠的组合是用 EAS Build 加 EAS Submit一条命令就能双端构建eas build --platform all --profile production --non-interactive构建完成后再执行eas submit --platform all --profile productionEAS Submit 会读取你 eas.json 里 submit 的配置自动帮你上传 ipa 到 App Store Connect、上传 aab 到 Google Play。这个姿势的优势在于完全不用碰 Fastlane少一个工具就少一个维护点也很适合刚接触自动化的团队。缺点是遇到复杂发布流程比如同时往三个渠道发或者要更新商店截图EAS Submit 就有点力不从心了。4.2 姿势二EAS 构建产物 Fastlane 上传分发大多数我接触到的团队最终会采用这个姿势。EAS 只负责构建构建完成后用 eas-cli 把产物拉到本地/CI再由 Fastlane 负责分发到 TestFlight、Google Play、Firebase App Distribution 或者各种内测平台。整体流程大致是eas build --platform all --profile preview --non-interactive触发双端云构建。eas build:download --platform ios --profile preview --output build/ios拉取 iOS 产物。eas build:download --platform android --profile preview --output build/android拉取 Android 产物。fastlane ios upload_testflight ipa:build/ios/*.ipa上传 TestFlight。fastlane android upload_internal aab:build/android/*.aab上传 Google Play 内部轨道。第 2、3 步看起来多余但它给了你在上传前做最终检查的机会。比如 Android 侧想先生成一份 aab 和一份 apk分别发给不同测试组你就可以在下载产物后再跑一次本地脚本拆分Fastlane 则负责把多份产物分发到不同渠道。这种灵活度是纯 EAS Submit 给不了的。4.3 姿势三CI 中编排 Fastlane 驱动整个流程再往上走一步就是把上面这些命令集成到 GitHub Actions / GitLab CI / Jenkins 里。我目前用的 GitHub Actions 工作流大致是开发推送到 release 分支后CI 自动安装依赖执行 lint 和单测通过后调用 EAS 云构建构建成功再调用 Fastlane 上传最后往飞书/钉钉发一条“新版已上 TestFlight”的通知。流程中要注意的是CI 环境里 EAS CLI 的登录不能依赖交互式输入需要用EXPO_TOKEN环境变量做身份认证。在 CI 变量里配置好EXPO_TOKEN然后eas build就可以加--non-interactive参数。Fastlane 这边的敏感信息也全部走 CI secrets避免把钥匙串文件或 p8 密钥写进仓库。版本号管理在这个环节尤其重要。建议始终让 EAS 的autoIncrement负责构建号而 App Store 的版本号比如 2.3.0由代码仓库里的 app.json 或业务侧脚本统一控制。如果你没有统一管控就会出现 iOS 构建号 14、Android versionCode 16 这种双端不同步的情况后面排查线上问题会非常痛苦。4.4 多端参数管理与版本号自动递增多端项目往往有多个 bundle id、多个应用名、多套 API 地址。我的做法是在 app.config.js 里用函数动态生成配置按环境变量区分const APP_ENV process.env.APP_ENV || development; const configs { development: { name: MyApp Dev, bundleId: com.example.app.dev, apiUrl: https://dev-api.example.com }, production: { name: MyApp, bundleId: com.example.app, apiUrl: https://api.example.com } }; const current configs[APP_ENV]; export default { name: current.name, slug: myapp, version: 2.3.0, ios: { bundleIdentifier: current.bundleId, buildNumber: 14 }, android: { package: current.bundleId, versionCode: 14 }, extra: { apiUrl: current.apiUrl } };这样每次构建只要切换APP_ENV就能得到对应环境的配置。但要注意profile 里的 env 和 app.config.js 里面读取的环境变量是两条链路eas.json里build.production.env只对构建阶段生效如果你想在运行时通过expo-constants读取就要把变量放到extra里或者用EXPO_PUBLIC_前缀暴露给 Metro 打包环境。这个细节很多人混淆导致“开发环境好的Pro 包读不到变量”。5. 常见问题与排查实录5.1 构建失败速查表现象常见原因解决办法EAS 构建一直排队免费档并发不足高峰期资源挤占错峰构建或升级付费计划Android 构建超时依赖下载慢、Gradle 配置过大开启缓存指定更高的 resourceClassiOS 构建时 Pod install 卡死CocoaPods 源不稳定或版本冲突锁定 Podfile 版本必要时配置镜像源构建提示缺少 app.json仓库没有完整的 Expo 配置执行eas build:configure确认 app.config.js 导出正常EAS 构建成功但下载产物为空平台或 profile 匹配错误检查--platform和--profile参数有一个我反复遇到的坑EAS 在云端新装依赖时如果package-lock.json或yarn.lock没提交构建机会随手解析最新版本很容易出现“本地没问题云端打包后行为不一致”的情况。所以建议从第一天起把锁文件提交进仓库并且在 eas.json 里禁用installCommand覆盖只有在需要私有源时才主动指定。5.2 签名与证书相关的坑如果你使用 EAS 云端管理凭据常见报错是 “Code signing is required for product type Application in SDK”。处理思路是先检查 eas.json 的credentialsSource是 remote 还是 local。团队多人协作时用 remote 容易遇到“别人更新了证书你本地还是旧缓存”的问题这时候去 EAS 后台 credentials 页面确认当前证书是否还在有效期内并让所有人重新拉取。Fastlane match 管理证书时另一个高频问题是 Appfile 里的 team_id 和 App Store Connect API Key 的 issuer_id 不一致。上传 TestFlight 报 401 或者 403八成就是 API key 权限不足需要去 App Store Connect 生成一个具有 App 管理权限的 key而不是用个人账号的开发者 token。我还遇到过 provisioning profile 过期导致的一连串连锁问题因为 iOS 描述文件有效期一般一年团队没有监控导致某次 release 构建时 EAS 自动重新生成了一个 profile但 App Store 那边已经有同名 profile两边签名不一致测试手机安装直接失败。后来我在 CI 里加了一步构建前先跑fastlane match --readonly本地强制装好最新描述文件再让 EAS 使用 remote credentials 构建基本杜绝了这类问题。5.3 环境变量和密钥管理前面提到的EXPO_PUBLIC_前缀问题值得再说一遍。现在 Expo SDK 49 支持通过EXPO_PUBLIC_前缀在客户端代码里直接访问环境变量但这种方式在打包时会被内嵌进 JS bundle所以绝对不要用它存 API 密钥、签名字符串这类敏感信息。服务端或构建期用的密钥请放到 EAS environment secrets 或 CI secrets 里运行时才需要的业务配置可以放进extra后通过expo-constants读取。Fastlane 侧也一样ENV[ASC_KEY_ID]这些值建议统一放 CI secrets。如果你在本地调试跑 lane可以新建一个.env文件但必须确保它进了.gitignore。我在一个朋友的仓库里见过.env被提交到 GitHub里面直接躺着一把具备生产发布权限的 Google Play 服务账号 key这种事故一旦发生基本只能紧急撤销并重新生成密钥。5.4 关于 EAS 免费的客观建议回到“EAS 云端构建免费吗”这个问题。我要给一个很实际的结论免费档适合学习和个人项目但当你有多环境、多平台、一天要出好几版的需求时构建排队的时间成本会远超付费套餐的价格。我在一个外包项目上就吃过教训因为预算限制选了免费档测试反馈一个 bug我改完提交构建硬生生在队列里等了快一个小时那一个小时里整个团队都在等包。后来客户发现一个 bug 才损失多少时间完全对不上。所以我的建议是项目初期可以免费档跑通流程一旦进入频繁迭代阶段直接为团队购买按月付费的 plan。比较一下 CI 机器成本和你人工打包的时间成本你会发现这笔钱非常值。6. 工程化的下一步测试与评审如何真正融入流水线6.1 把自动化测试放进构建流程有些团队把 EAS 构建成功当成“可以发版”的唯一信号其实这是远远不够的。构建成功只能说明代码能编译成二进制不能说明它没有破坏核心流程。我们现在的做法是在触发 EAS Build 之前先在 CI 里跑一轮单元测试和关键 UI 测试。React Native 项目可以用 Jest 跑组件测试用 Detox 或 Maestro 跑关键路径的端到端测试。只有测试全绿才允许 EAS 开始构建。好处很明显以前如果测试没过要等构建出来才能察觉现在在更早的阶段就拦住了。而且这类测试并不需要发生在 EAS 内部完全可以在 GitHub Actions / GitLab CI 的 job 里跑。让 EAS 只做它最擅长的事——构建。有一点需要提醒端到端测试不要全部放在每次构建前跑否则流水线会很慢。我一般把测试分层合并前跑静态检查、单元测试和少量冒烟用例合并后的 release 构建前再跑完整的 Maestro 关键流程。这套分层下来既保证质量又不会让工程师等 CI 等到崩溃。6.2 代码评审与质量工具的接入打包发布只是工程化的最后一公里真正决定能不能“放心发”的还是代码合入前的质量关卡。近几年不少工程化平台开始提供 AI 生成测试用例和自动代码 review 的能力比如有些团队用 Harness 之类的平台做 CI/CD顺带就把 AI 自动拆解需求、生成测试用例、代码变更评审接进了流水线。我不认为 AI 评审能替代人工 reviewer但它确实能在你点下 merge 之前把明显的空指针风险、环境配置错漏、硬编码问题先筛一遍。我们在接入这类能力后有一个很明显的感受代码评审的噪音少了人工 reviewer 能专注于架构和业务语义层面的问题。而且这类能力最好和发布流水线联动——比如只有当 AI review 通过、单元测试通过、关键 E2E 全部绿release 分支才允许触发 EAS 构建。这样一来整个发布链路的自动化才闭环从代码提交、静态检查、单测、AI 辅助评审到 EAS 云构建、Fastlane 分发最后再到 TestFlight / Google Play 出包每个环节都有明确的门禁。我个人现在最受用的是把“人”从重复操作里解放出来。以前发版是一个仪式要拉群、同步状态、盯着上传现在发版只是一个 merge action剩下的事情交给流水线。我能做的就是在一个干净清爽的 TestFlight 链接出来之后把它的下载地址丢给测试群然后等反馈。如果你也正被多端打包和人工发布流程折磨我真心建议先把 EAS Fastlane 这套链路搭起来。哪怕第一天只是让 EAS 替你跑一次云构建第二天再让 Fastlane 自动上传也已经比原来手动点 Xcode 高效太多了。工程化不是让你多写几个脚本而是让团队把精力花在真正影响产品的事上。
如果你也是那种“上午改一行配置下午排队等 Xcode 上传凌晨还要盯 Google Play 审核”的人那这篇东西应该对胃口。我做跨端 React Native 项目的这几年最烦的从来不是写业务代码而是把同一套东西在 iOS、Android、TestFlight、Google Play、各类国内分发渠道之间来回搬运。后来把 EAS 和 Fastlane 的组合拳彻底打通之后多端自动化打包发布才真正变成一条不需要人盯着跑的流水线。这篇文章就是我搭这套工程化流程的完整记录包括为什么这么拆、怎么配置、踩过哪些坑以及几个值得你直接抄的实践姿势。这套方案的核心思路其实是把“构建环境”和“发布动作”彻底解耦EAS 负责在云端把原生工程变成可上架的 ipa、aab、apk解决的是环境一致和签名管理问题Fastlane 负责在本地或 CI 里把这些产物送到各个商店、渠道顺便处理版本号、截图和通知。两者各干各的又通过构建产物和命令行接口连成一条完整链路。无论你是个人开发者、小团队还是已经有一堆 CI 脚本的中型团队这套组合都能把打包发布这件事的维护成本压到很低。1. 为什么需要“多端自动化打包发布”1.1 传统打包流程的痛点摆在那里我见过太多团队还在用“人肉打包”的方式发版本iOS 这边开发者在自己的 Mac 上打开 Xcodemanage signing、等待 Pod install再点 Product Archive然后跑到 App Store Connect 上传 TestFlightAndroid 那边本地跑 gradlew assembleRelease签好名之后再去 Google Play Console 传 aab顺带还得填一遍“这次更新了什么”。如果只是双端倒也罢了现实往往是还有 develop、staging、production 多个环境还有不同 bundleId 的白标版本一遍遍手动选 scheme、选 target、换签名真的很消磨耐心。更麻烦的是人肉流程一旦交接给别人环境差异就会带来一堆“在我机器上能跑”的问题。比如 A 同事本地装的是 CocoaPods 1.12B 同事还是 1.11打出来的包行为都可能不一样再比如证书放在某某的钥匙串里他休假了发版就得往后拖。这类问题没有技术难度却实实在在消耗团队信任。1.2 EAS 与 Fastlane 的分工逻辑后来我引入了 EAS 和 Fastlane把整件事拆成了两个角色。先说结论EAS 的核心价值是云构建与环境标准化。你在本地只需要提交代码和配置EAS 会在云端一次性装好 Node、Java、Ruby、CocoaPods、Gradle 这些依赖然后基于同一套配置文件产出二进制。这就像把“厨房”整体搬到云端每个人拿到的菜谱一样做出来的菜至少不会因为灶台不同而翻车。Fastlane 的价值则是发布动作的编排。它本身不是构建工具而是一个用 Ruby 写的自动化“车道”系统把签名、上传、截图、版本号更新、通知这些动作串成 lane。打个比方EAS 负责把食材做成半成品Fastlane 负责按不同餐厅的要求摆盘和上菜。你会发现两者并不冲突EAS 里也有 eas submit 可以直接提交商店但对于国内多个渠道、Firebase App Distribution、钉钉/飞书消息通知这些自定义场景Fastlane 的可编程性明显更强。这也是我为什么最终采用“云构建 本地/CI 动作编排”的组合而不是只押注其中某一个工具。职责EASExpo Application ServicesFastlane构建环境云上统一无需本地原生环境主要靠本地/CI 环境但可以做环境校验证书管理EAS 云端 credentials 管理match 统一管理签名证书和描述文件上传 App Store / TestFlight支持 eas submit支持 deliver / upload_to_testflight上传 Google Play支持 eas submit android支持 upload_to_play_store自定义发布动作走 CLI 命令较难扩展lane 内任意脚本扩展性极强适合场景Expo / React Native 云构建多渠道、多商店、复杂发布编排2. EAS 云构建把原生环境问题抛给云端2.1 EAS 到底是什么免费额度够不够EAS 是 Expo 团队提供的应用服务套件包含 EAS Build云构建、EAS Submit提交应用、EAS UpdateOTA 热更新等。你可以在 Expo 的官方文档里把它看成“React Native 世界的 CI 构建服务”。它支持 Expo 托管工作流也能用于 bare workflow 和纯 React Native 项目前提是你的项目结构能被 eas-cli 识别。很多人在决定使用前第一句话问EAS 云端构建免费吗这个我可以明确回答有免费档个人项目完全够用但别把它当无限资源。免费档的 EAS Build 通常会提供每月一定次数的构建配额iOS 和 Android 都会消耗而且并发数不高。高峰期提交构建可能要排队遇到这种情况要么把构建时间错开要么直接升级到付费档。我的建议是练手、开源项目、体量小的产品直接用免费档没问题正式团队流水线就直接选付费计划否则一旦一天内几次构建等免费队列能等到怀疑人生。另外用 EAS 构建 iOS 依然需要你在 Apple Developer 后台有对应权限也需要配置签名证书只是说你可以把证书上传到 EAS 云端统一管理不用再让每个开发者的 Mac 都装一套。Android 也是同样的逻辑keystore 上传到 EAS 之后团队任何人触发构建都能用同一套签名。2.2 eas.json 配置实战先在项目根目录安装 eas-cli 并登录npm install -g eas-cli eas login然后在项目里初始化 EAS 配置。如果你已经有 app.json / app.config.js直接执行eas build:configure它会生成一个 eas.json。我们把它配置成开发、预览、生产三个 profile这是我认为最实用的划分方式{ cli: { version: 3.17.2, appVersionSource: remote }, build: { development: { developmentClient: true, distribution: internal, channel: development, env: { APP_ENV: development } }, preview: { distribution: internal, channel: preview, env: { APP_ENV: preview } }, production: { channel: production, autoIncrement: true, env: { APP_ENV: production } } }, submit: { production: {} } }几个配置项要注意。cli.version建议指定一个范围避免团队里 eas-cli 大版本不同导致行为不一致。appVersionSource设为remote时EAS 会用云端维护的版本号对多端同一版本非常友好如果你更习惯本地 app.json 控制版本就保持默认或者显式设成local。developmentClient用于真机调试场景它会构建一个包含 Expo Dev Client 的开发版客户端preview一般用于测试人员安装可以设成 apk 方便安卓侧直接分发production是我们真正提审商店的配置autoIncrement自动递增 iOS buildNumber 和 Android versionCode这个特性我从用了之后就再没手工碰过版本号。2.3 构建环境、缓存与签名管理的关键细节构建环境方面EAS 默认会拉取项目依赖执行 prebuild如果配置了然后在云端跑原生的编译命令。你可以在 eas.json 里用build.resourceClass指定更强的机器比如 Android 大项目建议选m-medium或更高否则 Gradle 构建会慢到让你怀疑人生。cache配置建议始终保持开启这样 node_modules 和 Gradle 缓存能被复用相同依赖的后续构建能快非常多。签名这块我踩过一个坑刚开始我用 EAS 自动生成和管理证书一个人开发很爽但当 CI 里的构建机器也需要访问同一套证书时我发现如果凭据存在 EAS 云端任何触发 eas build 的账号都能用它。这本来是好事但你得保证所有触发构建的机器/账号都在同一个 Expo 项目空间里。后来团队多了我干脆把证书交给 Fastlane match 管理一部分再配合 EAS 的credentialsSource: remote让 EAS 构建时从远程凭据库拉取这样“证书由团队统一维护构建由云端统一执行”职责最清晰。一个小建议不要在构建脚本里直接 echo 密钥。EAS 提供的 secrets 环境变量默认不会输出到日志但你如果自己写脚本把它们打到控制台那就白瞎了。我在一个项目里就见过有人把 Google 服务账号 JSON 直接 base64 之后打到 log 里等提交到商店被审计发现只能紧急轮换。3. Fastlane从本地脚本到发布流水线的“指挥官”3.1 Fastlane 的核心概念与定位Fastlane 是一个老牌的移动端自动化工具基于 Ruby 编写。它的核心模型是 lane你可以把它理解成一个“发布动作插槽”lane :beta do build_app upload_to_testflight end每个 lane 里可以调用 Fastlane 自带的 action也可以执行任意 shell 命令甚至可以触发 EAS CLI。这就是为什么它适合当整个发布流程的“编排层”——EAS 负责最重的构建Fastlane 则把上传、通知、版本记录、截图处理这些杂活统一收口。3.2 安装与初始化在 macOS 上安装 Fastlane 通常用 Homebrewbrew install fastlane或者装在项目里作为 Ruby gemgem install fastlane进入 iOS 或 Android 工程目录后执行fastlane initFastlane 会生成 fastlane/Fastfile 和 Appfile。Appfile 里定义 app_identifier、team_id 等基本信息Fastfile 里写 lane。注意如果你用的是 monorepoFastlane 目录可能要按平台分开放或者通过环境变量切换。Fastlane 与 EAS 结合的关键在于EAS 构建完成后会返回一个构建 IDFastlane 可以通过 eas-cli 拉取对应产物文件再执行上传。下面这个 iOS lane 是我其中一个项目里在用的它负责把 EAS 构建出来的 ipa 上传到 TestFlightdefault_platform(:ios) platform :ios do before_all do ensure_cli_version end desc 上传 EAS 构建产物到 TestFlight lane :upload_testflight do |options| ipa_path options[:ipa] || Dir[build/EAS*.ipa].last api_key app_store_connect_api_key( key_id: ENV[ASC_KEY_ID], issuer_id: ENV[ASC_ISSUER_ID], key_filepath: ENV[ASC_KEY_FILE] ) upload_to_testflight( api_key: api_key, ipa: ipa_path, app_identifier: ENV[BUNDLE_ID], skip_waiting_for_build_processing: false ) end endAndroid 侧则更直接上传到 Google Play 内部测试轨道platform :android do desc 上传 AAB 到 Google Play 内部测试轨道 lane :upload_internal do |options| aab_path options[:aab] || Dir[build/*.aab].last upload_to_play_store( track: internal, aab: aab_path, json_key: ENV[PLAY_CONSOLE_JSON_KEY] ) end end用skip_waiting_for_build_processing: false会让 lane 一直等到 TestFlight 处理完成再退出这样 CI 不会因为 upload 完就退出而把后续流程带到“还没处理完”的状态。要注意 TestFlight 处理高峰期可能要等十分钟以上对于 CI 任务超时设置要给足余量。3.3 用 Fastlane match 统一管理签名证书如果团队超过一个人强烈建议用 fastlane match 管理签名。match 会把证书和 provisioning profile 加密存储在一个 git 仓库或 Google Cloud 存储中然后按需求自动安装到当前机器。这在配合 EAS 构建时有一个特殊价值如果你某些环节必须在本地签名后再上传match 能保证每一位同事拿到的证书一致。初始化 matchfastlane match init会要求填写存储仓库地址。然后按平台执行fastlane match appstore fastlane match development生成证书后会写入加密仓库之后用fastlane match --readonly也能只读安装。团队里添加新人时只需要让他在项目目录跑一遍 match 即可不再需要找老同事要证书文件。用 match 之后EAS 云端构建和 Fastlane 本地签名之间要格外注意 bundle id 的一致性。我遇到过最无语的问题iOS 的 provisioning profile 里 bundle id 是com.example.appEAS 构建时 app.config.js 却因为某个环境变量给改成了com.example.app.dev结果上传 TestFlight 直接报“Invalid Provisioning Profile”。排查到最后发现是 CI 里有人设置了EXPO_PUBLIC_APP_ENVdev而 app.config.js 里根据这个变量动态改 bundle id。后面我统一把所有 bundle id 映射收敛到 app.config.js 里根本不允许运行时环境变量再改问题才彻底消失。4. 打通多端发布链路EAS Fastlane 的三种组合姿势4.1 姿势一EAS 构建 EAS Submit最小成本搞定双端如果你的目标就是上架 App Store 和 Google Play没有太多国内渠道最简单可靠的组合是用 EAS Build 加 EAS Submit一条命令就能双端构建eas build --platform all --profile production --non-interactive构建完成后再执行eas submit --platform all --profile productionEAS Submit 会读取你 eas.json 里 submit 的配置自动帮你上传 ipa 到 App Store Connect、上传 aab 到 Google Play。这个姿势的优势在于完全不用碰 Fastlane少一个工具就少一个维护点也很适合刚接触自动化的团队。缺点是遇到复杂发布流程比如同时往三个渠道发或者要更新商店截图EAS Submit 就有点力不从心了。4.2 姿势二EAS 构建产物 Fastlane 上传分发大多数我接触到的团队最终会采用这个姿势。EAS 只负责构建构建完成后用 eas-cli 把产物拉到本地/CI再由 Fastlane 负责分发到 TestFlight、Google Play、Firebase App Distribution 或者各种内测平台。整体流程大致是eas build --platform all --profile preview --non-interactive触发双端云构建。eas build:download --platform ios --profile preview --output build/ios拉取 iOS 产物。eas build:download --platform android --profile preview --output build/android拉取 Android 产物。fastlane ios upload_testflight ipa:build/ios/*.ipa上传 TestFlight。fastlane android upload_internal aab:build/android/*.aab上传 Google Play 内部轨道。第 2、3 步看起来多余但它给了你在上传前做最终检查的机会。比如 Android 侧想先生成一份 aab 和一份 apk分别发给不同测试组你就可以在下载产物后再跑一次本地脚本拆分Fastlane 则负责把多份产物分发到不同渠道。这种灵活度是纯 EAS Submit 给不了的。4.3 姿势三CI 中编排 Fastlane 驱动整个流程再往上走一步就是把上面这些命令集成到 GitHub Actions / GitLab CI / Jenkins 里。我目前用的 GitHub Actions 工作流大致是开发推送到 release 分支后CI 自动安装依赖执行 lint 和单测通过后调用 EAS 云构建构建成功再调用 Fastlane 上传最后往飞书/钉钉发一条“新版已上 TestFlight”的通知。流程中要注意的是CI 环境里 EAS CLI 的登录不能依赖交互式输入需要用EXPO_TOKEN环境变量做身份认证。在 CI 变量里配置好EXPO_TOKEN然后eas build就可以加--non-interactive参数。Fastlane 这边的敏感信息也全部走 CI secrets避免把钥匙串文件或 p8 密钥写进仓库。版本号管理在这个环节尤其重要。建议始终让 EAS 的autoIncrement负责构建号而 App Store 的版本号比如 2.3.0由代码仓库里的 app.json 或业务侧脚本统一控制。如果你没有统一管控就会出现 iOS 构建号 14、Android versionCode 16 这种双端不同步的情况后面排查线上问题会非常痛苦。4.4 多端参数管理与版本号自动递增多端项目往往有多个 bundle id、多个应用名、多套 API 地址。我的做法是在 app.config.js 里用函数动态生成配置按环境变量区分const APP_ENV process.env.APP_ENV || development; const configs { development: { name: MyApp Dev, bundleId: com.example.app.dev, apiUrl: https://dev-api.example.com }, production: { name: MyApp, bundleId: com.example.app, apiUrl: https://api.example.com } }; const current configs[APP_ENV]; export default { name: current.name, slug: myapp, version: 2.3.0, ios: { bundleIdentifier: current.bundleId, buildNumber: 14 }, android: { package: current.bundleId, versionCode: 14 }, extra: { apiUrl: current.apiUrl } };这样每次构建只要切换APP_ENV就能得到对应环境的配置。但要注意profile 里的 env 和 app.config.js 里面读取的环境变量是两条链路eas.json里build.production.env只对构建阶段生效如果你想在运行时通过expo-constants读取就要把变量放到extra里或者用EXPO_PUBLIC_前缀暴露给 Metro 打包环境。这个细节很多人混淆导致“开发环境好的Pro 包读不到变量”。5. 常见问题与排查实录5.1 构建失败速查表现象常见原因解决办法EAS 构建一直排队免费档并发不足高峰期资源挤占错峰构建或升级付费计划Android 构建超时依赖下载慢、Gradle 配置过大开启缓存指定更高的 resourceClassiOS 构建时 Pod install 卡死CocoaPods 源不稳定或版本冲突锁定 Podfile 版本必要时配置镜像源构建提示缺少 app.json仓库没有完整的 Expo 配置执行eas build:configure确认 app.config.js 导出正常EAS 构建成功但下载产物为空平台或 profile 匹配错误检查--platform和--profile参数有一个我反复遇到的坑EAS 在云端新装依赖时如果package-lock.json或yarn.lock没提交构建机会随手解析最新版本很容易出现“本地没问题云端打包后行为不一致”的情况。所以建议从第一天起把锁文件提交进仓库并且在 eas.json 里禁用installCommand覆盖只有在需要私有源时才主动指定。5.2 签名与证书相关的坑如果你使用 EAS 云端管理凭据常见报错是 “Code signing is required for product type Application in SDK”。处理思路是先检查 eas.json 的credentialsSource是 remote 还是 local。团队多人协作时用 remote 容易遇到“别人更新了证书你本地还是旧缓存”的问题这时候去 EAS 后台 credentials 页面确认当前证书是否还在有效期内并让所有人重新拉取。Fastlane match 管理证书时另一个高频问题是 Appfile 里的 team_id 和 App Store Connect API Key 的 issuer_id 不一致。上传 TestFlight 报 401 或者 403八成就是 API key 权限不足需要去 App Store Connect 生成一个具有 App 管理权限的 key而不是用个人账号的开发者 token。我还遇到过 provisioning profile 过期导致的一连串连锁问题因为 iOS 描述文件有效期一般一年团队没有监控导致某次 release 构建时 EAS 自动重新生成了一个 profile但 App Store 那边已经有同名 profile两边签名不一致测试手机安装直接失败。后来我在 CI 里加了一步构建前先跑fastlane match --readonly本地强制装好最新描述文件再让 EAS 使用 remote credentials 构建基本杜绝了这类问题。5.3 环境变量和密钥管理前面提到的EXPO_PUBLIC_前缀问题值得再说一遍。现在 Expo SDK 49 支持通过EXPO_PUBLIC_前缀在客户端代码里直接访问环境变量但这种方式在打包时会被内嵌进 JS bundle所以绝对不要用它存 API 密钥、签名字符串这类敏感信息。服务端或构建期用的密钥请放到 EAS environment secrets 或 CI secrets 里运行时才需要的业务配置可以放进extra后通过expo-constants读取。Fastlane 侧也一样ENV[ASC_KEY_ID]这些值建议统一放 CI secrets。如果你在本地调试跑 lane可以新建一个.env文件但必须确保它进了.gitignore。我在一个朋友的仓库里见过.env被提交到 GitHub里面直接躺着一把具备生产发布权限的 Google Play 服务账号 key这种事故一旦发生基本只能紧急撤销并重新生成密钥。5.4 关于 EAS 免费的客观建议回到“EAS 云端构建免费吗”这个问题。我要给一个很实际的结论免费档适合学习和个人项目但当你有多环境、多平台、一天要出好几版的需求时构建排队的时间成本会远超付费套餐的价格。我在一个外包项目上就吃过教训因为预算限制选了免费档测试反馈一个 bug我改完提交构建硬生生在队列里等了快一个小时那一个小时里整个团队都在等包。后来客户发现一个 bug 才损失多少时间完全对不上。所以我的建议是项目初期可以免费档跑通流程一旦进入频繁迭代阶段直接为团队购买按月付费的 plan。比较一下 CI 机器成本和你人工打包的时间成本你会发现这笔钱非常值。6. 工程化的下一步测试与评审如何真正融入流水线6.1 把自动化测试放进构建流程有些团队把 EAS 构建成功当成“可以发版”的唯一信号其实这是远远不够的。构建成功只能说明代码能编译成二进制不能说明它没有破坏核心流程。我们现在的做法是在触发 EAS Build 之前先在 CI 里跑一轮单元测试和关键 UI 测试。React Native 项目可以用 Jest 跑组件测试用 Detox 或 Maestro 跑关键路径的端到端测试。只有测试全绿才允许 EAS 开始构建。好处很明显以前如果测试没过要等构建出来才能察觉现在在更早的阶段就拦住了。而且这类测试并不需要发生在 EAS 内部完全可以在 GitHub Actions / GitLab CI 的 job 里跑。让 EAS 只做它最擅长的事——构建。有一点需要提醒端到端测试不要全部放在每次构建前跑否则流水线会很慢。我一般把测试分层合并前跑静态检查、单元测试和少量冒烟用例合并后的 release 构建前再跑完整的 Maestro 关键流程。这套分层下来既保证质量又不会让工程师等 CI 等到崩溃。6.2 代码评审与质量工具的接入打包发布只是工程化的最后一公里真正决定能不能“放心发”的还是代码合入前的质量关卡。近几年不少工程化平台开始提供 AI 生成测试用例和自动代码 review 的能力比如有些团队用 Harness 之类的平台做 CI/CD顺带就把 AI 自动拆解需求、生成测试用例、代码变更评审接进了流水线。我不认为 AI 评审能替代人工 reviewer但它确实能在你点下 merge 之前把明显的空指针风险、环境配置错漏、硬编码问题先筛一遍。我们在接入这类能力后有一个很明显的感受代码评审的噪音少了人工 reviewer 能专注于架构和业务语义层面的问题。而且这类能力最好和发布流水线联动——比如只有当 AI review 通过、单元测试通过、关键 E2E 全部绿release 分支才允许触发 EAS 构建。这样一来整个发布链路的自动化才闭环从代码提交、静态检查、单测、AI 辅助评审到 EAS 云构建、Fastlane 分发最后再到 TestFlight / Google Play 出包每个环节都有明确的门禁。我个人现在最受用的是把“人”从重复操作里解放出来。以前发版是一个仪式要拉群、同步状态、盯着上传现在发版只是一个 merge action剩下的事情交给流水线。我能做的就是在一个干净清爽的 TestFlight 链接出来之后把它的下载地址丢给测试群然后等反馈。如果你也正被多端打包和人工发布流程折磨我真心建议先把 EAS Fastlane 这套链路搭起来。哪怕第一天只是让 EAS 替你跑一次云构建第二天再让 Fastlane 自动上传也已经比原来手动点 Xcode 高效太多了。工程化不是让你多写几个脚本而是让团队把精力花在真正影响产品的事上。
