——————————目录大纲——————————
一、提要
为了便于新手快速上手了解AEM，也为了便于老手巩固和更深入了解AEM，对AEM中常见涉及的名词、缩写进行总结整理，以供随时翻阅。
二、正文
2.1 ESI（Edge Side Includes）
ESI（Edge Side Includes）是一种网页内容组装技术，主要用于缓存系统（如CDN、反向代理服务器）中，以提高网页加载效率和可维护性。
简单来说：
ESI 就像是“边缘服务器上的模板引擎”。它允许你将一个网页拆成多个小部分，在边缘（Edge）服务器上动态地拼接它们，而不是由源服务器来完成整个页面渲染。
举个例子：
假设你有一个新闻网站，页面大部分内容是静态的（比如文章正文），但头部的用户信息（比如“欢迎你，张三”）和天气预报是动态的。
你可以写页面模板如下（简化示例）：
<html>
<body>
<esi:include src="/header" />
<div>文章正文内容...</div>
<esi:include src="/weather" />
</body>
</html>
然后，CDN（比如 Fastly、Akamai）或者反向代理（比如 Varnish）在收到这个页面后，会：
拉取
/header的内容替换<esi:include>。拉取
/weather的内容再替换。最后把组装好的完整页面发给用户。
优点：
缓存粒度更细：页面的静态部分可以长时间缓存，而动态部分可以频繁更新。
减轻源服务器压力：拼装和缓存都在边缘完成。
提升性能：减少全页面重新生成，提高响应速度。
模块化开发：前端更容易组织页面结构。
注意事项：
浏览器 不会执行 ESI 标签，它只在支持 ESI 的服务器（CDN、代理）中生效。
需要在服务链路中使用支持 ESI 的产品（如 Varnish、Akamai、Fastly、Cloudflare Enterprise）。
某些 CDN 可能有自己对 ESI 的支持限制或语法扩展。
常见支持 ESI 的服务或工具：
| 工具/服务 | 是否支持 ESI |
|---|---|
| Varnish | 完整支持 |
| Akamai | 支持 |
| Fastly | 支持 |
| Cloudflare | 免费版不支持（Enterprise 才有类似功能） |
如果你是在做 大型网站、需要提升性能、但又不能把所有内容缓存起来 的场景，ESI 是个非常实用的技术。
2.2 SSI（Server Side Includes）
什么是 SSI？
SSI（Server Side Includes） 是一种非常老牌的服务器端网页模板机制，允许你在 HTML 页面中插入动态内容，比如：
插入其他文件（常见于头部/尾部）
显示当前时间
显示环境变量
简单的条件判断（比如
if）
它在 Web 服务器（如 Apache 或 Nginx）上处理，而不是 CDN 或边缘节点。
示例：
假设你有一个网站的多个页面都用同一个头部导航栏，你可以这样写：
<!--#include virtual="/includes/header.html" -->
这个标签不会被浏览器识别，而是由服务器（例如 Apache）读取 /includes/header.html 的内容，并在页面返回给客户端之前把它插进去。
优点：
使用简单，不需要外部工具或框架。
在 Apache、Nginx（带模块）等服务器上可直接配置使用。
适合轻量网站、低成本动态拼接页面。
缺点：
功能非常有限，不能像 ESI 那样细粒度控制缓存。
性能较差：每次请求都由源服务器来处理。
安全性相对较弱（可能暴露环境变量，容易被误用）。
不适合复杂逻辑处理或大规模动态拼接。
SSI vs ESI 对比：
| 特性 | SSI | ESI |
|---|---|---|
| 执行位置 | 源服务器（Apache/Nginx） | 边缘服务器/CDN（Fastly、Akamai） |
| 目标 | 简单动态插入、模板片段复用 | 复杂页面拼接、缓存优化 |
| 支持缓存控制 | 基本不支持 | 精细缓存（每个块单独缓存） |
| 性能 | 中下（源服务器承担压力） | 高（边缘服务器分担压力） |
| 典型应用 | 小型网站、公网环境 | 大型网站、高访问量应用 |
| 支持语法 | <!--#include file="..." --> | <esi:include src="..." /> |
总结：
| 用 SSI 的好场景 |
|---|
| 网站比较小，或者部署在局域网中 |
| 想快速插入头部/尾部，不引入复杂技术栈 |
| 对缓存和性能要求不高 |
| 用 ESI 的好场景 |
|---|
| 大型网站、新闻门户、电商等动态页面系统 |
| 想最大程度利用 CDN，优化性能和缓存策略 |
| 多模块页面拼接、并要求部分块实时更新 |
2.3 SDI（Sling Dynamic Include）
SDI（Sling Dynamic Include），它是 AEM（Adobe Experience Manager） 特有的一种服务端动态内容拼接机制，跟你作为 AEM 开发者正好密切相关。
什么是 SDI（Sling Dynamic Include）？
SDI 是 AEM 提供的一种机制，它会在页面渲染时，把某些组件（比如动态的、个性化的内容）替换为服务端的 <include> 标签，等到 Web 服务器（如 Apache、Dispatcher）再去处理这些标签的时候再动态地请求这些块。
它的设计目标是 兼顾 Dispatcher 缓存效率和组件的实时性。
工作原理一览：
在 AEM 中渲染页面时，SDI 会把你标记为“不宜缓存”的组件（如登录信息、购物车状态）替换成：
<!--#include virtual="/libs/xxx/dynamicComponent.html" -->这个
<!--#include -->是 SSI 标签，由前端的 Apache（启用了 SSI 模块）或者 Dispatcher 来解析执行。Apache 会再向 AEM 请求这些动态部分，从而完成最终拼接。
为什么要用 SDI？
在 AEM 项目中，如果你把整页缓存，但某些区域又需要实时个性化数据（比如登录用户信息），那就需要 SDI：
| 普通做法 | 整个页面不能缓存，为了小块实时数据牺牲性能 |
|---|---|
| SDI 做法 | 把实时部分拆出来，其余区域依然能被 Dispatcher 缓存 |
SDI 常见使用场景：
显示用户登录信息
个性化推荐
实时数据展示（购物车、投票结果等）
多语言动态切换区域
使用 SDI 的基本步骤：
安装 SDI 包（Adobe 提供的
sling-dynamic-includeOSGi bundle）。在 AEM 中配置哪些组件使用 SDI（通过 OSGi Config 或 Sling Filter）。
确保 Dispatcher 或 Apache 服务器支持 SSI 并启用了相关模块。
测试动态组件是否被替换为
<!--#include virtual=... -->。
对比 SDI、ESI、SSI：
| 特性 | SDI | ESI | SSI |
|---|---|---|---|
| 用于 | AEM 页面中部分内容不缓存 | CDN 边缘拼接页面 | Web 服务器本地拼接页面 |
| 执行时机 | Dispatcher 或 Apache 执行 SSI | CDN 执行 | Apache/Nginx 执行 |
| 开发依赖 | 需安装 AEM OSGi Bundle | 依赖支持 ESI 的 CDN（Fastly、Akamai） | Web 服务器配置即可 |
| 是否 AEM 专属 | 是 | 通用 | 通用 |
| 适合什么场景 | Dispatcher 缓存 + 实时组件共存 | 复杂的 CDN 缓存策略 | 简单头尾拼接 |
总结一句话：
SDI 是 AEM + Dispatcher 环境下实现“页面可缓存 + 局部动态更新”的推荐方案。
2.4 JCR（Java Content Repository）
JCR（Java Content Repository） 是理解 AEM（Adobe Experience Manager）底层的核心之一，它是整个内容管理系统的“数据库 + 文件系统 + API 规范”。
什么是 JCR？
JCR（Java Content Repository） 是一个内容仓库规范，定义了如何以结构化和分层的方式存储内容数据，适用于内容管理系统（CMS）和文档管理系统等。
它是 Java 内容存储的标准，由 JSR-170（初版）和 JSR-283（2.0 版）定义的。
举个简单比喻：
如果把 AEM 当成一个网站工厂，那么：
JCR 就是仓库 + 文件架 + 货架标签 + 拿取/更新内容的操作手册。
JCR 的结构（像文件系统一样）
内容在 JCR 中是以“节点（Node）”和“属性（Property）”的形式组织的，类似树形结构：
/content
└── /mysite
└── /en
└── /home
├── jcr:content
│ ├── jcr:title = "Home Page"
│ ├── sling:resourceType = "mysite/components/home"
└── someChildPage
Node：可以理解为文件夹或文件。Property：节点的属性，如标题、资源类型等。Path：每个节点都有唯一路径，例如/content/mysite/en/home.
JCR 的核心特性
| 特性 | 说明 |
|---|---|
| 树形结构 | 类似文件系统，每个页面、组件、配置都是一个节点。 |
| 支持结构化/非结构化数据 | 可以定义 schema 也可以随意扩展属性。 |
| 版本控制 | 支持内容版本（比如回滚、历史记录）。 |
| 访问控制 | 内置权限系统（ACL）。 |
| 查询机制 | 支持 SQL2 和 XPath 形式的查询。 |
| 事务性 | 支持读写事务。 |
常见实现（产品）
| 实现 | 用途 |
|---|---|
| Apache Jackrabbit | 最常见的开源 JCR 实现，AEM 使用的基础组件。 |
| ModeShape | 另一种开源实现 |
| Magnolia CMS | 也基于 JCR |
AEM 用的 JCR 实现是 Jackrabbit Oak，是 Jackrabbit 的新一代存储引擎。
和 AEM 的关系
在 AEM 中：
页面（Page）是一个 JCR 节点；
组件（Component）是节点的类型（
sling:resourceType）；所有的 DAM 资源（图片、PDF 等）也保存在
/content/dam下的 JCR 树中；AEM 的查询、权限管理、发布机制都依赖于 JCR。
查询 JCR 内容
你可以通过：
AEM 的 CRXDE Lite 工具查看 JCR（
http://localhost:4502/crx/de）通过 SQL2 查询（例如在 AEM Query Builder 或开发代码中）：
SELECT * FROM [cq:Page] WHERE ISDESCENDANTNODE('/content/mysite')
总结一句话：
JCR 是 AEM 的底层数据模型，就像数据库 + 文件系统的混合体，是一切内容存储、查询、结构的基础。
2.5 CRXDE（Content Repository eXtreme Development Environment）
说到 CRXDE，那可真是 AEM 世界里的放大镜 + 手术刀 + 沙盘模拟器！
CRXDE 是什么？
CRXDE（Content Repository eXtreme Development Environment） 是 AEM 自带的一个Web-based JCR 浏览与编辑工具，它允许你在浏览器中：
浏览 JCR 内容树结构（类似于文件管理器）
直接查看和编辑节点、属性
创建页面、组件、模板等节点
编写并测试 JSP/HTL 脚本（CRXDE Lite）
访问地址（默认）：
http://localhost:4502/crx/de
或者你点 AEM 欢迎页里的 CRXDE Lite 链接也能进。
CRXDE ≠ CRXDE Lite？
| 工具 | 说明 |
|---|---|
| CRXDE | 原本是一个 Eclipse 插件，已废弃。 |
| CRXDE Lite | 是现在 AEM 自带的 Web UI 工具，你看到的 /crx/de 就是它。 |
所以现在大家说 CRXDE，基本指的是 CRXDE Lite。
CRXDE Lite 能干什么？
| 功能 | 描述 |
|---|---|
| 浏览节点结构 | 就像文件管理器一样看 /content、/apps、/etc 等路径 |
| 查看/编辑属性 | 查看 jcr:title、sling:resourceType 等节点属性 |
| 创建/复制/删除节点 | 对页面、组件、模板结构进行编辑 |
| 编辑 HTL/JSP 脚本 | 可以直接在线修改 .html、.jsp、.xml 文件 |
| 查询与调试 JCR 数据 | 快速找出结构错误、数据丢失等问题 |
界面示意：
├── /content
│ └── /mysite
│ └── /en
│ └── /home
│ ├── jcr:content
│ │ ├── jcr:title = "Home Page"
│ │ ├── sling:resourceType = "mysite/components/home"
├── /apps
│ └── /mysite/components
使用时注意：
| 注意事项 | 说明 |
|---|---|
| 不建议线上环境使用 | CRXDE Lite 是调试工具，不适合在生产环境开放，容易误删误改 |
| 权限问题 | 需要 admin 或开发者组权限，否则无法访问 /crx/de |
| 不适合部署用 | 编辑代码应通过 Maven + 包部署（如 all 包），而不是在 CRXDE 改文件 |
总结一句话：
CRXDE Lite 是 AEM 的 JCR 编辑器 + 文件管理器 + 简易开发环境，是开发调试 AEM 项目的神器。
上一篇
AEM SDI整理