聊 SAP 的前端显示界面先说个有点扎心的现状不少 S/4HANA 项目上线大半年业务同事每天用的还是 SAP GUI 里那几十个事务码Fiori 磁贴只在培训材料里露过一次脸。这事真不能全怪用户守旧界面这一层没打通、没人把来龙去脉讲清楚换谁都懒得动。这篇就把 S/4 HANA 前端显示界面这一层彻底拆开它由哪几块拼起来、和 R/3 时代的界面本质差在哪、想自己搭一套能跑的环境要动哪些开关、磁贴白屏或者数据不对的时候该从哪个点切进去查。不管你是刚从 ECC 转过来的顾问、接盘运维的 Basis还是天天被“页面打不开”追着跑的关键用户看完至少能自己判断问题落在客户端配置、服务激活、OData 通道、还是权限这四层里的哪一层。1. 从三屏客户端到 Fiori前端显示界面的演进脉络1.1 三种界面形态的技术底子很多人把 S/4HANA 的界面变化理解成“换了个皮肤”这是最容易踩的认知坑。R/3 时代的 SAP GUI 走的是三屏架构前端是一台装了 SAP GUI for Windows 的 PC中间是 ABAP 应用服务器上的 Dynpro 屏幕底下是数据库。用户在界面上的每一次回车走的都是“前端把屏幕字段回传ABAP 在 PAIProcess After Input里校验再在 PBOProcess Before Output里重绘屏幕”这一套闭环。所有显示逻辑都在 ABAP 里界面本身非常“薄”它只负责画框和收数。到了 Web Dynpro ABAP 和 ITS 那一代浏览器开始登场但渲染还是服务端在算浏览器拿到的是一堆拼好的 HTML。这个阶段的界面基本只解决了“不用装客户端”的问题体验上并没有什么质变反而因为页面刷新频繁被用户嫌弃。真正的分水岭是 SAPUI5 和 Fiori渲染这件事被搬到了浏览器端服务端只吐 JSON 数据界面怎么画、什么时候画、画哪些字段全由前端 JavaScript 决定。这就意味着同一份数据可以同时喂给桌面浏览器、平板和手机而不用为每种设备单独做屏幕。理解这三段的差异非常关键因为它直接决定了你排查问题的方向。GUI 时代界面出错八成去看 ABAP 和屏幕Fiori 时代界面出错可能是前端资源没加载、可能是 OData 服务没返数据、也可能是浏览器缓存脏了。拿错工具去查两天也查不出来。1.2 S/4HANA 为什么非要把 Fiori 推到台前把界面重构这件事S/4HANA 不是出于审美考虑而是被底层数据模型逼出来的。HANA 是列式内存库S/4HANA 又把大量业务逻辑下沉到了 CDS 视图和 ABAP Managed Database Procedure 里也就是常说的代码下推Code Pushdown。原来在应用层做的聚合、排序、筛选现在数据库自己就干完了返回给上层的已经是算好的结果集。这套变化带来的直接后果是界面不再需要承载复杂计算而是变成“把结果漂亮地摆出来”的角色。传统的 ALV 列表虽然功能强但它对多设备、多角色、图表化展示的支持实在有限。而 Fiori 的设计语言天生就是为“角色化的、卡片式的、能钻取的”展示准备的——一个采购员打开首页看到的是待审批的采购申请、逾期未收货的订单、超预算的提醒而不是一堆菜单树。另一个绕不开的动因是事务码的数量问题。ECC 时代一个成熟系统里存着几千个自定义事务码和报表新员工上手基本靠师父带着走一遍。Fiori 用业务目录Business Catalog和业务组Business Group把应用按角色打包用户看到的就是他岗位需要的那十几个磁贴。这背后其实是权限模型和展示模型的重新对齐也是为什么 Fiori 上线往往要同步梳理 PFCG 角色两件事分不开。1.3 什么场景留 GUI什么场景上 Fiori这是我在项目里被问得最多的一个问题。我的经验是别搞一刀切也别迷信“全 Fiori 化”这种口号。判断标准可以简化成三条使用频次、操作复杂度、数据量级。高频、操作简单、单人完成的场景优先 Fiori。比如审批、查询、状态跟踪这些操作 Fiori 的体验碾压 GUI。低频、逻辑复杂、需要批量录入的场景GUI 依然是主力。典型的就是 MIRO 发票校验、大批量采购订单维护键盘流加多屏幕操作熟练用户用 GUI 的效率是鼠标点磁贴的好几倍。海量数据的报表和分析看情况。Fiori 的分析类应用Analytical App配上 CDS 视图性能很好但如果用户习惯把数据导到 Excel 里二次加工那 GUI 的 ALV 导出反而更顺手。下面这张对照表是我自己整理后发给客户的实际沟通中省了很多口水场景特征推荐界面核心理由需要注意的点审批、待办、状态跟踪Fiori Launchpad角色化聚合一屏看全需要角色与 Catalog 对齐大批量数据录入SAP GUI键盘流高效多窗口配合需保留 GUI 授权与前端部署结构化分析报表Fiori 分析应用CDS 下推图表钻取需检查 OData 分页与聚合性能后台配置与调试SAP GUI事务码直达工具链完整配置类角色一般不开放给业务移动端现场操作Fiori 移动应用响应式布局触屏友好需要单独测试触屏交互路径有一点要提醒Fiori 应用的覆盖面虽然每年都在扩但到现在也仍有一些后台配置和特殊事务没有 Fiori 替代。所以把 SAP GUI 完全关掉这种事除非是公有云版本本身不提供私有部署环境下我一般不建议做。2. 扒开 S/4HANA 前端的四层结构2.1 渲染层SAP GUI、SAPUI5 与它们的宿主前端显示界面这四个字落到具体实现上就是两个渲染引擎在工作。一个是 SAP GUI for Windows或 for Java它是桌面原生程序通过 SAP 自己的通信协议跟应用服务器对话协议层做过压缩和增量传输所以即便带宽一般操作响应也还可以。它的显示逻辑绑定在 Dynpro 屏幕上屏幕的布局、字段属性、流逻辑都写在 ABAP 里的屏幕绘制器就是 SE51 那套东西里。顺便说一个常被问到的细节用屏幕绘制器做输入框时默认的输入字段通常只有一行高度想做成多行得改成带滚动条的文本编辑控件或者在 PBO 里动态调整字段的行高属性。这个坑很多做增强的同事都踩过本质上是 Dynpro 的字段类型决定的不是显示设置的问题。另一个是 SAPUI5它是跑在浏览器里的 JavaScript 框架。Fiori Launchpad 本身就是一个大的 UI5 应用每个磁贴点进去又是一个独立的 UI5 应用应用之间通过 Launchpad 的 Shell 容器做路由和上下文传递。UI5 应用的资源JS、CSS、i18n 文本、图标字体都存放在 ABAP 服务器的 MIME 仓库里通过 HTTP 服务对外提供。所以浏览器第一次打开一个应用慢很可能是在拉这些静态资源这跟数据库性能一点关系都没有。这里还有个概念要拎清楚Fiori 前端可以部署在同一个 S/4HANA 系统里嵌入式部署也可以单独部署一台前端服务器Hub 部署。嵌入式部署省事升级也同步Hub 部署适合有多套后端系统的场景用户只面对一个入口。选哪种取决于你家有几套后端、以及运维团队愿不愿意多养一台机器。2.2 通道层OData 与 Gateway 怎么把数据递到界面浏览器里的 UI5 应用要拿数据走的是 OData 协议中间那一站是 SAP Gateway。Gateway 把 ABAP 里的数据源可能是 CDS 视图也可能是传统的 RFC 函数包装成 OData 服务对外暴露标准的 HTTP 接口。前端发一个带筛选条件的 GET 请求Gateway 转成 ABAP 调用拿到结果再序列化成 JSON 返回。这条通道上有几个点必须记住。第一服务的注册和激活在/IWFND/MAINT_SERVICE里做服务没激活前端点磁贴就是拿不到数据界面上可能只显示一个空列表或者干脆报错。第二OData 的$metadata定义了前端能看到的字段清单如果某个字段在 CDS 视图里被删掉了或者注解里没有标记成可显示前端界面上就找不到它这时候你去查权限是白费功夫。第三$select和$expand决定了每次请求拉多少数据回来前端应用写得粗糙的话很容易一次拉回十几个关联实体的全部字段这是首屏慢的主要元凶之一。排查通道问题的时候/IWFND/ERROR_LOG和/IWBEP/ERROR_LOG这两个事务码是我的第一站。任何一个 OData 请求报错这里都有完整的调用栈和请求参数比在前端按 F12 看网络面板直观得多。想看详细的报文内容还可以开/IWFND/TRACES做一次跟踪把请求和响应原文都抓下来。2.3 配置层Launchpad 的内容组织和目录角色Fiori Launchpad 的内容不是随便拖磁贴排的它有一套三层结构应用App挂在业务目录Business Catalog下业务目录通过 PFCG 角色分配给用户用户再通过业务组Business Group或者空间与页面Spaces and Pages看到排好版的界面。这套结构刚接触的时候很绕但理解了就会发现它比 GUI 的菜单树合理得多因为权限和展示是同源的——你没权限的目录磁贴根本不会出现。内容的维护入口老版本用的是/UI2/FLPD_CUST这个 Launchpad Designer新版本已经推到/UI2/FLPCM_CUST内容管理器了。两者最大的区别是 Spaces and Pages 模式的引入一个空间对应一个业务角色空间下面可以放多个页面页面里再放磁贴和分组。这个模型比老版的“首页分组 磁贴”清晰得多尤其是在用户身兼多职的场景下不同角色的入口不会互相打架。角色侧的操作还是在 PFCG 里做。把对应的业务目录挂到角色菜单里生成参数文件分配给用户用户重新登录后磁贴就出来了。这里有个很常见的坑改完角色忘了做用户比较User Comparison结果角色改了但用户的有效权限没更新表现就是“明明给了权限还是看不到磁贴”。这问题在 GUI 时代就有Fiori 时代一样存在只是现象从“菜单里没这一项”变成了“首页没这个磁贴”。2.4 个性化层用户自己能改的和改不了的Fiori 有个设计原则叫“配置与个性化分离”这条线一定要分清否则运维会很痛苦。配置Configuration是管理员做给所有人看的比如某个页面里放哪些磁贴、顺序怎么排个性化Personalization是用户自己改的比如他可以把不想看的磁贴隐藏掉、调整自己的默认筛选条件、换个主题色。用户个性化数据存在后端所以换台电脑登录还能看到自己排的版。好处是体验连贯坏处是数据会积累。项目上线初期用户到处乱点试出来一堆奇怪的布局后面想统一就会遇到“我这边显示怎么和你不一样”的问题。这时候管理员可以用/UI2/PERS_DEL之类的工具清理掉指定用户的个性化数据把界面恢复到配置的初始状态。主题这块标准主题之外如果有品牌统一的需求可以用 UI Theme Designer 做定制。它可以基于标准主题派生一套自定义配色挂到 Launchpad 上按用户或按角色生效。我的建议是主题定制要克制改得太花哨容易把可读性改坏尤其是状态标识色红黄绿这种有业务含义的颜色别动。3. 从零把一套能看的前端界面跑起来3.1 动手前的检查清单在开始配任何东西之前我习惯先跑一遍检查清单。这一步花十分钟能省掉后面两小时的抓瞎。检查的核心是四项系统版本、ICF 服务状态、证书、用户主数据。检查项主要入口期望结果不通过的表现系统版本与组件系统状态SM51 或状态查看确认 UI 与 Gateway 组件版本部分新应用根本不存在ICF 服务激活状态SICF相关节点为绿色激活浏览器报 404 或 403前端证书STRUST 与 SMICM证书有效且未过期浏览器提示连接不安全用户默认设置SU01 与 SU3语言、日期格式、时区正确界面乱码、日期错乱前端资源与索引UI5 应用索引相关事务索引已生成应用列表搜索不到磁贴版本这件事特别要留意。S/4HANA 的不同 FPS 之间UI 组件的版本差别很大有些 Fiori 应用只在较新的 FPS 上才有。选应用的时候一定要去 Fiori 应用参考库里核对最低版本要求别照着别人的项目清单直接抄很可能是抄了个自己系统上跑不起来的应用。3.2 SAP GUI 侧的连接与快捷方式GUI 这边的配置相对简单但有几个细节值得说。连接信息保存在本地的登录配置里文件名是SAPUILandscape.xml早期是saplogon.ini放在用户目录下的 SAP 配置文件夹里。多套环境开发、测试、生产的时候我一般会按环境前缀命名连接项比如DEV-100、QAS-200、PRD-300避免误连。如果团队里有人要频繁切换系统与其每天点登录面板不如直接做快捷方式。SAP GUI 自带一个命令行工具可以带着系统标识、客户端、事务码、语言一起启动sapshcut.exe -systemPRD -client300 -userYOURID -languageZH -commandMD07这条命令的意思很直白连生产系统 300 客户端用中文登录进去直接打到 MD07 这个事务码。给库存计划员做这么一个快捷方式比教他背菜单路径强太多。注意密码别写在参数里工具会弹窗让你输入这是有意为之的安全设计。还有个容易忽略的显示设置GUI 的本地布局里可以调字体大小、颜色方案、字段宽度这些设置是存在本地 PC 上的。用户反馈“字太小看不清”或者“表格列太窄总要点滚动条”很多时候就是本地布局没调。这类问题不用改系统让用户自己按 AltF12 打开本地布局调整就行。3.3 Fiori Launchpad 的激活与首屏验证Fiori 这条路要动的开关就多了按顺序来。第一步是把 ICF 里相关的服务节点激活。核心的几个节点挂在default_host下面大致涉及/sap/bc/ui5_ui5、/sap/bc/ui2/flp、/sap/bc/ui2/start_up以及对应的/sap/public/...公共资源节点。激活之后浏览器里访问对应路径应该能看到登录页或者 Launchpad 壳子如果直接 404就回到 SICF 检查节点状态和“服务已激活”标记。第二步是验证 Launchpad 本身能不能起。事务码/UI2/FLP会把你带到当前系统的 Launchpad 地址也可以直接在浏览器里拼 URLhttps://your-host:port/sap/bc/ui2/flp?sap-client100sap-languageZH?sap-client 这段千万别漏尤其是多客户端系统不指定客户端可能会跳到默认客户端然后告诉你用户不存在。这一步能打开一个空的或带少量磁贴的首页就说明渲染层和通道层是通的剩下的都是内容配置问题。第三步是内容与角色。先在内容管理器里建空间和页面把标准应用或者自定义应用以磁贴形式放进去然后回到 PFCG把对应的业务目录挂到角色上生成参数文件分配给测试用户。测试用户重新登录后首页应该能看到这些磁贴。如果看不到优先怀疑三处角色的用户比较没做、Catalog 和 Space 的对应关系没配对、以及用户主数据里的语言设置和页面语言不一致。顺带说一个自定义应用的路径。如果你写了自开发的 UI5 应用需要把它部署到系统的 MIME 仓库里再通过 SICF 新建一个对应的服务节点指向该部署路径。应用部署上去以后访问不了先看 SICF 节点建没建、再看向导里配的路径对不对最后才去怀疑前端代码。3.4 桌面与移动端的显示差异怎么处理同一套 UI5 应用在不同设备上的表现可能完全不一样这不是 bug是响应式设计的结果。桌面端屏幕宽表格能铺开显示十几列手机竖屏只有几个厘米框架会自动切换成卡片列表每张卡显示关键字段详细内容要点进去看。如果你发现某个字段在手机上找不到先去确认它是不是被响应式规则隐藏了而不是去查权限。处理移动端显示问题我总结的经验有两条。一是尽量用标准控件搭界面sap.m里的表格、列表、对象页控件都自带响应式行为自己写的 CSS 硬编码宽度在手机上一定崩。二是移动端的筛选和排序要简化别把桌面端那一长串筛选条件原样搬过来用户在小屏上根本不想点。如果企业有移动端管理平台的诉求S/4HANA 这边也有官方的移动入口方案可以让用户从移动设备管理平台里单点进入 Launchpad走的是和桌面一致的认证逻辑。这块涉及设备管理和安全策略实施前一定要和负责移动设备管理的团队对齐别自己闷头配。4. 显示类问题的排查实录4.1 白屏、404、转圈停不下来这三种现象我都遇到过排查思路其实可以做成一个固定的判断顺序从外往里剥。现象最先检查常见根因处理动作浏览器 404ICF 服务节点状态服务未激活或被停用在 SICF 里激活并重启相关节点浏览器 403用户授权缺少服务访问权限用 SU53 定位缺失的权限对象白屏无提示浏览器控制台与服务器错误日志前端资源加载失败或 JS 报错清理缓存后重试查服务端日志一直转圈OData 请求是否返回后端查询超时或服务挂起查 Gateway 错误日志与工作进程状态登录后又跳回登录页认证与会话会话 Cookie 或认证配置问题检查认证顺序配置与浏览器策略白屏这一类我要多说一句很多时候真的就是浏览器缓存惹的祸。UI5 应用的资源更新后客户端如果还拿着旧版本的应用索引就会出现新页面调老资源、老资源里没有新函数的情况表现就是页面加载到一半卡住。标准做法是让浏览器强制刷新快捷键加无痕窗口验证一下就知道是不是缓存问题如果确认是服务端缓存再去清理应用索引缓存并重建。还有一类“转圈”是后端真的慢。这时候要看工作进程的占用情况看是不是所有对话进程都被占满了导致新请求排队。这种情况往往是某个报表查询跑了全表扫描把进程池吃光了表面现象是全系统都在转圈。4.2 数据不对、字段空、中文乱码显示的信息跟预期不一致原因可能分散在四层我一般按这个顺序排字段在不在、数据有没有、格式对不对、语言对不对。字段为空但确实有数据先确认 OData 服务的元数据和$select是否包含这个字段。前端应用如果没有显式请求该字段服务端就不会返回界面上自然显示空白。这一点在自开发应用里尤其常见很多人改完后端视图忘了同步改前端请求参数。中文乱码问题现在比以前少多了但偶尔还会冒出来多半是三种原因用户主数据里的语言设置不对比如设成了英语但页面用中文渲染、前端字体缺失导致特定字符显示成方块、以及自开发界面里对字符集做了手工转换。第一种改用户主数据就行第二种换字体第三种得改代码。金额和数量的显示异常是另一个高频点。金额字段在 ABAP 里存的是按货币小数位换算过的整数前端展示时要根据货币码或者参考字段还原小数位。如果货币字段没带过来界面可能把 12345 显示成 123.45 或者 12345.00看着差了好几个数量级。日期格式同理用户主数据里选的日期格式比如 YYYY.MM.DD 还是 DD/MM/YYYY会直接反映在界面和导出文件里跨地区团队协作的时候很容易因此产生误解这个一定要在项目上线前统一。4.3 首屏慢和列表翻页卡Fiori 的首屏慢跟传统报表的慢完全是两回事得分开看。如果打开 Launchpad 本身就要等十几秒问题在静态资源加载和服务索引上如果是点进某个应用后等数据问题在 OData 查询上。静态资源这块UI5 的应用索引是个关键机制系统会把所有可用的 UI5 应用信息建成索引Launchpad 靠它来快速定位应用资源。索引没建或者过期磁贴搜索和应用启动都会变慢甚至失败。对应的处理是重建索引之后清理浏览器缓存再验证。首次访问某个应用时会有一段时间的预热第二次访问明显变快这是正常的资源缓存行为不用大惊小怪。OData 查询这块$batch用得好不好影响很大。一个页面要显示卡片和明细两块数据如果做成两个独立请求串行发用户就要等两次往返用$batch打包成一个请求虽然数据量一样但往返次数少了体感差别很明显。另外要重点看有没有不必要的$expand把关联实体的全部字段都拉回来是性能杀手。真要深挖单次请求的耗时可以开 Gateway 的跟踪然后拿一次完整的交互去跑把每个环节的时间都记录下来。哪一步吃掉了大部分时间一眼就能看出来。经验上十次有七次问题出在 CDS 视图的查询条件上比如没有有效利用索引或者做了太多计算列。4.4 权限一卡界面就“少块肉”权限引发的显示问题有个典型特征界面能打开但内容不全。有的磁贴不显示有的列表只有一部分数据有的按钮点不了。这类问题用 SU53 能很快定位到缺少的授权对象比对着角色清单一条条翻高效得多。磁贴不显示这一类八成是业务目录没给到用户角色而不是授权对象的问题。授权对象缺了通常是能进应用但看不了数据目录缺了是根本进不去。这两种现象要分开判断方向搞反了会白忙一场。还有一个绕不开的话题是数据导出权限。很多业务部门希望把界面上的列表导出成电子表格做二次分析但导出这个动作在很多企业里是受审计管控的需要单独的授权。做权限设计的时候导出权限要不要放开、放开到什么程度得和财务或者内控部门先谈别等到用户提需求了才发现流程走不通。我的习惯是在角色设计阶段就把这个点提出来让业务方自己决定后面就不会来回扯皮。5. 显示界面与业务场景的对应关系5.1 财务口径从科目余额查看到发票凭证显示财务同事对界面的要求往往最具体核心诉求就两个数据准、导得快。科目余额查看这类需求传统做法是在 GUI 里跑一个行项目报表把结果导出Fiori 这边有对应的分析应用可以直接按科目、按期间筛选图表和明细同屏。发票凭证的显示是另一个高频场景。做过发票校验的都知道一张发票涉及的凭证关系相当复杂拆分记账、冲销凭证、差异科目一层套一层。显示界面上如果不把这些关联关系清楚地呈现出来用户看到的就是一堆互不相干的凭证号。这里有个经验当业务反馈“凭证明明过账了但后续操作打不开”的时候先别急着查后台配置去显示界面上把关联的凭证链条捋一遍看看是不是拆分或者冲销产生了额外的凭证把供应链路切断了。很多所谓的“配置问题”其实是显示层没把关系摆清楚导致用户看漏了。科目余额表这类导出需求还要注意导出格式和字段顺序的稳定性。用户拿到文件后通常有固定的加工模板如果导出字段的顺序每次都不一样他们的模板就废了。这个细节标准功能未必能满足定制的时候一定要问清楚。5.2 物料与采购库存需求清单和价格变更对照库存需求清单这类界面信息密度非常高一屏要放物料、需求日期、库存、预计到货、缺口等一大堆字段。设计或选型的时候核心考量是“能不能一眼看出异常”。我的做法是让关键异常项在视觉上跳出来——缺口用颜色标识、逾期用图标提示而不是让用户自己去比数字。这不是审美问题是效率问题。采购订单的价格变更场景也值得说。业务上经常需要改已有采购订单的价格改完之后大家想看到的是“改前是什么、改后是什么、差异多少”。标准显示界面通常只呈现当前值历史对比要靠凭证历史或者变更记录去翻。如果这个需求很强烈可以考虑做一个侧边栏的自定义展示把变更前后并排放在一屏里。做的时候要注意价格变更涉及条件类型和计算逻辑显示层只做呈现计算还是要在后端算好别在前端拼公式否则口径很容易对不上。5.3 销售与交货日期异常的界面表现与判断交货单上的日期字段是显示层最容易出问题的地方之一。实际操作中会遇到“实际发货日期早于库存入库日期”这类提示用户的第一反应是“系统不让我过账”但真相往往是数据本身的时间顺序不合理。从显示界面角度处理这类问题的思路是先在交货单的日期页签把所有相关日期摊开看一遍——计划发货日期、实际发货日期、货物移动日期、入库日期谁的顺序不对一目了然。很多时候不是某一个字段填错了而是跨系统的数据同步有时间差导致本不该比的日期被拿来比了。这种情况下要确认的是业务时间戳的口径而不是去改界面。顺便提一句销售和采购相关的显示界面里数量单位和小数位的显示问题也特别多。同一个物料在不同单位下的显示精度不一样如果界面没有把单位和精度一起带出来用户很可能把 1000 件看成 1000 个这种错误在小屏幕上尤其容易发生。6. 几个我踩过坑之后的取舍6.1 别指望一套界面通吃所有角色我早期做过一个判断失误的项目为了追求“全 Fiori 化”的整齐把几个重度批量录入的场景也强行搬到 Fiori 上结果那批熟练用户效率掉了三分之一怨声载道最后又给他们在首页加回了 GUI 的入口。这件事给我的教训是界面选型要以用户的实际操作节奏为准不要以管理上的整齐为准。后来我调整了做法先做角色画像把每个角色的高频动作列出来标出哪些是“一天做几十次”的、哪些是“一个月做两次”的。高频动作必须是效率优先哪怕界面长得不那么现代低频动作可以体验优先。这套方法落地之后界面相关的不满反馈少了很多因为用户真正在乎的那些操作路径始终是顺手的。6.2 上线前最该盯的三件事如果只能盯三件事我会盯这三件一是所有 Fiori 应用在目标设备上的实际渲染效果尤其是横屏小尺寸设备很多问题只有在真机上看才暴露二是导出功能的权限和格式这个最容易在上线后被业务追着改三是角色的用户比较我见过不止一次因为漏了这一步导致整个部门看不到新首页。最后分享一个小技巧。排查 Fiori 显示问题时我习惯准备一个“满权限测试用户”把所有相关业务目录都挂给它。问题出现时先拿这个用户试一次如果满权限用户正常那问题在权限如果满权限用户也异常那问题在服务、数据或者前端资源。这一招能把排查范围瞬间砍掉一半比对着日志反复猜快得多。