给定代码场景下调用方AppDomain是否会自动加载目标程序集？

核心问题结论 #

secondAppDomain.Load()返回的asm引用不会自动让调用方AppDomain加载目标程序集，你看到的引用本质是CLR生成的跨域代理，不是绑定当前域的真实程序集对象。

具体运行逻辑拆解 #

• 首先明确CLR的基础规则：所有Assembly类实例从创建开始，就永久绑定在它被加载时所在的AppDomain上，不能跨AppDomain边界直接传递真实实体。
• 当你在默认AppDomain中调用secondAppDomain.Load(assemblyIdentity)时，整个流程是分两步完成的：
  1. 调用被CLR的跨域机制转发到secondAppDomain的上下文执行，真正的程序集加载动作完全发生在secondAppDomain内部：按照该域的程序集解析规则，将目标程序集的元数据、IL代码加载到secondAppDomain的内存空间，生成真实的、绑定在secondAppDomain上的Assembly实体。
  2. CLR不会把secondAppDomain里的真实Assembly实体直接返回给默认AppDomain——因为跨AppDomain边界传递对象默认会触发类型解析，而非MarshalByRef、非可序列化的对象无法跨边界传递。因为Assembly类型本身继承自MarshalByRefObject，所以这里返回给调用方的，是一个绑定在默认AppDomain上下文上的透明代理对象：这个代理内部只存储了目标程序集的标识、目标AppDomain的引用，所有你对这个代理的方法、属性调用，都会被CLR拦截后序列化转发到secondAppDomain的真实程序集实体上执行，拿到结果后再序列化返回给默认AppDomain。

为什么持有引用不会触发当前域加载 #

• 代理对象本身的运行完全不需要默认AppDomain加载目标程序集的元数据：它的作用只是“请求转发”，没有任何需要依赖SomeLibrary内部类型定义的逻辑。只要你不对这个代理做会触发类型解析的操作，默认AppDomain就永远不会执行SomeLibrary的加载动作。
• 只有当你通过这个代理执行的操作，需要把secondAppDomain里的、非可序列化、非MarshalByRef的类型实例传递回默认AppDomain时，CLR才会为了在当前域还原对象实例，主动触发SomeLibrary在默认AppDomain中的加载。这个加载是类型解析流程带来的，不是最初的Load()调用本身导致的。

常见认知误区：很多开发者以为只要拿到了跨域返回的对象引用，就意味着相关程序集已经加载到当前AppDomain，本质是把跨域透明代理和真实实体对象搞混了。如果只通过代理读取FullName、Location这类程序集基础标识信息，哪怕持有代理引用到应用退出，当前AppDomain也不会完成目标程序集的加载。

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