在 Fiori Launchpad 这个圈子里摸爬滚打几年，你会发现一个很有意思的现象：很多团队一上来就喜欢直接改模板、写 tile、铺 Target Mapping，结果需求一变更，整个配置就乱成一锅粥。真正到了 Space 与 Page Template 全面铺开的阶段，这种“散装配置”的弊端会暴露得非常彻底。
我这篇文章不打算给你复述一遍 Help Portal 上的官方定义，而是想从一个实际落地的角度来聊聊：当你真正接手一个基于 SAP BTP 的 Fiori Launchpad 项目时，如何通过 Space 和 Page Template 把权限、布局、内容分层解耦，让配置变得可持续维护，同时让业务用户真正觉得“这东西好用”。
1. 先搞清 Space 与 Page Template 究竟解决什么
1.1 从角色视角回归用户视角
过去我们在 Fiori Launchpad 里做配置，习惯性的思路是“我要给谁看什么”。在 Fiori 前端配置还没有进化的年代，比如经典 Launchpad 时代，管理员会把所有 Group 和 Tile 堆在一个共享区域里，然后通过 PFCG 角色去控制谁能看到哪些。这种做法在应用数量少的时候没问题，但一旦应用数量超过 20 个，或者部门之间出现交叉访问需求，维护成本会呈指数级上升。
Space 的出现，本质上把“给谁看什么”变成了“用户属于哪个空间，空间里有什么”。你可以把 Space 理解成一个独立的、带权限边界的容器。这个容器内不仅包含指向具体应用的 Tile，还包含一套完整的页面布局体系。当我们创建了一个 Space 并把它分配给角色之后，用户登录 Launchpad 看到的就不再是管理员手工拼出来的大杂烩，而是一个有明确业务边界的工作台。
Page Template 则是这个容器里的“页面骨架”。它决定了用户进入某个 Space 后，看到的是一个单栏的 Dashboard，还是一个带侧边栏的业务工作台，或者是一个分 Tab 的监控视图。这种组合方式最大的好处是让我可以把“内容”和“外观”分开管理。负责配置的人不需要关心色彩和布局，负责布局的人也不需要一头扎进具体应用列表里。
1.2 权限模型的一次根本性简化
在经典 Launchpad 时代，我经常遇到这样的问题：某个业务顾问说“为什么 XX 部门的用户多看到了几个 tile？”排查半天，最后发现是某个角色继承了另一个角色的 catalog，而 catalog 本身又是共享的。这种继承链一旦多了，没人能说清楚最终效果是由哪一层配置引起的。
Space 的权限模型则简单粗暴得多：一个 Space 通过Fiori Launchpad Space这个 PFCG 角色模板分配给用户（或者用户组）。分配之后，用户能看到这个 Space 及其内部所有 Page 和 Tile。不需要再一层一层去继承 catalog，也不需要担心 tile 在多个 catalog 里重复出现。
实际操作中，我会把 Space 角色设计成“部门业务单元”模式。举个例子，某公司有销售部和市场部，我直接创建两个 Space，名字分别叫Sales_Workspace和Marketing_Workspace。然后在 PFCG 里为每个 Space 生成独立角色，再把用户分配进去。这样权限既清晰又不会互相污染。
1.3 Page Template 是页面体验的标准化武器
我见过不少项目团队，对 Page Template 的理解停留在“它可以控制 tile 排列”。其实它的能力远不止于此。Page Template 决定的是整个页面区的信息架构，包括导航模式、页面的标题显示方式、tile 的分组布局方式，甚至是否显示用户自定义入口。
我们在某个制造企业项目里，把 Page Template 分成了三类：Dashboard型、Workspace型和Monitor型。Dashboard 型用于高管看板，一个 Page 里放关键 KPI 磁贴和报表入口；Workspace 型用于业务处理，带竖直图标导航和顶部标题栏；Monitor 型则用于运维监控，页面相对紧凑，所有 tile 平铺在一个区域内。
这种设计让不同类型用户进入 Launchpad 后，第一眼就能感受到“这个页面是给我用的”，而不是“我还要从一堆 tile 里找到我常用的那个”。尤其是对新手用户，这种体验差异是决定他们愿不愿意主动使用 Fiori 的关键因素。
2. 内容落地前必须想清楚的规划问题
2.1 先梳理业务场景，再设计 Space 数量
很多团队在配置 Space 时犯的第一个错误就是“照搬组织架构”。公司有五个部门就创建五个 Space，结果有些部门只有两个应用，Space 里空荡荡的，用户还要点进去再出来，体验很割裂。
我建议的做法是：先梳理用户真实的任务场景。比如“处理销售订单”“查看库存报表”“审批采购申请”这些才是场景。一个场景对应一个 Space，不一定要严格按部门划分。某项目里，我们把“销售订单处理”和“销售数据分析”分别做成两个 Space，但两个部门的用户因为业务交叉，往往同时拥有两个 Space 的访问权。这样他可以在两个工作台之间快速切换，而不会被部门墙限制住。
另外还要控制 Space 的数量。我的经验是，一个普通业务用户最多分配 2 到 3 个 Space。超过 3 个，切换成本增加，用户会开始抱怨“找不到入口”。如果你发现某个用户需要 5 个 Space，大概率是 Space 拆分粒度有问题，应该重新考虑合并方案。
2.2 Page 的命名与布局规范提前定好
Space 里的 Page 不是随意创建的。Page 名称会直接显示在 Launchpad 的导航区域，如果命名不统一，用户会产生困惑。比如同一个人拥有两个 Space，一个 Space 里页面叫“概览”，另一个叫“首页”，实际上功能类似，这就是命名混乱的信号。
我会在项目启动阶段就定义一个简单的命名规范。比如所有页面名称统一由“动词 + 对象”构成，像“处理订单”“审批申请”“查看库存”。或者按用途分：Overview、Processing、Reports、Admin。这个规范不一定要多高级，但必须保证团队成员在创建 Page 时不用临时构思名称。
布局方面也要提前统一。除非业务确有差异，否则一个 Space 里建议保持同类 Page 使用同一套 Template。如果有的页面一套布局，有的页面另一套布局，用户点击切换时会产生很强的跳跃感。统一布局也是一种隐性的用户体验设计，帮助用户形成空间记忆，让他知道点开哪个入口会进入哪种界面结构。
2.3 判断哪些内容应该放进 Space 而不是 Group
这里有一个很值得注意的细节：在 Page 内部，你可以分别添加“Groups（组）”和“Tiles”。但如果你过于依赖 Groups，本质上又回到了经典 Launchpad 的老路。Space 的价值在于它是一个完整的信息边界，而 Group 只是 Page 内的一个分区。
我的习惯是：把同属于一条业务流程的 tile 放进同一个 Group，但 Page 与 Group 之间应该有清晰的逻辑关系。比如处理订单这个 Page 里，可以分两个 Group：一个放“订单处理”相关事务型应用，另一个放“订单分析”相关报表型应用。这样布局有逻辑层次，用户能较快定位。
如果你在 Page 里创建的 Group 数量超过 5 个，我会建议你审视一下：是不是应该拆成多个 Page？Group 太多会导致页面滚动过长，使用体验反而下降。好的 Page 设计应该控制在屏幕滚动 1 到 2 屏以内就能看完所有分组。
3. 实操落地：从创建 Space 到配置 Page 的完整路径
3.1 在 BTP 里启用 Space 与 Page 功能
Space 和 Page 配置功能依赖于两样东西：Fiori Launchpad 的FLP服务以及SAP Build Work Zone（或传统 E 版 Fiori 前端服务器上的对应功能）。如果你用的是 BTP 的 Launchpad 服务，登录 Administration 界面后，左侧菜单里有Space Management选项。
这个页面就是配置的总入口。针对 Space 的操作主要是创建、编辑、分配、删除。针对 Page 的操作则包括创建、编辑、关联 Catalog、关联 Tile。需要注意的是，这里编辑 Space 和 Page 的人员需要有Launchpad_Admin角色。
在创建 Space 之前，我会建议你先在脑子里做一次“业务数据梳理”：这个 Space 面向什么角色、包含哪几个 Page、每个 Page 放哪几个 Tile。有了清单，再动手配置，效率会高很多。
3.2 一个 Space 的标准创建流程拆解
进入Space Management后，点击Create Space。这里需要填写一个名称，通常建议用业务短名加可读名称。比如技术上叫Z_SALES，显示名就叫Sales Workspace。创建 Space 后，系统默认会生成一个Default Page，这个 Page 的标题默认等于 Space 名称。
此时如果你直接往 Default Page 里加 tile，当然也能用。但我会建议你手动新增若干个 Page，而不是把内容全塞到 Default Page 里。因为 Page 之间是对业务场景的进一步拆分，多 Page 结构会让用户更清楚地知道哪里放什么内容。
创建 Page 的界面很简单：指定 Page 名称，选择 Template，然后添加相关的 Catalog/Tile。这里的关键点是：Tile 的选择不需要一个一个手动添加，可以直接基于某个目录（Catalog）批量导入。你只需要指定这个 Page 使用哪个 Catalog，并点击 Add Tiles，就能把该目录下的全部 tile 一次性带进来。这种模式特别适合按应用域组织 Catalog 的项目。
3.3 分配权限时最容易踩的坑
配置完 Space 和 Page 后，最核心的一步是把 Space 通过角色分配给用户。在 PFCG 的角色菜单里，输入事务代码PFCG_BC（如果用的是 ST 版本），点击分配角色模板。在模板列表里选择SAP_FIORI_LAUNCHPAD_SPACE，然后在空间字段填入你在 Space Management 里创建的那个 Space 名称。
保存并生成角色后，把用户加进去。这里有一个常见问题：如果你分配的 Space 名称与系统里某个已存在的 Space 名称不完全一致，权限不会生效，用户在 Launchpad 里看不到这个 Space。排查时先检查 Space 名称是否精确匹配，包括大小写与空格。我遇到过一次因为多了个尾空格导致整组用户看不到空间的情况，这种小问题排查起来非常耗时。
还有一种情况是要把同一个 Space 分配给多个角色，比如一线员工和经理都看同一个工作台，但经理还有一个额外的管理空间。这时候可以在两个角色里分别配置同一个 Space。角色之间不会互相干扰，同一个用户拥有多个角色时，Space 会合并显示。
3.4 Page Template 选择的判断依据
创建 Page 时，你会遇到 Template 选择界面。系统提供的模板包括Default、Dashboard、Workspace等。不同版本的 Fiori 前端服务器或 BTP 服务提供模板时有差异，但核心选择逻辑是相通的。
Default模板适合大多数情况，页面居中显示所有 tile，分组从上到下排列。Workspace模板则提供更紧凑的导航结构，适合业务操作频繁的场景，因为它支持把常用 tile 固定到侧边栏。Dashboard模板适合用于 KPI 展示，控制内容密度相对宽松。
我的个人建议是：没有特殊需求用 Default 就行。不要为了“看起来丰富”而强行套用复杂模板。复杂的模板意味着受限的排列结构，而且改模板往往比改经典布局更费时间。某项目里，我们曾把所有 Page 都套上 Workspace 模板，结果部分报表型 tile 在窄列里显示不全，后来又统一退回 Default，浪费了一个迭代周期的人力。
4. 常见问题：这些坑我替你先踩过了
4.1 用户看到了 Space，但看不到 Page
这种状况通常出现在分配权限后的第一次登录。用户能看到 Space 名称，但点击进入后 Page 空白。最常见的原因是这个 Space 下的 Page 尚未与任何 Catalog 关联，或者关联的 Catalog 没有分配 tile。
排查思路很简单：在 Space Management 里打开对应 Space，检查 Page 列表，查看每个 Page 的 Tile 来源是否指向有效目录。如果目录存在但用户仍看不到内容，就要检查用户角色是否包含该目录的对应权限。注意，Fiori Launchpad Space角色并不会自动继承目录权限，你需要另外分配一个包含 catalog 权限的角色给用户。
很多时候团队会忽略这一步，认为分配了 Space 就等于分配了内部 tile 权限。这是一个误区，也是新手最容易犯的错误。
4.2 修改了 Space 配置但用户端无变化
有时候你在后台给某个 Space 新增了一个 Page，或者修改了某个 Page 的标题，但用户刷新后看不到变化。这个问题的核心在于缓存。Fiori Launchpad 前端加载后，Space 和 Page 的元数据在浏览器端是有缓存的。
最直接的解决办法是让用户强制刷新页面（Ctrl+F5），或者退出重新登录。如果仍然无效，可以检查网关的元数据缓存，必要时在 BTP Subaccount 的 Destination 配置里调整缓存策略。我的经验是，多数情况下 Ctrl+F5 就能解决问题，不需要过度折腾后台。
但要注意：如果你修改的是 tile 指向的 Target URL，而不只是 Page 布局，可能还需要清理 ICF 节点缓存或应用相关的缓存。这里的排查路径通常比 Space 配置本身更长，因为它涉及 SAP NetWeaver 层面的缓存机制。
4.3 Space 分配后，用户同时被多个 Space 页面轰炸
有些管理员在配置时，因为不清楚一个用户需要哪些 Space，干脆把所有 Space 都分配给所有用户。结果用户登录后，导航栏出现三四个空间切换入口，每个空间里内容雷同。这种现象非常普遍，而且会让业务用户极度反感，他们会觉得“Fiori 就是把网页版 SAP 的图标罗列出来”。
要避免这个问题，最有效的方法是建立权限分配的评审机制。在角色配置阶段，就要有业务方参与确认“这个角色对应哪几个页面”。同时定期用事务代码SUIM或通过 BTP 的授权报表检查用户的有效 Space 数量。如果一个用户的有效 Space 超过 3 个，就要打上标签进行复核。
4.4 模板变更后页面错乱，如何快速回退
我见过最惨痛的案例是有人在生产环境里误改了 Page Template，把 Default 改成 Workspace 后，页面里的 tile 布局全部重排，用户截图反馈说界面错乱。这类问题回退成本很高，因为 Page 的配置改动是直接保存到后端表的，没有版本历史。
我给大家的建议是：模板变更之前，务必先用一个单独的测试 Space 做验证。在测试 Space 里把真实的 Page 结构复制一份，改模板后检查每个 Group 的布局表现。确认无误后，再在生产 Space 里操作。另外，建议在变更前使用SE16查看底层表FPM_HEADER等相关配置，把当前值记录下来，这样万一出错还有机会手工改回去。
5. 项目实战心得：Space 与 Page 的配合让迭代更顺滑
5.1 我们的角色权限与页面模板协同设计方法
在最近的一个制造业客户项目中，我们采用了一种很实用的分层协同方式。权限模型仍然走 PFCG 标准路径，但不再为每个用户单独配置目录权限。我们设计了一套矩阵：部门 × 场景 = Space + Page。比如“生产计划部”这一行对应“生产计划工作台”这个 Space，内部页面对应订单处理、物料查询、异常监控等 Page。
每个 Page 在创建时就绑定固定的 Catalog，Catalog 内 tile 的 Target Mapping 提前在 Launchpad 设计器里维护好。这样当业务方提出“新增一个报表”时，我们只需要在对应 Catalog 里增加一个 tile，然后回到 Page 里点击同步，用户端马上就能看到。整个流程不需要动角色权限、不需要改布局模板，发生变化的只有内容层的 catalog。
这种“权限动、页面不动；页面动、内容动”的配合模式，让我们的迭代速度提升了一大截。过去改一个 tile 需要配置角色、目录、目标映射三处，现在只需要在目录维护处动一次。对于频繁有新增应用的中型项目来说，这种体验是非常值得投入的。
5.2 页面模板对用户培训成本的影响
我这里有一个比较直观的观察：在采用 Space 和 Page Template 的项目里，给新用户做培训的时间可以缩短 30% 左右。原因很简单：空间内的页面结构一致，用户只要学会了第一个工作台的操作逻辑，之后的所有工作台都套用同一套认知模型。
比如在订单处理 Page 中，用户知道左侧是业务入口，右侧是历史记录。到了库存监控 Page，左侧是监控应用，右侧是异常查询。同一个布局习惯被复用，用户形成肌肉记忆的速度明显更快。相比经典 Launchpad 把所有应用全部平铺，这种“场景化 + 模板化”的界面更容易被非 IT 背景的业务人员接受。
当然，这种效果高度依赖你在项目前期对模板的规范化设计。如果每个模板都有很大的布局差异，那种培训优势就荡然无存。所以我会建议大家在项目里专门拨出时间，定义一套“页面的信息架构规范”，其中包括 Group 顺序、tile 大小、标题显示策略等细节。这种规范化工作虽然短期内看不到直接收益，但它对整个产品的后续迭代影响深远。
5.3 与现有经典 Launchpad 混用时的注意事项
如果你的企业并不是从零开始上 Fiori，而是正在从经典 Launchpad 迁移到 Space 模式，你一定会遇到这样一个阶段：部分用户已经习惯了老工作台，新工作台又刚刚上线。这时候你可能会同时保留新旧两种 Launchpad 的访问方式。
我的实践建议是，这个过渡期尽量控制在两个迭代以内。因为维护两套 Launchpad 会让你在权限分配和配置维护上出现重复投入。一旦确认新工作台符合业务预期，就应该立即切断老入口，避免用户长期停留在旧页面里，导致新功能的认知度始终提不上来。
迁移过程中还有一个细节：老方案里的SAP_FIORI_LAUNCHPAD目录角色模板仍然会存在，如果你不主动清理，用户既能看到新 Space，也可能在系统里看到旧的 Group 目录结构。这种双重显示会让用户觉得系统很乱。所以在迁移时，务必检查每个用户角色集合里是否还残留旧目录角色，确认无误后再切换。
5.4 后续优化：如何利用 Space 洞察用户行为
当项目运行稳定后，我会建议团队进一步使用后台的 Launchpad 使用情况统计功能（比如SUIM报表或 BTP 上的 Usage Analytics），按 Space 维度分析哪些 Page 被用户高频访问、哪些页面一个月都没人打开。
这种数据可以帮助你做页面瘦身和权限收敛。比如某个 Space 里有一个页面连续 90 天零访问，那大概率这个页面应该被移除，或者说明用户根本不知道它的存在。又比如某个页面访问量极高，可以把其中的高频应用提升到更显眼的位置，甚至可以基于这个行为数据反过来优化 Page Template 中 Group 的排序。
这种基于数据的持续调优，才真正体现了 Space 与 Page Template 这些新配置模式的长期价值。它们不仅仅是“换了一种展示方式”，而是让整个前端配置体系在结构和数据层面都变得可分析、可优化。这也是我在多个项目里一直坚持用这套方案的根本原因。
