接口在正常网络下返回数据，只是移动端数据流程的一种状态。用户可能在地铁里断网、切换筛选后看到旧结果，或者保存失败丢失刚输入的内容。expo-data-fetching 针对这些场景组织请求、缓存和界面状态，适合已有列表或表单的完善工作。
先把 Expo 知识接入 Agent
Codex 用户在终端运行下面的 Expo 官方插件命令，也可在 Codex 的 /plugins 中找到 Expo。Claude Code 用户改用 claude plugin install expo@claude-plugins-official。两种插件都会带入 Expo Skills 与 MCP 配置；其他支持 Agent Skills 的客户端可用 npx skills@latest add expo/skills --skill '*'，按提示选择客户端并刷新会话。安装插件本身不会构建或发布应用。
codex plugin add expo@openai-curated
打开已有 Expo 项目，直接说“使用 expo-data-fetching”，并给出当前 SDK、目标平台及相关文件。
从当前数据方案继续，而不是重建一套
以下是可按项目调整的首次输入：
使用 expo-data-fetching 检查订单列表及编辑表单。项目已有 React Query，目标平台是 iOS/Android。保留当前 API，补齐首次加载、空结果、后台刷新失败和断网状态；保存失败保留输入，避免重复提交。核对 query key 是否包含筛选条件，并说明环境变量和登录令牌分别放在哪里。
先告诉 Agent 项目使用 fetch、React Query 还是 SWR，并提供接口约定、认证方式和相关屏幕。已存在的缓存层应优先复用。给一个具体错误场景，例如“下拉刷新失败时列表消失”，比只要求“优化请求”更容易得到可验收的修改。
分清没有数据与正在刷新
首次请求尚未完成不等于空结果；已有缓存时，刷新失败也不一定需要把整屏内容清空。让 Agent 分别设计首次等待、空列表、带旧内容的刷新和不可恢复错误。query key 应包含影响结果的参数，避免切换筛选后错误复用另一组数据。
使用 fetch 时需要检查响应状态，HTTP 错误并不会自动成为被拒绝的 Promise。保存操作还应避免重复提交，失败后保留输入；选择乐观更新时，要明确如何回滚与显示失败。缓存时长和重试次数应由业务数据特点决定，不是复制某个示例里的固定数字。
配置与凭据各有位置
公开 API 地址可以通过 EXPO_PUBLIC_ 环境变量传入，但这些值会进入客户端包，不适合存私钥。官方文档要求用明确的 process.env.变量名读取，动态索引或解构不会按同样方式替换。更改本地值后还需要完整刷新应用，避免把旧值误判为代码问题。
认证令牌和刷新流程需要按移动端存储方案处理；多个请求同时过期时，也要避免重复刷新造成竞争。
如果 Agent 建议在路由文件里使用 loader 或 useLoaderData，先确认目标平台与 SDK。Expo 的 Router data loader 目前只面向 Web、要求 SDK 55+；原生 iOS/Android 屏幕继续使用 React Query 或 fetch。Web 项目还需在 app.json 或 app.config.js 核对 web.output：server 与 static 都需要启用 unstable_useServerDataLoaders，server 模式还需启用 unstable_useServerRendering。别把 Web loader 当作移动端列表的通用替代方案。
用失败场景验收
完成后测试正常响应、空数组、服务端错误、慢网、断网与保存失败，再检查切换条件时是否出现过期结果。期望得到的是清楚的数据状态、请求与缓存调整，以及可重跑的测试步骤。技能不会替接口保证正确性，但可以让应用在接口不顺利时仍给用户合理选择。
用一条失败后的重试路径检验数据状态
可以给 Agent 一个可复现流程：打开订单列表后切换筛选，等待新结果时保留旧内容或显示明确加载状态；断网刷新时提示失败但不清空已有订单；恢复网络后重试并检查筛选条件仍然一致。对于保存表单，先输入一段尚未提交的备注，模拟服务端错误，确认输入还在，再重试一次。只测成功请求很难发现最伤用户的丢稿问题。
如果使用 React Query，首次请求和后台刷新要分别判断。一个被暂停的查询可能没有数据，也并非正在加载；界面需要解释缺少登录、离线或等待初始化的真实原因。认证信息如果要从本地存储恢复，先完成 hydration 再做路由跳转，否则冷启动和深链接都可能短暂进入错误页面。
查询条件与缓存键必须一起变化
如果订单页同时有状态、日期和搜索词，query key 应包含所有会影响返回结果的条件。测试时先看“待处理”，再切到“已完成”，迅速切回，观察是否闪出上一组数据。请求取消与缓存策略应结合项目现有库处理，不能仅靠隐藏旧列表来掩盖数据串组。空状态文案也要区分“目前没有订单”和“筛选没有结果”，让用户知道下一步是创建、清除筛选还是稍后重试。
上传卡住时先确认请求有没有结束
有开发者在 Expo SDK 56.0.21 的 iOS 实机开发包中复现过 expo/fetch 上传遇到服务器中途断开、返回不完整响应时 Promise 长时间不完成。为上传设置明确的 AbortSignal 超时，并把“网络错误、用户取消、服务器响应不完整”分开显示；必要时在相同设备上用 expo-file-system 的上传 API 做对照。这个案例说明要测试失败路径，不能据此断言每个 Expo SDK 都有同一故障。