SAP Fiori On-Premise中HTTP 200与304状态码深度解析与缓存排错指南

最近在帮一个客户排查 SAP Fiori On-Premise 系统的性能问题时，我盯着 Chrome Network 面板里一串 HTTP 状态码看了很久——同一批资源，一会儿 200，一会儿 304，中间还夹着几个 403。很多人看到 304 会以为"是不是出错了"，看到 200 就以为"服务器正常返回了"，但在 SAP Fiori On-Premise 环境里，这两个状态码背后牵扯着浏览器缓存、Gateway 缓存、ABAP 后端、甚至 CSRF Token 校验的一系列逻辑。

这篇文章我想把 200 和 304 掰开揉碎地讲清楚：它们在 Fiori 系统里分别来自哪里、由哪些缓存节点决定、怎么快速排查，以及和 CSRF 403、沙盒启动失败这些问题有什么关联。内容面向 Fiori 管理员、Basis 顾问和开发人员，也会照顾到刚接触 Fiori 架构、对 HTTP 缓存机制还不太熟的读者。

1. 先说结论：200 和 304 在 Fiori 请求里分别代表什么

1.1 不是所有 200 都来自服务器

HTTP 200 OK 的基础语义是"请求成功，响应体里有完整内容"。但在浏览器里，你看到的 200 其实分两种情况：

• 网络面板里的 200，Size 列显示具体的字节数，说明这次请求真正到达了服务器（或者代理），服务器返回了完整资源，响应体里有数据。
• 网络面板里的 200 (from memory cache) 或 200 (from disk cache)，说明浏览器没有发起网络请求，直接从本地缓存里把资源取了出来，状态码沿用了缓存里记录的 200。这在页面加载日志里非常常见，尤其是 Fiori Launchpad 这种重度前端应用，二次打开时大量静态资源都是这种"假 200"。

真正由服务器返回的 200，在 Fiori 场景里通常意味着：

• 首次加载某个 JS 或 CSS 文件时，服务器返回完整文件内容。
• OData 请求成功返回业务数据，响应体包含 XML 或 JSON 数据。
• 用户个人信息、个性化设置等动态请求成功返回。

1.2 304 是"确认没变"，不是错误

304 Not Modified 的语义是：浏览器带着缓存资源的验证信息（ETag 或 Last-Modified）去问服务器"这个资源还能接着用吗"，服务器检查后发现资源没变化，于是返回一个没有响应体的 304，告诉浏览器"直接用你本地那份吧"。

所以 304 的第一条性质是：它确实是一个网络请求，服务器参与了这个过程，但没有传输完整资源。第二条性质是：304 不等于"页面出错"，它是 HTTP 缓存协商机制里的正常响应，专门用来节省带宽。

在 Fiori On-Premise 里，304 主要出现在这些地方：

• Fiori Launchpad 启动时加载的 SAPUI5 核心库，比如 sap-ui-core.js、sap.m 库文件、主题 CSS。
• OData 服务元数据请求，比如 $metadata，如果网关配置了缓存，第二次请求很可能返回 304。
• 某些通过 BSP 应用提供的静态页面资源。

我把常见请求类型和典型状态码整理成了下表，方便后续排查时对照：

2. Fiori On-Premise 缓存链路：谁在决定 200 还是 304

2.1 浏览器缓存的两个层级

在分析 Fiori 请求前，先要理解浏览器缓存的两个概念，否则后面所有的排查都会跑偏。

第一层是强缓存。服务器在响应头里返回 Cache-Control: max-age=3600，表示这个资源一个小时内可以直接用本地缓存，不用问服务器。浏览器