无TypeScript的React Native项目运行时报Could not get BatchedBridge错误

你遇到的全场景统一报错——不管是旧JS项目、新建无模板JS项目，只要在Android虚拟设备运行就触发Could not get BatchedBridge, make sure your bundle is packaged correctly——本质是之前安装react-native-template-typescript的操作污染了全局级别的配置、缓存、构建规则。这类残留不属于单个项目的代码或依赖范畴，不会因为你删node_modules、重装项目依赖、在项目内清缓存被清除，所以之前尝试的所有常规排查操作全部没有触达问题根源。你当前使用的react-native-cli 2.0.1本身缺少不同模板的配置隔离逻辑，是触发该类全局污染的版本基础。

• 清除全局CLI的默认模板绑定
  旧版react-native-cli会把最后一次使用的模板写入全局用户配置，导致你不带参数执行npx react-native init时自动套用TS模板的打包规则。依次执行以下命令清除残留：
  npm config delete react-native-template
yarn config delete react-native-template
• 清空全局非项目级的Metro缓存
  旧版RN的Metro缓存默认存储在系统临时目录，不属于单个项目的内部文件，之前在项目目录内执行的清缓存操作无法触达这部分残留：
  执行rm -rf $TMPDIR/metro-*（Windows用户对应操作是删除%TEMP%路径下所有带metro-前缀的临时文件）
  执行watchman watch-del-all清空所有文件监听映射记录，避免之前TS项目的文件路径被错误关联到其他项目的打包流程中
• 清除Gradle层的构建缓存污染
  虚拟设备上报错的直接触发点是打出来的debug安装包没有内置可被识别的JS bundle，这是全局Gradle缓存错误复用了TS项目的打包规则导致的：
  进入任意RN项目的android子目录，执行./gradlew clean清理项目内的构建产物
  删除全局Gradle缓存中RN相关的转换残留：rm -rf ~/.gradle/caches/transforms-*
• 排查Metro端口的异常占用
  安装TS模板的过程可能会常驻一个无响应的旧版Metro进程占用默认8081端口，导致你新启动的开发服务根本没有拿到端口权限，虚拟设备连接的是没有有效bundle的空Metro服务：
  执行lsof -i :8081（Windows用户执行netstat -ano | findstr "8081"）定位占用8081端口的进程，直接终止该进程
  重新启动开发服务时强制使用无缓存模式启动：yarn start --reset-cache --no-cache
• 离线打包验证构建流程
  确认Metro正常启动后，在项目android目录下执行./gradlew assembleDebug打一次离线debug包，安装到虚拟设备验证。如果应用可以正常加载运行，说明残留的污染配置已经完全清除。

额外提示：react-native-cli 2.0.1为已停止维护的旧版本，缺少全局配置隔离能力，后续可切换到社区维护的@react-native-community/cli，降低同类全局配置污染问题的复发概率。

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