用人为延迟照出真相：SAP Fiori 里 OData 同步请求为什么看起来像异步

在一次 CRM 项目排查里，同事抛给我一个看似简单、却很容易被直觉带偏的问题：在 Fiori 应用《My Opportunity》里，用来读取机会列表项上公司 logo URL 的那条 OData 请求，明明被配置成async = false（也就是同步），可他在界面上观察到的现象却像异步——就算后端还没把图片 URL 返回，用户仍然能继续点别的、滚动列表、做其他操作，页面似乎并没有被阻塞。

这类争论在 SAPUI5 / Fiori 开发团队里并不少见：代码配置写得清清楚楚，但人的眼睛会被请求很快这个事实欺骗。更有意思的是，越是在内网、越是在性能好的系统上，越容易误判。

下面我把当时的分析和验证过程完整梳理出来，顺带把 SAPUI5 里同步与异步请求的底层含义、为什么会产生视觉错觉、以及在真实业务里更推荐的实践方式讲透。

场景复盘：logo URL 请求到底在做什么

在很多 CRM 类 Fiori 应用中，列表里每条业务对象（机会、线索、客户）旁边都会展示一个图标或 logo。为了做到数据可配置、图片可维护、按需加载，常见做法是：

• 列表主体数据（机会 ID、描述、金额、状态）走一次 OData 查询；
• logo 本身不直接把图片二进制塞进列表响应里，而是给出一个可访问的 URL（或媒体流地址）；
• UI 端在渲染到某一行时，再触发额外请求去拿到图片地址或图片内容。

这种拆分能减少首屏 payload，也更利于缓