@ScriptVariable与@SlingObject注入resourceResolver的差异咨询

两种注解都是Sling生态中用于依赖注入的标记，但底层注入逻辑、绑定规则完全不同，核心差异集中在三点：

• 注入链路来源不同
  @SlingObject是Sling Models框架原生的核心注入注解，走Sling Models标准注入链路，直接从Model适配时传入的Adaptable（通常是Request、Resource对象）提取对应上下文的ResourceResolver，不会额外查找其他作用域的变量，适配逻辑对所有适配场景生效。
  @ScriptVariable是Sling Scripting模块提供的脚本专用注入注解，注入时优先从当前脚本执行的全局绑定域（即SlingBindings存储的变量集合）查找对应实例，只有脚本上下文存在变量时才能稳定注入，非脚本环境下的兜底查找逻辑在不同Sling版本表现不一致，不属于可靠的通用注入方式。
• 实例权限归属不同
  @SlingObject注入的ResourceResolver和适配时传入的原始上下文绑定，完全继承原始上下文对应的JCR会话权限，不会出现权限替换。比如从HttpServletRequest适配Model时，拿到的就是当前请求用户对应的解析器，权限和当前登录用户完全对齐。
  @ScriptVariable注入的ResourceResolver以脚本上下文存储的实例为准，如果项目通过BindingsValuesProvider、脚本前置逻辑、请求过滤器往脚本域里塞了自定义权限的解析器（比如服务用户解析器、临时降权的解析器），注入时会直接使用这个替换后的实例，和原始请求的用户权限可能完全不同。
• 生命周期绑定规则不同
  @SlingObject注入的解析器生命周期和原始Adaptable绑定：如果Adaptable是短生命周期的请求对象，解析器就随请求结束回收；如果Adaptable是长生命周期的资源解析器实例，解析器就随该实例的生命周期走，Sling Model本身不会主动干预注入解析器的关闭逻辑。
  @ScriptVariable注入的解析器默认绑定当前脚本执行周期，如果是脚本运行时临时生成的解析器实例，会在脚本执行结束后被自动关闭，不受Model实例本身的生命周期影响。

以下场景下两种注解注入的ResourceResolver会出现明确的行为差异，甚至导致逻辑报错：

• 场景1：脚本层存在自定义绑定配置
  当项目实现了SlingBindingsValuesProvider接口自定义脚本全局变量、或者在HTL全局脚本、JSP前置逻辑里替换了默认的resourceResolver变量时，@ScriptVariable会注入替换后的自定义权限解析器，@SlingObject依然注入原始上下文的解析器，二者读写仓库的权限范围、可访问路径会出现明显差异。
• 场景2：Model在非脚本上下文下适配
  当Sling Model不是通过HTL/JSP脚本渲染触发适配，而是在OSGi服务、Servlet、事件监听器、Sling Job里通过ModelFactory手动适配生成时，不存在脚本执行上下文和对应的SlingBindings，此时@ScriptVariable会直接抛出注入失败异常，@SlingObject可以正常从传入的Adaptable中提取解析器完成注入。
• 场景3：Model实例被跨周期缓存
  如果将脚本执行过程中初始化的Model实例缓存到HTTP Session、OSGi服务静态缓存等长生命周期存储中做跨请求复用，@ScriptVariable注入的解析器会因为脚本执行结束被自动关闭，后续调用解析器API时会抛出IllegalStateException: ResourceResolver is already closed异常；@SlingObject注入的解析器只要原始Adaptable未被销毁，就可以正常使用。
• 场景4：请求经过内部转发/包含
  当请求通过RequestDispatcher做forward/include内部转发时，转发后的执行链可能会替换脚本域的上下文变量，此时@ScriptVariable会拿到转发后最新上下文的解析器，@SlingObject拿到的始终是Model第一次适配时绑定的原始解析器，二者对应的请求路径、会话属性、权限上下文可能存在偏差。

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