我之前也遇到过类似的问题，Expo默认的错误提示确实有时候会隐藏node_modules里的细节，试试下面这些方法应该能帮你定位到具体错误来源：

• 启用Expo详细日志模式
  运行项目时添加--verbose参数，让CLI输出更完整的错误栈信息，其中会包含node_modules内的文件路径和行号：

  expo start --verbose
  

  这样错误提示里会明确显示是哪个依赖包的哪个文件抛出了PropTypes相关错误。

• 配置Metro生成完整Source Map
  修改项目根目录下的metro.config.js，确保开启source map生成，让错误栈能精准映射到原始的依赖文件：

  module.exports = {
    transformer: {
      getTransformOptions: async () => ({
        transform: {
          experimentalImportSupport: false,
          inlineRequires: true,
        },
      }),
      sourceMap: true, // 强制生成source map
    },
    resolver: {
      sourceExts: ['jsx', 'js', 'ts', 'tsx'],
    },
  };
  

  修改后重启Expo服务，错误提示会显示更准确的文件位置和代码行。

• 使用Chrome DevTools远程调试
  在Expo开发者菜单里选择「Debug Remote JS」，Chrome会自动打开DevTools。切换到「Sources」面板，点击「Pause on exceptions」按钮（暂停图标旁的小按钮），这样当PropTypes错误触发时，会自动断点到出错的代码位置，直接定位到node_modules里的具体文件和代码行，还能查看上下文变量辅助排查。

• 排查依赖版本冲突
  很多PropTypes错误是因为依赖版本不兼容导致的，比如某些库仍在使用已废弃的React.PropTypes而非独立的prop-types包。可以用以下命令查看项目中所有依赖的prop-types版本：

  # npm用户
  npm ls prop-types
  # yarn用户
  yarn why prop-types
  

  如果发现有多个版本或过时的依赖，可以尝试升级冲突的包，或者用resolutions（yarn）/overrides（npm）字段强制统一版本。

• 临时添加日志到可疑依赖
  如果以上方法都没找到来源，可以临时修改node_modules里可疑包的代码，比如在PropTypes校验的逻辑前添加console.log(__filename)，这样就能在控制台看到具体是哪个文件触发的错误。注意：这个修改会在npm install/yarn install后被重置，仅作为临时排查手段。

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