刘芷宁我自己第一次被 Spaces 与 Pages 折腾到凌晨，是在一个 S/4HANA 项目的 Fiori Launchpad 2.0 升级测试里。开发系统的采购员工作台明明配置得整整齐齐，等我把同一个请求传到质量系统，用户登录后却连 Space 都看不到。主管问我“页面配置怎么还能传丢？”，我当时只能看着空白的启动台发愣。后来才明白，Fiori Launchpad 里 Spaces 与 Pages 的传输机制和 ABAP 代码传输根本不是一回事，目录、页面、空间、授权角色之间的对象关系只要有一层没理清，传输过去就是给你看一个“干净”的启动台。
这篇内容我会从对象关系讲到项目落地，把里面涉及的技术逻辑、实际操作步骤和我在现场踩过的坑完整拆一遍。适合刚开始负责 Fiori 配置传输的 ABAP 顾问、Fiori/UX 顾问、Basis 运维，以及正在做 Fiori 内容推广但总被“页面不显示”困扰的项目团队。
1. Space 与 Page 不是“新文件夹”，它们是导航装配层
1.1 用户眼中的空间和页面，其实是系统眼中的显示容器
如果你只是以终端用户身份登录过 Fiori Launchpad，你会觉得 Space 就是一个左上角的下拉区域，点进去之后里面有一个或多个 Page，Page 上面放着各种 App 磁贴。看起来像一个稍微高级一点的菜单分组。
但从配置和传输的角度看，Space 和 Page 的本质是一层“导航装配容器”。Space 在最高层定义了一个业务职责领域，比如“采购专员空间”“仓库主管空间”“财务月结空间”。Page 是在这个领域内部进一步切分的显示工作台，比如采购专员空间下可以有“日常采购任务”页面和“采购分析”页面。而页面上真正被用户点击的每一个磁贴，才对应到底层的 Fiori 应用或者一组应用集合。
这层容器不维护任何业务数据，里面装的也不是应用本身，它只维护“谁应该看到什么布局”的菜单关系。所以我一直和团队强调，Space/Page 在做传输时，本质上是在传输“配置关系”，而不是传输“应用功能”。应用功能可能早就通过 ABAP 传输请求过去了，但如果这层装配关系缺失，用户的前端就是空白。
1.2 为什么项目里老有人搞混目录、空间、页面、磁贴
出现混淆的根本原因是旧版 Fiori Launchpad 和 2.0 的术语完全变了。在旧版 Fiori 里大家习惯说的是 Catalog（目录）和 Group（组）。Catalog 管的是应用集合与权限赋值，Group 管的是用户启动页上磁贴的目视排列。新版引入 Spaces 与 Pages 之后，很多人想当然地认为“Space 就是原来的 Group，Page 就是原来的 Catalog”，这个直觉在某种层面上接近，但技术上又不完全一致。
我给同事做培训时会用最简单的话解释：
- Catalog 是后端的“应用抽屉”，存的是应用与权限引用关系。
- Group 是启动页显示的“磁贴抽屉”，控制哪些磁贴按什么顺序显示。
- Space 是用户角度可见的“工作空间”，可以包含多个 Page。
- Page 是 Space 内部的“页面布局”，用来承载一组能完成业务任务的目录或磁贴。
这里的装配层级是：用户分配到 PFCG 角色，角色关联 Space，Space 里挂 Page，Page 里挂 Catalog 或 App。如果这个链条里任何一个关节没有挂上，用户进入 Launchpad 后一定会出现要么找不到空间，要么页面空白的问题。
1.3 和我经历过的经典目录模式比，到底好在哪
传统模式里，你给一个用户分配了多个 Catalog 后，Launchpad 上所有 Catalog 里的磁贴会全部堆在“我的主页”上，用户需要不停地查找和筛选。想要调整布局，只能动 Group。Group 一多，配置非常分散，而且很难按业务职责做清晰的隔离。
Spaces 模式针对这种场景做了很大改进：每个 Space 可以独立配置，包含的 Page 也可以为某个岗位角色量身打造。这样“采购员”进来看到的是采购员工作台，“仓库主管”进来看到的是仓库主管工作台，彼此不干扰。但从项目实施角度来看，这种架构导致配置对象数量暴增，Space/Page/Catalog/应用的引用关系形成了一张很密的网。假如项目团队还用原来“目录传一下就行”的思路去传输，必然会在目标系统里翻车。
所以在深入传输机制之前，必须先接受这个前提：Spaces 与 Pages 是 Fiori Launchpad 2.0 的显示组装层，它本身并不实现业务权限，只是把后端已经授权的应用资源按业务场景重新布局，传输时既要传“布局关系”，又要保证“背后引用的资源在目标系统里已经存