AEM 的黄昏与黎明：传统开发模式的困境与边缘交付的前瞻

发布时间：2026-08-31

作者：William

引言

MACH Alliance 的研究给出了一个刺眼的数字：采用完全可组合（composable）架构的企业，获得清晰技术投资回报的概率是其他企业的 6 倍 [1]。企业技术架构正在从"一个平台做所有事"转向"每个环节选择最好的服务"——越来越多的客户在咨询如何将传统 AEM 站点拆分、迁移，或至少部分迁移到更轻量的交付架构。

目标场景的特征：

l 已运行 AEM 5 年以上，技术债深重，每次发布都是一场战役

l 内容团队抱怨编辑器难用，市场团队抱怨页面慢，开发团队抱怨构建慢

l 想上 headless / edge 架构，但被"已有投资"和"迁移成本"困住

l 听说过 EDS，但不确定它解决了什么问题，又不解决什么问题

我们在多个大型企业站点上深度使用 AEM 6.x 全栈技术。这篇文章记录实战中的观察：传统模式的结构性问题在哪里，Adobe 推出的 Edge Delivery Services（EDS）是否是一条可行的出路。

一、传统 AEM 开发模式：一座精密而迟缓的钟表

1.1 技术栈的"化石层"

AEM 的技术栈是一个地质剖面。最底层是 JCR（Java Content Repository），设计于 XML 时代的树状存储模型；往上是 Apache Sling——本质是一个深植于服务端渲染世界观的 URL 路由器；再往上是 OSGi，它的动态加载和配置管理带来的却是无尽的类加载器调试；最上层是 Granite UI / Coral UI——基于 jQuery 的组件层，在 React/Vue/Svelte 统治前端的今天像博物馆展品：做一个稍复杂的编辑对话框要写 XML 节点定义，没有类型检查，也没有组件复用的现代手段。

这些技术本身并非没有道理，问题在于它们是一个封闭的、不与外界演进同步的生态。当前端世界用 TypeScript + npm 管理依赖时，AEM 用 Maven 打包 clientlib；当后端世界用 Spring Boot 或 serverless 时，AEM 还在 OSGi 里注册 Service；当部署世界用 Docker + K8s 时，AEM 的部署单元是 CRX Package——一个 ZIP 文件。

（图片展示了技术栈化石图层）

1.2 双内容树的认知负担

真实项目的内容架构往往演化出分裂：一棵展示页面树，一棵数据/配置页面树，展示页面通过 Sling Model 和 QueryBuilder 查询在运行时引用数据页面。数据与展示分离有其合理性，但代价是隐式耦合——关联关系不存在于类型系统和外键约束里，只存在于开发者的脑中和查询字符串里。数据页面改名了、删除了，展示页面不会报错，只会安静地渲染一个空白区域。

这不是 bug，而是架构的必然代价：JCR 没有外键，Sling 没有编译期检查，所有的关联都是字符串路径，所有的错误都推迟到运行时——adaptTo() 适应失败得到的是 null 而非编译错误，查询路径拼错得到的是空结果集而非异常。

1.3 前端工程的层层迷雾

现代 AEM 项目的前端工程化是妥协的产物：用 Webpack + TypeScript + SCSS 写代码，编译产物移动到 clientlib 目录，再由 Maven 打包部署，每一步都在制造摩擦。

更本质的问题有两个：

其一，手动映射层取代了编译期保障。 clientlib 不能用标准的 code splitting——它是服务端 include 的静态标签，于是要手动维护一份 webpack entry 列表和一份 clientlib 输出配置，再叠加组件策略 XML 中的样式类名匹配，任何一环出错都不会有编译错误或运行时异常，只是某个组件的样式不加载。前端和运行时之间被插入了太多靠人脑对账的映射层。

其二，服务端渲染与前端增强是割裂的。 页面主体由 Sling/HTL 在服务端生成，交互行为由 jQuery 在浏览器里二次加工——同一个页面的"最终形态"没有单一事实来源。内容默认全部塞进服务端 HTML 再用 JS 折叠隐藏，服务端输出和用户实际所见严重不一致；靠 Ajax 动态注入的内容又对 SEO 和首屏不友好。团队成员要同时在两个心智模型之间切换，调试时先要判断"这段内容到底是谁渲染的"。

二、开发与部署的日常之痛

2.1 构建：一个为 2010 年设计的管线

构建速度是一个慢动作。 中等规模项目的完整构建可能需要五到十分钟，即使跳过测试。更折磨人的是反馈回路：改了代码 → 构建、打包、部署 → 等几分钟 → F5 → 没生效 → 查日志 → 发现是 bundle 没更新 → 卸载重装 → 再等几分钟 → 终于看到了。前端改动理论上可以绕开 Maven 直接构建，但产物仍要手动同步进 AEM。根因在于这是一个全量管线：任何一行改动的生效都要走完编译、打包、安装的完整链条，没有增量，没有热替换的可靠性。

2.2 OSGi Bundle：热部署的幻觉

最大的陷阱是版本号。 版本号相同的 bundle 不会被自动替换。改了代码，部署，日志显示一切正常——但运行的还是旧代码。没有报错：bundle 显示 Active，日志没有异常，功能就是不对。开发者盯着代码确认逻辑无误，最后才想起检查 bundle 的实际版本——团队里每个人都至少被坑过一次。

依赖解析的延迟失败。 bundle 部署后可能处于 Installed 而非 Active 状态，意味着有未满足的依赖。这个错误不在部署时报告，需要在控制台逐个检查导入包——在几十个 bundle 的项目里，这是一个搜索游戏。

Sling Model 的"静默失败"。 Sling Model 的初始化方法普遍用 try-catch 包裹并只记日志，任何运行时异常都不会导致 HTTP 500，而是组件渲染为空白：状态码 200，无前端报错，页面其他部分正常。唯一的线索是 error.log 里的堆栈，而日志巨大，定位要先记时间点再做文本搜索——这让"页面正常"的判断变得不可靠。

2.3 Author 与 Publish 的裂隙：缓存是那个无解的死结

内容在 Author 实例编辑，通过 Replication 发布到 Publish——架构理论上清晰，实践中充满裂隙。WCM 模式是隐藏变量：Author 默认运行在编辑模式，开发时加参数模拟发布环境，但真实环境还有 Dispatcher、CDN、负载均衡，行为并不完全等价。Replication 队列会卡住：编辑者不知情地反复点"发布"，队列里堆的请求越来越多。

但真正的死结是缓存与动态内容的矛盾。Dispatcher 的价值在于整页缓存，可一旦页面上存在需要实时聚合的动态组件——比如根据当前页面上下文生成的"相关洞察"列表——传统做法只剩两个：整页不缓存、每次回源 Publish 渲染，性能灾难；或者用 Ajax 前端异步加载，首屏闪烁、SEO 不友好。失效粒度同样进退两难：失效太多性能崩，失效太少内容不更新，而 Dispatcher → CDN → 浏览器的多级缓存每一层策略都不一致。我们处理过这样的 case：一篇新闻发布后 Author 正常、Publish 上 curl 也正常，但用户访问的还是旧的——CDN 缓存没过期，排查链路横跨三个系统，没有统一的"缓存状态视图"。

我们最终在某国际律所的全球官网上用外部手段破局：Sling Dynamic Include（SDI）在 AEM 渲染阶段把动态组件替换成 ESI（Edge Side Includes）占位符 [4]，Cloudflare Worker 在 CDN 边缘解析占位符、流式拼装真实内容——页面主体与动态片段各自独立缓存、独立失效，全球 TTFB 稳定在毫秒级，Publish 负载降到个位数百分比。这套方案的完整落地过程，我们在《AEM Dynamic Include 结合 Cloudflare ESI：构建极致性能的全球品牌站点》一文中有详细展开 [5]。

但这恰恰是问题所在：这个矛盾是 AEM 架构固有的，而官方没有给出答案。 SDI 只负责输出占位符，边缘的解析、拼装、缓存协调全靠自研；我们要在 CDN 层给 AEM 补上一层它本该原生具备的能力。当一个平台的核心矛盾需要用户在平台之外修补时，这个平台的架构就到了该被重新审视的时候。

三、落伍的本质：为什么传统模式不可持续

服务端渲染的认知错位。 传统模式假设页面在服务端组装，这在 2012 年成立，但今天用户期望亚秒级首屏。每次请求要解析 URL、加载 Model、执行查询、渲染模板，延迟在数百毫秒级，之后浏览器还要加载 clientlib 和 jQuery。Dispatcher 缓存能弥补延迟，却引入一致性问题；动态内容更是无法缓存，每次请求都回源。

部署单元太粗且不可回滚。 CRX Package 把组件定义、模板配置、内容页面、静态资源混在一起，无法细粒度增量更新；重新部署上一个版本时，两次部署之间产生的数据可能丢失——与蓝绿部署、金丝雀发布等现代交付理念完全脱节。

内容管理的深度耦合。 存储、渲染、编辑、分发在同一个系统内，版本必须一致，升级必须同步。这与 Contentful、Sanity 等 Headless CMS 的解耦理念完全相反：内容是 API 返回的 JSON，不是绑定在特定渲染管线上的 HTML。

四、EDS：Adobe 的 Edge 之赌

4.1 什么是 Edge Delivery Services

Edge Delivery Services（EDS）是 Adobe 在 2023 年推出的新一代内容交付架构，核心理念是内容在边缘渲染，而不是在服务器渲染 [2]。它的技术栈与传统 AEM 几乎完全不同 [3]：

l 内容源：Google Docs、Microsoft Word、SharePoint 等"文档即内容"来源，以及传统 AEM Author

l 构建管线：基于 GitHub 的自动管线，变更触发构建、部署到 CDN 边缘节点

l 渲染：预构建的静态 HTML + 原生 JavaScript，不再有 Sling/HTL 服务端渲染

l 前端：原生 ES Modules + 轻量增强，没有构建步骤和打包器

l 部署：Git push 触发的 CI/CD，秒级部署到全球 CDN，不再有 OSGi bundle

l 性能：官方目标是 Lighthouse 满分，实际项目通常能稳定达到 95 分以上

值得强调的是：我们在 2.3 节用 SDI + ESI 在 CDN 边缘艰难实现"页面主体缓存 + 动态片段边缘拼装"，正是 EDS 的默认架构——静态主体在边缘、动态部分按需获取，不需要自研任何边缘引擎。

4.2 文档即内容：编辑体验的范式转移

EDS 最革命性的改变不是技术架构，而是编辑体验。传统 Touch UI 功能丰富但学习曲线陡峭，编辑者要理解组件、模板、策略、Blueprint/Live Copy 等概念，发布要走 Replication 流程。EDS 的替代方案激进而直接：用 Google Docs 或 Word 编辑内容，保存后管线自动将文档转换为 HTML 部署到 CDN——从编辑到上线可能只需 30 秒，没有 Replication，没有缓存失效，没有 Publish 实例。

对编辑者意味着零学习成本——他们已经会用 Google Docs；对开发者意味着不再需要写组件对话框、配置编辑界面。"文档即内容"适合文章、新闻等内容型页面，复杂交互页面仍需代码开发，但开发方式已变为标准 Web 开发。

4.3 开发与部署体验的对比

以"为新页面类型添加一个自定义组件"为例。传统 AEM 方式涉及 4-5 个模块、7-8 个文件、3 种语言、2 个构建系统：组件节点结构、XML 编辑对话框、HTL 模板、可选的 Sling Model、前端 entry 与 clientlib 配置、组件策略——然后构建、部署、测试、查日志、验证缓存行为，有经验的开发者需要 2-4 小时。EDS 方式涉及 1 个目录、2 个文件、0 个构建配置：在 blocks/ 目录下写一个原生 JS 文件和一个 CSS 文件，内容文档中用一个表格标记引用，Git push 即完成部署——30 分钟。

部署体验的差距同样悬殊。传统部署以"分钟"为单位，CRX Package 不可回滚、存在"bundle 安装了但没激活"的中间态；EDS 的部署是 git push，秒级生效，回滚就是 git revert，不存在部分成功的中间态。这个对比是残酷的：传统 AEM 的复杂性不来自业务需求，而来自框架本身——大部分时间不是在解决用户的问题，而是在与基础设施搏斗。

（图片展示了部署流程对比）

4.4 性能的代际差异

传统 AEM 的性能优化是一门黑魔法：缓存规则、JVM 调优、查询优化、clientlib 压缩、CDN 策略——每个优化都是独立配置项且相互影响。即便如此，传统 AEM 站点的 Lighthouse 性能分数通常在 30-60 之间，首页首次内容渲染可能需要 2-4 秒。

EDS 的性能优势是架构性的：内容是预构建的静态 HTML，部署在边缘节点，TTFB 就是 CDN 响应时间，通常在 50 毫秒以内；没有 jQuery 和 clientlib，JavaScript 体积可控制在 50KB 以下；Lighthouse 95 分以上是架构的默认行为，而非调优的结果。

（图片展示了性能指标对比）

五、冷静审视：EDS 不是银弹

EDS 适合内容驱动型站点：企业官网、新闻门户、博客、知识库——内容更新频繁、页面结构相对固定、交互复杂度低、性能要求高。但把它当作 AEM 的"免费升级"之前，必须正视它的边界和代价。

5.1 功能边界

l 复杂的个性化体验。 AEM 的 ContextHub 和 Target 集成提供基于用户画像的动态推荐；EDS 的静态架构对个性化支持有限，客户端调 API 可实现，但牺牲边缘渲染的性能优势。

l 复杂的多站点管理。 AEM 的 MSM 和 Blueprint/Live Copy 管理多站点内容继承；EDS 没有等价功能，每个站点是独立仓库。

l 复杂的表单和工作流。 AEM Forms 支持动态表单、工作流、数字签名，EDS 不提供等价能力。

l 深度的 Adobe 生态集成。 深度依赖 AEM Assets、Dynamic Media、Marketo 的企业，传统 AEM 集成最紧密。

5.2 迁移成本：不是升级，是重建

从传统 AEM 到 EDS，走的不是升级路径，而是平台更换：

l 内容迁移：JCR 内容要导出为文档或 JSON，多年积累的元数据、版本历史、引用关系如何保全，每项都是工程

l 模板与逻辑重写：HTL 模板重写为原生 HTML + JavaScript，Sling Model 的业务逻辑迁移到客户端或 Edge Functions，没有自动转换工具

l URL 与 SEO 保全：URL 结构、重定向规则、搜索收录的连续性需要显式设计

l 前置条件：EDS 是 AEM as a Cloud Service 的组成部分——仍在使用 AEM 6.x on-premise 的企业要先完成云版本迁移或授权，这是常被低估的成本

l 过渡期双栈：渐进式迁移意味着一段时间内两套架构并行运营，发布流程、监控体系都要维护两份

迁移成本与站点规模、定制深度成正比，大型重度定制的站点，迁移开销可能不亚于一次平台更换。

5.3 成熟度与治理

EDS 2023 年才正式推出，社区文档、第三方组件、最佳实践还在快速发展中，没有传统 AEM 十几年积累的深度。"文档即内容"的治理模型也需要重建：权限、审批、元数据规范都要重新设计。选择 EDS 意味着接受一定程度的"早期采用者"风险。

六、展望：后 AEM 时代的可能性

对大多数企业，最现实的路径是混合架构：核心营销站点用 EDS 获得极致性能和编辑体验，复杂的应用型页面保留在传统 AEM——AEM as a Cloud Service 已支持这种组合，允许企业先迁移性能敏感的页面，再逐步扩大范围。

EDS 的出现也不是孤立的，它反映了 CMS 行业从单体到 composable 的大趋势 [1]：企业不再寻求"什么都做"的 CMS，而是选择可替换的最佳服务组合。传统 AEM 位置尴尬：它什么都做，但每一项都不是最好。EDS 的策略是做减法——砍掉服务端渲染、OSGi、HTL、clientlib，只保留最核心的内容管理和交付能力。

技术的演进方向由开发者体验驱动。传统 AEM 的开发者体验在过去十年几乎没有改善——不是 Adobe 不努力，而是 JCR、Sling、OSGi 这些地基无法在不推倒重来的情况下现代化。EDS 用当前的技术栈从零开始——原生 JavaScript、Git 工作流、边缘渲染、文档即内容，都不是新概念，但对 AEM 是第一次真正采纳。

FAQ

Q1：我们已经在用 AEM 6.x，有必要迁移到 EDS 吗？

不一定。站点以内容展示为主、性能是痛点、编辑对 Touch UI 不满意，EDS 值得评估；深度依赖 AEM Forms、Assets、MSM 或大量自定义 OSGi 服务，传统 AEM 仍更务实。注意 EDS 需要 AEM as a Cloud Service 授权，on-premise 用户要先算上这层成本。

Q2：EDS 的"文档即内容"对内容治理有什么影响？

正面影响是编辑零学习成本、发布秒级、版本控制由 Git 承担。挑战是权限管理、审批流程、元数据规范需要重新设计——企业级工作流要靠 GitHub 的 PR 机制或外部工具补充。

Q3：EDS 能否支持个性化内容推荐？

有限支持。个性化需要客户端 JavaScript 调 API 动态注入，会牺牲部分性能优势。轻量级个性化可以胜任；深度个性化仍是传统 AEM + Target 更强。

Q4：从传统 AEM 迁移到 EDS，最大的成本在哪里？

内容迁移和模板重写。JCR 内容要导出为文档或 JSON，HTL 模板和 Sling Model 逻辑要用原生 JavaScript 重写；此外还有 AEMaaCS 前置授权和过渡期双栈运营的隐性成本。建议分阶段迁移，优先高流量、低交互的页面。

Q5：EDS 的依赖锁定风险如何？

EDS 核心是标准 Web 技术 + Git + CDN，内容源也可以是 AEM Author 本身，技术栈是开放的。主要锁定点在构建管线和 Adobe CDN，相比传统 AEM 的全栈锁定已大大降低。

Q6：EDS 和 AEM as a Cloud Service 是什么关系？

EDS 是 AEM as a Cloud Service 的一个交付层选项，不是替代品。企业可以同时使用传统 AEM（内容后端）和 EDS（边缘交付前端），这种混合模式是 Adobe 官方推荐的渐进式迁移路径。

结语

在它的时代，AEM 是一个了不起的产品——它把内容管理、资产管理、站点管理、营销管理整合在一个平台中，许多企业的数字存在至今仍建立在 AEM 之上。但时代变了：用户期望亚秒级响应，开发者期望秒级部署，基础设施转向 CDN edge、serverless 和 Git 工作流。传统 AEM 的技术栈是一座精密的机械钟表，但在智能手表的时代，它不再是计时工具的首选。

EDS 不是完美的——有适用范围的限制、成熟度的不足、迁移成本的高昂。但它代表了一个正确的方向：让内容回归内容，让代码回归代码，让交付回归边缘。我们的态度是谨慎的乐观：谨慎，因为它仍需证明自己在大规模复杂场景下的能力；乐观，因为终于有了一条走出 JCR-Sling-OSGi 泥潭的路。AEM 的黄昏已经到来，天际线上有了光。

参考文献

[1] MACH Alliance, 《MACH Principles》, https://machalliance.org/mach-principles

[2] Adobe, 《Edge Delivery Services Documentation》, https://www.aem.live/

[3] Adobe Experience League, 《Edge Delivery Services Overview》, https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/edge-delivery/overview.html

[4] W3C, 《ESI Language Specification 1.0》, https://www.w3.org/TR/esi-lang

[5] 龙孚信息（DBC）, 《AEM Dynamic Include 结合 Cloudflare ESI：构建极致性能的全球品牌站点》, https://www.dragonsoftbravo.com/cn/zh/insights/aem-dynamic-include-cloudflare-esi-performance.html