React Native iOS Crashlytics崩溃排查：Hermes严格模式限制错误

崩溃信息 #

Fatal Exception: RCTFatalException: Unhandled JS Exception: TypeError: Restricted in strict mode, js engine: hermes
0 CoreFoundation 0x827cc _exceptionPreprocess
1 libobjc.A.dylib 0x172e4 objc_exception_throw
2 MyApp 0x38a764 RCTFormatError + 167 (RCTAssert.m:167)
3 MyApp 0x3f9354 -[RCTExceptionsManager reportFatal:stack:exceptionId:extraDataAsJSON:] + 82 (RCTExceptionsManager.mm:82)
4 MyApp 0x3f9b74 -[RCTExceptionsManager reportException:] + 154 (RCTExceptionsManager.mm:154)
5 CoreFoundation 0x20374 invoking
6 CoreFoundation 0x1f3c4 -[NSInvocation invoke]
7 CoreFoundation 0x94cb8 -[NSInvocation invokeWithTarget:]
8 MyApp 0x3ba2c4 -[RCTModuleMethod invokeWithBridge:module:arguments:] + 587 (RCTModuleMethod.mm:587)
9 MyApp 0x3bc33c facebook::react::invokeInner(RCTBridge*, RCTModuleData*, unsigned int, folly::dynamic const&, int, (anonymous namespace)::SchedulingContext) + 197 (RCTNativeModule.mm:197)
10 MyApp 0x3bbf88 ___ZN8facebook5react15RCTNativeModule6invokeEjON5folly7dynamicEi_block_invoke + 298 (optional:298)
11 libdispatch.dylib 0x2370 _dispatch_call_block_and_release
12 libdispatch.dylib 0x40d0 _dispatch_client_callout
13 libdispatch.dylib 0xb6d8 _dispatch_lane_serial_drain
14 libdispatch.dylib 0xc1e0 _dispatch_lane_invoke
15 libdispatch.dylib 0x17258 _dispatch_root_queue_drain_deferred_wlh
16 libdispatch.dylib 0x16aa4 _dispatch_workloop_worker_thread
17 libsystem_pthread.dylib 0x4c7c _pthread_wqthread
18 libsystem_pthread.dylib 0x1488 start_wqthread

应用环境：React Native 0.72.6，仅生产环境崩溃，开发环境无法稳定复现。

咨询问题 #

1. React Native + Hermes环境下，触发"TypeError: Restricted in strict mode"错误的常见原因、编码误区或第三方库问题有哪些？
2. 针对仅生产环境出现的该崩溃，有哪些调试策略与工具可用于定位问题代码？

一、触发"TypeError: Restricted in strict mode"的常见原因 #

1. 编码层面的严格模式违规 #

• 给arguments对象赋值：严格模式下arguments是只读引用，直接写arguments = []会触发错误。
• 使用with语句：严格模式完全禁用with，生产代码压缩时可能残留旧代码中的with逻辑。
• 声明eval或arguments为变量/参数：比如function test(eval) {}或var arguments = 1，严格模式下不允许这类命名冲突。
• 修改不可写属性：比如给window内置属性、或用Object.defineProperty设置writable: false的属性强行赋值。
• 同一作用域重复声明变量：用var重复声明同一变量，开发环境可能被忽略，但生产压缩后会触发严格模式报错。

2. 第三方库或依赖问题 #

• 旧依赖未适配严格模式：部分维护停滞的第三方库（尤其是原生桥接类、工具类）内部使用了严格模式禁止的语法，开发环境容错性高未暴露，生产环境触发错误。
• 依赖版本冲突：不同依赖对严格模式的处理不一致，或某依赖更新后引入违规代码，生产打包合并代码后暴露问题。
• Hermes引擎的严格校验：Hermes对严格模式的校验比JSC更严格，一些在JSC下能运行的违规代码，在Hermes生产环境直接报错。

二、生产环境专属崩溃的调试策略 #

1. 本地模拟生产环境调试 #

• 生产模式打包测试：运行npx react-native run-ios --configuration Release，本地运行生产包尝试复现崩溃。
• 开启Hermes调试日志：在ios/Podfile确保hermes_enabled = true，打包后通过Xcode查看JS层面的错误详情。
• 临时禁用代码压缩：修改metro.config.js关闭生产环境的minify配置，若崩溃消失，说明是压缩过程中代码逻辑被误改。

2. 收集完整JS错误栈 #

• 配置Crashlytics的Sourcemap上传：确保React Native集成Crashlytics时，上传生产包的sourcemap，崩溃后可获取具体JS文件、行号信息。
• 全局错误捕获：在App.js最顶部添加全局错误监听，收集更详细的上下文：

  ErrorUtils.setGlobalHandler((error, isFatal) => {
    if (isFatal) {
      // 上报错误到自定义日志服务，包含错误栈和当前页面信息
      console.error('Fatal JS Error:', error.stack);
    }
  });
  

3. 逐步排查代码与依赖 #

• 二分法回滚代码：将最近上线的代码拆分，逐步回滚测试，定位触发崩溃的代码块。
• 依赖版本回退：排查最近更新的第三方依赖，逐个回退到稳定版本，测试是否解决崩溃。
• ESLint严格模式扫描：启用ESLint的strict规则，批量扫描代码中的严格模式违规语法，比如使用eslint-plugin-react的相关规则。

4. Hermes特定工具 #

• Hermes Inspector连接生产设备：生产打包时保留调试端口（修改Xcode Build Settings关闭调试信息优化），通过Hermes Inspector连接运行中的生产应用，实时查看JS错误。
• 解析Hermes字节码：使用hermes disassemble命令解析生产环境的字节码文件，查找违规指令或逻辑。

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