AEM中页眉页脚为何定义为experience fragment而非独立组件

都是实际项目踩坑踩出来的实锤原因，没有虚头巴脑的概念：

• 集中维护成本极低，天然保证全站一致性
  页眉页脚是标准的全站公共区块，要是做独立组件嵌到每个页面模板里，哪怕你把配置抽成全局变量，后期要改个logo、调整导航排序、加个全局公告条，要么得挨个刷页面引用，要么得在臃肿的全局配置里找对应项，多站点/多语言/多品牌场景下更是容易出现不同页面头脚不一致的bug。用Experience Fragment（简称XF）的话，所有头脚内容存在独立的资源节点上，全站点所有引用位置都是读这同一个资源，改一次全量生效，做区域化/多语言版本的时候直接建XF的活副本就行，基础结构不用重复搭，不会出现某几个页脚漏改备案号、漏更活动入口的低级问题。我之前接触过做独立header组件的项目，年底改版权年份，运营漏了3个落地页模板的配置，被法务追着整改了一周，换XF根本不会出这种问题。
• 权限和工作流完全匹配公共内容的管理逻辑
  全站头脚的修改权限本来就不该开放给普通页面编辑——之前见过不少用独立header组件的项目，编辑改自己页面内容的时候不小心动了模板里嵌的组件配置，直接把全站导航改挂了。XF本身是独立的AEM资源，可以单独配细粒度权限：只有全站运营组的账号有修改、发布头脚XF的权限，普通页面编辑在编辑页面内容时只能看到头脚的占位，根本点不开改不了，从根源上避免误操作。而且XF的修改可以走独立的审批工作流，比如要临时加个顶部的促销通知，直接改对应XF、走审批发布就行，不用绑定具体页面的发布流程，效率高很多。
• 片段级缓存能力直接拉满渲染性能
  独立header/footer组件的渲染逻辑是绑在页面渲染链路里的，没法单独拆出来做缓存策略，高并发场景下每次页面请求都要重新计算导航、用户态判断等头脚逻辑，对发布层压力很大。用XF的话，头脚可以作为独立的渲染片段，直接配SSI/ESI级别的缓存，缓存失效规则可以单独设：比如页脚的联系方式更新了，只需要清这个XF的缓存就行，不用动全站成百上千个页面的缓存，首屏加载速度和发布层承压能力都能上一个台阶。
• 多端适配、个性化扩展不用反复改代码发版
  现在站点基本都要覆盖PC、移动端、甚至第三方嵌入场景，要是做独立组件，得在组件逻辑里写一堆设备判断、场景判断的分支，代码越堆越乱，后期改个逻辑都要回归半天。XF本身就支持多维度变体配置，同一个头脚XF可以分别建PC端、移动端、小程序内嵌的不同版本，引用的时候会自动根据访问设备、渠道匹配对应变体，不用改组件代码。要做个性化头脚（比如新用户显示注册入口、老用户显示个人中心入口，不同地区显示不同的本地服务导航），直接在XF里配受众规则就行，不用发版迭代组件。
• 故障回滚成本极低
  XF自带独立的版本历史，要是改头脚的时候出了问题（比如配错了跳转链接、样式乱了），直接一键回滚到XF的历史版本，全站立刻恢复正常。要是用独立组件加全局配置的方案，要么得找对应配置项的历史版本回滚，要是问题出在组件代码逻辑上，还得重新走代码部署流程，故障恢复时间要长很多。

内容的提问来源于stack exchange，提问作者SilviaJoyceBalraj