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，表示这个资源一个小时内可以直接用本地缓存，不用问服务器。浏览器在有效期内再次请求这个资源，根本没有网络请求，Network 面板显示 200 (from disk cache) 或 200 (from memory cache)。Fiori 里的静态资源如果配置了长缓存，二次启动时大量资源都会走这一层。

第二层是协商缓存。服务器可以设置 Cache-Control: no-cache（注意，no-cache 不是不缓存，而是"每次使用前必须经过服务器确认"），或者资源的强缓存过期后，浏览器会带着 If-None-Match（对应 ETag）或 If-Modified-Since（对应 Last-Modified）头发起一次条件请求。服务器检查资源版本：

• 没变化：返回 304，响应体为空，浏览器继续使用本地缓存。
• 有变化：返回 200，响应体带着最新资源，浏览器用新内容替换旧缓存。

简单类比：强缓存像是"我跟你约好了一个月内不用再问，直接照旧执行"，协商缓存像是"每次开会前我都要问你一句，方案没变我就不用重新打印，方案变了就换新文档"。

2.2 Fiori On-Premise 里参与缓存的节点不止浏览器一个

Fiori On-Premise 请求从浏览器到 ABAP 后端，通常要经过这么几层：

1. 浏览器缓存。
2. SAP Web Dispatcher 或反向代理（如果有）。
3. SAP Gateway 的 ICM（Internet Communication Manager）层。
4. ABAP 应用服务器层面的 OData 缓存或 BSP 缓存。

静态资源请求（如 /sap/bc/ui5_ui5/ 路径下的 JS/CSS）通常由 ICM 直接响应，ICM 会根据文件系统属性自动生成 ETag。动态 OData 请求（如 /sap/opu/odata/ 路径）则进入 Gateway 框架，由 /IWFND 相关组件处理，缓存行为受 OData 服务配置影响。

所以在 Fiori On-Premise 环境下，同一个 304 可能是浏览器和服务器的直接协商结果，也可能是反向代理或 Web Dispatcher 在中间替服务器回答的"没变"。排查时先分清是哪一层返回的，比直接改代码更高效。

2.3 ETag 和 Last-Modified 在 SAP 网关里是怎么生成的

ETag 是实体标签。对于静态文件，比如 SAPUI5 的 JS 库，ICM 会根据文件大小、修改时间等信息生成一个 ETag。文件一旦更新，ETag 就会变，浏览器下次带旧 ETag 来问时，服务器发现不匹配，就返回 200 + 新文件，而不是 304。

OData 服务的情况不太一样。SAP Gateway 默认对很多 OData 响应不会主动设置长缓存，更多时候是 Cache-Control: no-cache, no-store，或者根据 sap-cache-control 扩展头来配置。我在实际项目里见过不少客户把 $metadata 请求交给网关缓存，这种情况下第二次请求就会拿到 304。

想快速确认某个资源当前返回的是什么头，直接用 curl 看响应头最方便：

bash复制# 查看 SAPUI5 静态资源的响应头
curl -I -k "https://<fiori-host>:<port>/sap/bc/ui5_ui5/ui5/ushell/resources/sap-ui-core.js"

# 查看 OData 服务的 $metadata 响应头（需要传入认证信息）
curl -I -k -u USER:PASS "https://<fiori-host>:<port>/sap/opu/odata/sap/API_BUSINESS_PARTNER/\$metadata"

注意 $ 符号在 bash 里要转义，或者把 URL 用单引号包起来。看响应头里的 Cache-Control、ETag、Last-Modified、X-CSRF-Token 这几个字段，基本就能判断出当前请求走的是强缓存还是协商缓存，以及 304 的判定依据是什么。

3. 从 Network 面板到后端：200/304 的实际排查链路

3.1 先学会区分 memory cache、disk cache 和真正的 304

很多同事一打开 Chrome DevTools 的 Network 面板，看到状态码是 200 就不看了，这是不对的。对 Fiori 应用来说，要重点看 Size 这一列：

• from memory cache：从内存缓存读取，没有网络往返。优点是快，缺点是浏览器关闭或标签页释放后可能失效，二次打开 Launchpad 时非常常见。
• from disk cache：从磁盘缓存读取，没有网络往返。跨会话加载静态资源时经常出现。
• 304 Not Modified：有网络往返，但响应体为空，服务器确认资源未变更。点开这个请求，能看到浏览器在请求头里带了 If-None-Match 或 If-Modified-Since，响应头里只有类似 ETag 的验证信息，没有实际内容。
• 一个具体数字：比如 sap-ui-core.js 有几 MB，如果 Size 列显示 (from disk cache)，说明这次加载完全不占带宽；如果显示 304，说明省了这几 MB 的响应体，但请求还是消耗了几十到几百毫秒的网络时间。

调试 Fiori 性能问题时，我的习惯是先打开 Network 面板的 "Disable cache" 勾选项，再刷新一次页面。这样能强制浏览器放弃所有本地缓存，把真实的服务器响应暴露出来。如果禁用缓存后页面加载变慢很多，说明线上用户大概率依赖了缓存，那么 304 和 from cache 的分布就有分析价值；如果禁用前后差异不大，说明应用本身的请求设计才是瓶颈。

3.2 Fiori 请求级调试的几条实际路径

结合"怎么 debug"这个高频问题，我把 Fiori 排错里的请求级调试路径整理一下：

第一，在浏览器层面看请求细节。右键点击 Network 面板里的任意请求，选择 "Copy as cURL"，可以快速在命令行里复现同一个请求，非常适合排查缓存、认证和代理问题。Fiori 的 OData 请求通常需要 Cookie 和 CSRF Token，直接复制 cURL 出来的命令很完整，不需要手工拼请求头。

第二，启用 SAPUI5 调试模式。在 Fiori 应用 URL 后面加上 sap-ui-debug=true，SAPUI5 会加载非压缩版本的 JS 库，源码可读性更好，方便在 Sources 面板里打断点，定位是哪一段代码发起了某个请求。也可以配合 sap-ui-language=EN 切换语言，避免非英文环境下错误信息不易搜索的问题。

第三，看后端日志。前端 Network 面板能确认"请求发出去了、状态码是什么、耗时多长"，但"服务器为什么这么回答"要到后端的日志里找：

• 事务码 /IWFND/ERROR_LOG：查看 Gateway 框架记录的 OData 错误日志。
• 事务码 SMICM：查看 ICM 进程的 HTTP 请求记录，能确认某个 304 是不是由 ICM 直接返回的，还是落到了 ABAP 层。
• 事务码 ST22：看 ABAP short dump，如果请求导致后端异常，这里会有记录。

第四，用 HAR 文件保存完整的请求链路。在 Network 面板空白处右键，选择 "Save all as HAR with content"，导出的 HAR 文件包含了所有请求的 URL、状态码、耗时、响应头、Cookie 等关键信息。遇到难以现场复现的现场问题时，让用户把这个文件导出发给你，比截图高效得多。

3.3 一个真实案例：静态资源一直 304，导致用户始终加载旧版本

之前处理过一个 Fiori 升级后的"旧界面残留"问题。客户把 SAPUI5 版本从 1.71 升级到 1.96，但部分用户反馈登录后看到的还是旧版界面。第一反应是浏览器缓存没有刷新，让用户清缓存，问题依旧。

抓了一份 HAR 文件分析后发现，用户的浏览器加载 sap-ui-core.js 时拿到的是 304，但本地缓存里的文件确实是旧版本。为什么服务器会确认"没变"？因为请求 URL 没有带版本参数，而 ICM 上这个路径的文件 ETag 没有发生变化。再往下一查，发现是 IT 部门在 Web Dispatcher 上配置了静态资源缓存规则，把 /sap/bc/ui5_ui5/ 路径下的资源缓存到了边缘节点。边缘节点上的旧文件一直没失效，于是每次请求都从边缘节点返回 304，浏览器也就一直沿用旧版本。

这个案例说明：304 虽然省流量，但在 Fiori 升级场景里可能变成"旧版本保护伞"。碰到升级后资源不更新的情况，除了清浏览器缓存，还要检查中间层代理是否缓存了旧资源，以及静态资源 URL 是否包含版本标识。

4. 200/304 的性能账：命中率、白屏时间与缓存策略优化

4.1 一次 Fiori 启动，资源消耗到底有多大

一个典型的 Fiori Launchpad 页面，启动时发起的请求数量非常可观。我统计过一个中型项目的生产环境，一次冷启动大约产生 200 到 300 个 HTTP 请求，其中静态资源请求占 80% 以上。SAPUI5 的控件库拆分成大量 JS 文件，虽然总体积比传统 Web 页面大一个量级，但正因为文件多、体积大，缓存的价值也格外突出。

从性能角度把三种情况做个对比：

这里关键的一点是：304 虽然省了带宽，但仍然受网络延迟 RTT 制约。如果用户在一个 RTT 是 50ms 的网络里，100 个资源都返回 304，光这些请求的等待时间叠加起来就可能达到几秒钟。所以在网络条件差、用户跨地域访问 Fiori 的场景下，单纯依赖 304 并不够，应该尽量让更多资源命中强缓存，实现零请求往返。

4.2 怎么判断当前系统的 304 比例是否合理

在 Chrome DevTools 的 Network 面板里，可以先按 "Size" 排序，看看有多少请求是 from disk cache、多少是 304 Not Modified、多少是完整 200。更精确的方法是导入 HAR 文件后用脚本统计：

bash复制# 用 jq 分析 HAR 文件中的状态码和缓存字段（示例）
jq '.log.entries[].response.status' fiori.har | sort | uniq -c
jq '.log.entries[] | {url: .request.url, status: .response.status, cache: .response.content.size}' fiori.har | head -50

我通常关注两个比例：静态资源的强缓存命中率，以及动态 OData 请求的 200 占比。静态资源强缓存命中率太低，说明 Cache-Control 配置有问题；OData 请求出现大量 304 则需要警惕，因为业务数据很少应该被缓存，特别是带权限校验的数据，304 反而可能意味着缓存配置过于激进。

4.3 实战中的缓存策略调整思路

针对 Fiori On-Premise 的缓存优化，一般的做法分成静态资源和动态请求两条线。

静态资源方面，SAPUI5 在发布后 URL 里通常自带版本号，比如 /resources/sap-ui-core.js 对应某个版本路径。版本号不变，文件内容不会变化，所以这类资源可以放心设置长缓存，比如 Cache-Control: max-age=31536000, immutable。这样用户再次打开应用时，大量资源直接命中强缓存，根本不发请求。真正要更新时，SAPUI5 版本升级会让 URL 路径变化，旧缓存自然失效，不会出现"升了级但浏览器还在用旧资源"的问题。

OData 动态请求方面，不建议无脑设置长缓存。主要有两个原因：

• 业务数据的实时性无法保证，一个单据状态改了，用户看到的还是旧值，容易引发数据一致性问题。
• 缓存如果包含个人敏感信息，一旦浏览器被多人共用，数据泄露风险很高。对于这类请求，应该显式设置 Cache-Control: no-store，而不是依赖默认行为。

比较折中的方案是只缓存 OData 元数据，比如 $metadata 请求。这类数据相对稳定，且没有业务敏感信息，缓存 5 到 10 分钟能明显减少重复请求。具体可以在 SAP Gateway 的 OData 服务配置里调整缓存相关参数，或者通过 Web Dispatcher 规则对 $metadata 路径做定向缓存，但要注意不同版本 Gateway 的配置方式有差异，改之前先确认当前系统版本支持哪些选项。

5. 状态码联排：403 CSRF 与沙盒启动异常中的 200/304 隐藏线索

5.1 403 CSRF：为什么 304 会让 Token 获取失败

Fiori 的 OData 写操作（POST、PUT、DELETE）默认受 CSRF 防护保护，这个防护机制和 304 之间有个很容易踩的坑。

正常情况下，客户端第一步会先发一个 GET 或 HEAD 请求去"取 Token"，服务器在响应头里返回 X-CSRF-Token: Fetch。第二步，客户端在写请求中带上 X-CSRF-Token: <第一步拿到的值>，服务器校验通过后执行操作。如果 Token 缺失或失效，服务器返回 403 Forbidden。

问题出在这个"第一步"上。如果这个 GET 请求被浏览器或代理缓存命中，浏览器直接返回了本地缓存的响应（可能是 200 from cache），或者返回了一个 304，那么响应头里可能压根没有 X-CSRF-Token 字段——本地缓存响应里存的头是旧的，304 的响应体是空的。结果前端拿到值为 undefined 的 Token，写请求自然 403。

在实际项目中，SAPUI5 自身的 OData 模型会处理这个问题，但自定义的 jQuery.ajax 或 fetch 调用很容易忽略。排查步骤是：打开 Network 面板，找到获取 CSRF Token 的请求，点开查看 Response Headers 里有没有 X-CSRF-Token；如果请求显示 304 或 from cache，说明缓存干扰了 Token 获取，需要在请求行上追加时间戳参数，或者显式设置 cache: false，确保每次都是真实请求到服务器。

5.2 Fiori 应用沙盒启动失败：状态码分布能告诉你什么

"Fiori 应用沙盒启动"通常指在开发环境或测试环境里，直接打开一个 Fiori 应用的组件测试页面，不经过完整 Launchpad 壳子。启动失败的现场，状态码比报错文本更能说明问题。

沙盒页面启动时，一个典型的加载序列是：

1. sap-ui-core.js：SAPUI5 核心库。
2. 应用自己的 Component-preload.js：预先打包好的组件 JS。
3. manifest.json：应用清单，包含路由、数据源、模型配置。

如果 Component-preload.js 返回 403，最常见的原因是该路径的访问权限配置不对，SICF 服务未激活或用户缺少权限。如果返回 404，通常是应用构建时没有正确生成 preload 文件，或者部署目录结构不对。如果返回 304，但页面依然启动失败，就要怀疑本地缓存的组件代码和服务器上的 manifest 版本不一致，导致应用内部组件依赖冲突。

处理沙盒启动问题，我的套路是固定的：

1. 打开无痕窗口，或者勾选 Network 面板的 Disable cache 后刷新，排除本地缓存干扰。
2. 看 Console 面板的 JS 报错，重点记录第一个报错，因为后续报错基本都是连锁反应。
3. 在 Network 面板里按状态码排序，把所有 4xx 请求列出来，逐个确认 URL 路径和服务是否正常。
4. 如果状态码看着正常但页面还是白屏，启用 sap-ui-debug=true 重新加载，看模块加载日志卡在哪一步。

5.3 一个简单的三段判断法

综合 200、304、403 这几个状态码，我在排错时习惯用下面的判断逻辑快速缩小范围：

这张表不是标准答案，但大多数 200/304/403 混在一起的问题，用这三步都能定位到一个可下手的点：先区分缓存类型，再确认服务器返回头，最后查后端日志。

6. 我的一点排错心得

做 Fiori On-Premise 排错做得越多，越觉得 HTTP 状态码只是表面现象，真正决定问题走向的永远是响应头和缓存策略的配合关系。这里分享几点实际工作中的体会。

第一，不要把 304 当成错误，但也不要把 304 当成"性能好"。304 表示协商缓存生效，省了带宽，但没省网络往返。在静态资源多、网络延迟高的环境里，优化目标是让更多资源直接命中 from disk cache，而不是停留在 304 层面。

第二，调试时先解决缓存干扰，再谈后端问题。很多"改了代码没生效"的现场，最后都是浏览器或代理缓存惹的祸。用无痕窗口、勾选 Disable cache、或者临时给 URL 加时间戳参数，能过滤掉大部分缓存因素。排除缓存后再看后端日志，定位会快很多。

第三，关注响应头比关注状态码本身更有价值。看到请求的状态码后，顺手点开看一下 Cache-Control、ETag、X-CSRF-Token、Content-Type 这几个字段，往往能直接解释"为什么是 200 而不是 304"或"为什么 403"。比如同样是一个 200 的 OData 请求，响应头里带不带 X-CSRF-Token: Fetch，直接决定了下一个写请求是成功还是失败。

第四，一个小技巧：调试 Fiori 请求时，遇到说不清道不明的 OData 问题，先把请求在 Network 面板里右键复制成 cURL，在命令行里去掉 Cookie 和 Token 分步执行，看哪一步开始报错。这个方法在判断问题是出在认证、CSRF 还是数据查询上，比我见过的很多复杂的调试工具都直观。