嘿，我来帮你把这些容易混淆的版本配置点理清楚，这确实是用expo-updates时常见的疑问！

1. app.json vs AndroidManifest.xml：哪个配置runtimeVersion/sdkVersion更靠谱？ #

没错，runtimeVersion和sdkVersion确实可以在app.json里定义，而且这是expo-cli工作流下的首选方式！

当你用expo build:android或者eas build构建应用时，expo会自动把app.json里的runtimeVersion/sdkVersion同步到AndroidManifest.xml对应的元数据字段里，完全不用你手动修改原生文件。手动改AndroidManifest反而容易和app.json的配置冲突，导致构建出问题，所以优先在app.json里配置就好，既便捷又安全。

2. app.json的version、package.json的version，和runtimeVersion/sdkVersion的区别 #

这三个是完全不同的概念，各司其职：

• app.json里的version：这是用户在应用商店看到的应用版本号（比如1.0.0），对应Android的versionCode和iOS的build number的上层标识，主要用来向用户展示应用迭代进度，也是应用商店区分不同安装包的依据之一。
• package.json里的version：这是你项目作为npm包的版本号，和应用商店、expo-updates都没有直接关系，纯粹是开发者自己用来管理项目内部迭代的标记，比如你可以用来记录自己的开发版本迭代。
• runtimeVersion/sdkVersion：这是expo-updates用来做OTA更新兼容性匹配的核心标识。只有当用户设备上安装的应用的runtimeVersion（或sdkVersion）和你推送的更新包的对应版本完全一致时，更新才会被接收。它们的作用是区分不能通过纯JS更新兼容的版本——比如你修改了原生代码、添加了原生模块、升级了expo SDK版本这类变更，就需要更新这两个值中的一个，避免把不兼容的JS更新推送给老版本的安装包。

3. runtimeVersion和sdkVersion的格式规范 #

• runtimeVersion：格式非常灵活，只要是字符串就行，通常推荐遵循语义化版本规范（比如1.0.0、2.1.3），或者你也可以用自定义的数字串（比如1001）。核心原则是：每次有不兼容的非JS变更时，必须递增这个值（不管是小版本还是大版本，只要能区分开就行）。
• sdkVersion：这个必须严格和你项目使用的expo SDK版本保持一致，比如你用的是expo SDK 44，就必须写"44.0.0"；用SDK 49，就写"49.0.0"。它是绑定expo SDK版本的，用来确保更新包和设备上的SDK环境兼容，所以不能随便自定义格式。

最后补充个小建议：如果你的项目经常做自定义原生修改，或者不频繁升级expo SDK，优先用runtimeVersion，灵活性更高；如果你的项目严格跟随expo SDK版本迭代，用sdkVersion更省心，每次升级SDK时直接同步更新这个值就好。

内容的提问来源于stack exchange，提问作者Clerni