React Native小型图片CRUD应用AWS S3请求量过高排查求助

一、先搞定CloudWatch的指标查看问题 #

• 默认S3的请求指标是关闭状态，得手动开启：进入S3控制台找到目标桶，切换到「指标」标签，点击「创建指标」，开启对应桶的「请求指标」（支持针对整个桶或特定前缀）。开启后等几个小时，就能在CloudWatch里看到Get、Put等各类请求的统计数据，精准定位哪种请求占比最高。
• 开启S3访问日志更直接：在桶的「权限」->「访问日志」里配置，日志会存在你指定的另一个S3桶中，每条日志都包含请求类型、发起IP、请求时间、目标对象路径等细节，能直接查到重复请求的来源。

二、针对react-native-fast-image的重点排查 #

这个库本身带缓存，但配置或使用不当很容易导致重复请求：

• 检查缓存配置：FastImage的cache属性有没有设置成FastImage.cacheControl.web（遵循S3返回的缓存头）或合适的缓存策略，如果完全没配置，可能每次加载都走网络请求。
• 检查图片URL的稳定性：如果URL里带了随机参数、动态timestamp之类的内容，会导致缓存失效，FastImage每次都会重新请求S3。
• 列表渲染场景：如果在FlatList/ScrollView里展示图片，有没有做懒加载？有没有给列表项设置稳定的key？要是key不稳定或者没做懒加载，滚动时组件反复渲染，会触发重复请求。
• 离线测试验证：把设备断网，看已加载过的图片能不能正常显示。如果很多图片加载失败，说明缓存没生效，所有请求都是走网络。

三、代码层面的隐藏问题排查 #

• 检查组件生命周期：比如useEffect的依赖项设置是否合理？如果依赖项频繁变化，会导致每次组件更新都重新触发图片加载逻辑。
• 排查全局状态：如果图片URL存在Redux、Context这类全局状态里，有没有被频繁更新？状态更新会触发组件重渲染，进而发起新的图片请求。
• 真机抓包验证：用Charles或Fiddler抓真机的网络请求，过滤S3的域名，统计请求次数和重复的URL，直接定位哪些图片被反复请求。

四、DynamoDB与S3的关联问题 #

DynamoDB的查询本身不会直接触发S3请求，除非你的代码里写了关联逻辑：比如查询DynamoDB拿到图片URL后立刻发起S3请求；或者DynamoDB的Lambda触发器里有操作S3的逻辑——这种情况可以去看Lambda的调用次数和执行日志，就能确认是否是这部分导致的请求量增加。

五、其他常见诱因 #

• 第三方爬虫或未授权访问：查看S3访问日志里的发起IP，如果有大量非用户设备的IP，可能是爬虫在爬你的S3资源。可以给S3桶配置IAM策略，只允许你的App通过特定身份访问，或者用预签名URL（而非公开可读）来限制访问。
• 错误重试逻辑：如果代码里有请求失败自动重试的逻辑，而S3偶尔出现网络波动返回错误，会导致重复请求叠加，进而拉高请求量。

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