Unity 2021双热更实战：HybridCLR代码热更+Addressables资源热更

1. 为什么2021版Unity做HybridCLR+Addressables双热更，必须亲手踩一遍这个坑

我第一次在项目里把HybridCLR和Addressables绑在一起跑通热更，是在一个上线前两周的深夜。当时需求很明确：iOS审核被拒三次，每次都是因为热更资源包里混进了未签名的原生库；Android端又卡在64K方法数，补丁一打就闪退。团队里没人敢动IL2CPP底层，但又必须绕过苹果的签名限制——最后发现，只有HybridCLR能真正把C#逻辑从AOT编译中“摘出来”，而Addressables才是唯一能把资源加载、版本管理、依赖解析全链路收口的方案。这不是炫技，是Unity 2021 LTS版下，中小团队能落地的、成本最低的双热更正解。

关键词“HybridCLR”“Addressables”“Unity 2021”不是随便堆砌的。HybridCLR解决的是Unity热更最顽固的“代码热更不可信”问题——它不改引擎、不依赖Mono运行时，而是用C++重写了一套轻量级CLR虚拟机，让C#脚本在运行时动态加载、执行、卸载，彻底规避iOS AOT限制；Addressables则解决了“资源热更太散乱”的痛点——它把AssetBundle封装成可寻址、可版本化、可远程加载的抽象单元，配合ContentUpdateGroup自动处理依赖、差异打包、CDN分发。二者叠加，才构成“资源+代码双热更”的完整闭环。本文面向的是已熟悉Unity基础、正在为热更方案焦头烂额的中高级开发者，尤其适合那些用着2021.3.x长期支持版、不敢贸然升级到2022+、又急需上线热更能力的项目组。你不需要懂IL汇编，但得会看日志、会配Build Profile、能改几行C#脚本——接下来所有步骤，我都按真实产线节奏拆解，连Editor Log里那行容易被忽略的[AddressableAssets] Build completed successfully在哪找，都给你标清楚。

2. HybridCLR核心机制与2021版适配要点：为什么不能直接套用2022+文档

2.1 HybridCLR不是“另一个热更框架”，它是运行时环境的替换层

很多团队一开始就把HybridCLR当成类似XLua或ILRuntime的“脚本热更方案”，这是根本性误判。HybridCLR的本质，是在Unity IL2CPP构建流程中，插入一个可动态加载的、兼容.NET Standard 2.1的轻量级CLR运行时。它不替换Mono，也不替换IL2CPP，而是在IL2CPP生成的原生代码之上，再架一层C++实现的虚拟机。这层虚拟机负责加载、解析、执行.dll格式的热更程序集（即HotUpdate.dll），并提供完整的GC、反射、异常处理能力。关键点在于：它完全绕过了iOS对AOT编译的强制要求——因为HotUpdate.dll里的C#代码，是在运行时由HybridCLR虚拟机解释执行的，而非提前编译成ARM64指令。

提示：HybridCLR生成的HotUpdate.dll，本质是标准.NET程序集（PE格式），不是Unity AssetBundle。它通过HybridCLR.LoadAssembly()加载进虚拟机，再用Assembly.GetType().GetMethod().Invoke()调用逻辑。这和传统AssetBundle加载预制体有本质区别——前者是代码执行环境，后者是资源容器。

2.2 Unity 2021.3.x的三大硬约束，决定你必须手动调整构建链

Unity 2021 LTS版（尤其是2021.3.30f1及之前）对HybridCLR的支持，存在三个必须直面的工程约束：

1. IL2CPP后端版本锁定：2021版默认使用IL2CPP 2.0.0+，而HybridCLR 2.10+要求IL2CPP 2.1.0+。若不升级，构建时会报错HybridCLR::Init failed: invalid il2cpp version。解决方案不是升级Unity，而是在Player Settings → Other Settings → Scripting Backend中，将API Compatibility Level从.NET Standard 2.1临时切回.NET Framework，再切回，强制刷新IL2CPP版本缓存。实测在2021.3.28f1上，此操作后il2cpp.exe --version输出变为2.1.1，方可继续。

2. HybridCLR Editor插件与2021 API不兼容：官方HybridCLR 2.10的Editor插件（如HybridCLREditor.dll）引用了UnityEditor.PackageManager命名空间中的Client.List()方法，该方法在2021.3中尚未暴露。直接导入会报CS0234: The type or namespace name 'Client' does not exist。正确做法是：删除Assets/Plugins/HybridCLR/Editor下所有.dll文件，改用源码模式——将HybridCLR仓库中hybridclr/unity/Editor目录下的.cs脚本全部复制进项目，Unity会自动编译。这些脚本不依赖Package Manager API，只调用AssetDatabase和BuildPipeline，完全兼容2021。

3. iOS平台需手动注入libHybridCLR.a：2021版Xcode导出时，不会自动将HybridCLR的静态库链接进工程。必须在Xcode中手动操作：打开Unity-iPhone.xcworkspace→ 选中Unity-iPhone Target → Build Phases → Link Binary With Libraries → 点击+→Add Other...→ 导航至Libraries/Plugins/iOS/libHybridCLR.a（该文件由HybridCLR的Generate iOS Lib菜单生成）。漏掉这一步，App启动时HybridCLR.Init()必返回false，且Xcode控制台无任何错误提示——这是2021版最隐蔽的坑。

2.3 2021版HybridCLR热更流程的三阶段验证法

在2021环境下，我总结出一套必须逐阶段验证的流程，跳过任一环节都会导致线上闪退：

• 阶段一：Editor内热更模拟
  在Unity Editor中，不运行真机，仅测试加载逻辑。创建一个空场景，挂载如下脚本：

  public class HotUpdateTester : MonoBehaviour { void Start() { // 1. 初始化HybridCLR var initResult = HybridCLR.Runtime.RuntimeApi.Init(); Debug.Log($"HybridCLR Init: {initResult}"); // 必须为true // 2. 加载本地HotUpdate.dll（放在StreamingAssets） var dllPath = Path.Combine(Application.streamingAssetsPath, "HotUpdate.dll"); if (File.Exists(dllPath)) { var assembly = HybridCLR.Runtime.RuntimeApi.LoadAssembly(File.ReadAllBytes(dllPath)); Debug.Log($"Assembly loaded: {assembly.FullName}"); // 3. 调用热更类方法 var type = assembly.GetType("HotUpdate.HelloWorld"); var method = type.GetMethod("SayHello"); var result = method.Invoke(null, null); Debug.Log($"Result: {result}"); // 应输出"Hello from HotUpdate!" } } }

  此阶段成功标志：Console输出三行日志，且无NullReferenceException。若卡在LoadAssembly，大概率是DLL编译目标框架不对（必须为.NET Standard 2.1，非.NET Core 3.1）。

• 阶段二：Android真机热更通道验证
  将HotUpdate.dll放入Android设备的/sdcard/Android/data/[bundleId]/files/HotUpdate.dll，修改脚本中dllPath为"/sdcard/Android/data/[bundleId]/files/HotUpdate.dll"。重点验证：

  • Application.persistentDataPath是否正确指向应用私有目录（2021版某些定制ROM会返回空）；
  • File.Exists(dllPath)是否为true（Android 10+需申请READ_EXTERNAL_STORAGE权限，且Target SDK < 29）；
  • LoadAssembly后，assembly.GetTypes()是否能列出热更类（证明DLL未被Android SELinux策略拦截）。

• 阶段三：iOS真机热更沙盒路径验证
  iOS路径必须用Application.temporaryCachePath（而非persistentDataPath），因后者在iOS 13+受App Sandbox严格限制。正确路径为：
  Path.Combine(Application.temporaryCachePath, "HotUpdate.dll")。
  验证时，先用Xcode的Devices and Simulators窗口，将HotUpdate.dll拖入App沙盒的tmp目录，再运行。若LoadAssembly失败，检查Xcode的Build Settings → Other Linker Flags是否包含-lHybridCLR，且Always Embed Swift Standard Libraries设为YES（HybridCLR依赖Swift运行时）。

3. Addressables资源热更架构设计：为什么必须放弃传统的AssetBundle手动管理

3.1 Addressables不是“AssetBundle封装器”，它是资源生命周期的中央控制器

很多团队尝试在HybridCLR热更之外，用老办法自己管理AssetBundle：手写BuildPipeline.BuildAssetBundles()，手动维护AssetBundleManifest，再用WWW或UnityWebRequest下载。这套方案在2021版会迅速崩溃——原因有三：
第一，AssetBundle.Unload(true)会强制卸载所有依赖资源，极易引发MissingReferenceException，而HybridCLR热更后的代码可能正持有这些资源的引用；
第二，AssetBundleManifest无法自动处理多版本间的增量更新，每次热更都要全量下载，用户流量成本飙升；
第三，iOS App Store审核明确要求：所有远程加载的代码和资源，必须具备明确的版本标识、校验机制、回滚能力，手写方案几乎无法满足。

Addressables的核心价值，在于它把资源管理从“手动拼图”升级为“声明式治理”。你只需在Inspector里勾选Addressable，设置Address（如ui/login_panel）和Label（如ui,login），Addressables系统就会自动生成：

• 一个中心化的AddressablesContentCatalog.json（记录所有资源地址、哈希、依赖关系）；
• 一组按ContentUpdateGroup划分的AssetBundle（自动处理依赖合并，避免重复打包）；
• 一套基于ContentStateData的版本比对算法（对比本地Catalog与远程Catalog，精准计算需下载的Bundle列表）。

注意：Addressables的ContentUpdateGroup不是简单的“打包分组”，而是热更的原子单位。一个Group内的所有Bundle，必须同时更新或同时回滚。因此，我建议将Code（HybridCLR DLL）、UI、Config、Art分别设为独立Group——这样当美术资源出错时，只需回滚Art组，不影响代码逻辑。

3.2 2021版Addressables构建配置的致命细节

Unity 2021.3.x自带Addressables 1.19.19，此版本存在两个必须修复的配置缺陷：

1. Build Script Pipeline默认禁用Include Addressables Content in Build：
   在Window → Asset Management → Addressables → Groups面板，右键任意Group →Build → New Build Script，生成的脚本中，AddressablesBuildScript类的PerformBuild方法默认不调用Addressables.BuildPlayerContent()。这会导致：打包APK/IPA时，Addressables资源不会被打进安装包，首次启动必报Catalog not found。
   修复方法：打开Assets/AddressableAssetsData/BuildScripts/AddressablesBuildScript.cs，在PerformBuild方法末尾添加：

   Addressables.BuildPlayerContent();

   并确保BuildPlayerOptions中的contentStateData参数传入正确的ContentStateData实例（通常为Addressables.ContentStateData）。

2. Remote Catalog URL的Scheme必须为https://，且域名需预置在Allowed URLs白名单：
   2021版Addressables的InitializationObjects中，ResourceManager的RemoteCatalogUrl字段若填http://cdn.example.com/catalog.json，iOS会因ATS（App Transport Security）策略直接拒绝连接，且Log无提示。必须：

   • 将URL改为https://cdn.example.com/catalog.json；
   • 在Player Settings → Publishing Settings → iOS → Additional App Store Options → Allowed URLs中，添加https://cdn.example.com；
   • 若用自签名证书，还需在Info.plist中添加NSAppTransportSecurity字典，启用NSAllowsArbitraryLoads（仅限测试，上线必须用正规SSL证书）。

3.3 双热更协同的关键：如何让Addressables加载HybridCLR的HotUpdate.dll

Addressables默认只加载UnityEngine.Object子类（如GameObject、Texture2D），而HotUpdate.dll是纯托管程序集，无法直接作为Addressable资源。解决方案是：将DLL包装为ScriptableObject资产，并利用Addressables的AsyncOperationHandle<T>泛型加载能力。

具体步骤：

1. 创建一个HotUpdateAssemblyAsset类，继承ScriptableObject：

   [CreateAssetMenu(fileName = "HotUpdateAssembly", menuName = "Addressables/HotUpdate Assembly")] public class HotUpdateAssemblyAsset : ScriptableObject { public byte[] assemblyBytes; public string assemblyName; }

2. 在Unity Editor中，右键Create → Addressables → HotUpdate Assembly，生成一个新Asset；
3. 编写编辑器脚本，自动将HotUpdate.dll的字节流注入该Asset：

   [MenuItem("Tools/Build HotUpdate Assembly")] public static void BuildHotUpdateAssembly() { var asset = AssetDatabase.LoadAssetAtPath<HotUpdateAssemblyAsset>("Assets/AddressableAssets/HotUpdateAssembly.asset"); var dllBytes = File.ReadAllBytes("BuildOutput/HotUpdate.dll"); asset.assemblyBytes = dllBytes; asset.assemblyName = "HotUpdate"; EditorUtility.SetDirty(asset); AssetDatabase.SaveAssets(); }

4. 在Addressables Groups面板中，将该.asset文件拖入CodeGroup，并设置Address为hotupdate/assembly；
5. 运行时加载：

   AsyncOperationHandle<HotUpdateAssemblyAsset> handle = Addressables.LoadAssetAsync<HotUpdateAssemblyAsset>("hotupdate/assembly"); handle.Completed += op => { var asset = op.Result; var assembly = HybridCLR.Runtime.RuntimeApi.LoadAssembly(asset.assemblyBytes); Debug.Log($"HotUpdate loaded via Addressables: {assembly.FullName}"); };

此方案的优势在于：Addressables自动处理了DLL的下载、缓存、版本校验（通过ContentStateData比对哈希值），且与资源热更共用同一套CDN分发、断点续传、失败重试机制，大幅降低运维复杂度。

4. 全流程实操：从零搭建HybridCLR+Addressables双热更管道（2021.3.30f1实测）

4.1 环境准备与依赖安装：精确到小版本号的操作清单

以下步骤均在Windows 10 + Unity 2021.3.30f1 + Visual Studio 2019环境下实测通过，任何版本偏差都可能导致构建失败：

1. 安装HybridCLR 2.10.1：

   • 下载Release包HybridCLR-2.10.1-Unity2021.zip（注意：不是master分支最新版，2021版不兼容2.11+）；
   • 解压后，将hybridclr/unity/Plugins目录下所有文件（含HybridCLR.dll、HybridCLR.pdb、libHybridCLR.a）复制到项目Assets/Plugins；
   • 将hybridclr/unity/Editor目录下所有.cs文件（HybridCLREditor.cs、HybridCLRMenu.cs等）复制到Assets/Plugins/HybridCLR/Editor；
   • 删除Assets/Plugins/HybridCLR/Editor下所有.dll文件（避免与源码编译冲突）。

2. 安装Addressables 1.19.19：

   • 打开Window → Package Manager；
   • 点击左上角+→Add package from git URL...；
   • 输入https://github.com/Unity-Technologies/Addressables.git?path=/com.unity.addressables#1.19.19；
   • 等待安装完成，重启Unity。

3. 配置Player Settings：

   • Other Settings → Scripting Runtime Version:.NET 4.x Equivalent；
   • Other Settings → Api Compatibility Level:.NET Standard 2.1；
   • Publishing Settings → iOS → Target SDK:Device SDK；
   • Publishing Settings → Android → Target API Level:Android 10 (API level 29)（避免Android 11 Scoped Storage干扰）。

4. 初始化Addressables Groups：

   • Window → Asset Management → Addressables → Groups；
   • 点击Create Group，新建四个Group：Code、UI、Config、Art；
   • 为每个Group设置Build Path和Load Path：

     Group	Build Path	Load Path
     Code	{BuildTarget}/Code	https://cdn.example.com/{BuildTarget}/Code
     UI	{BuildTarget}/UI	https://cdn.example.com/{BuildTarget}/UI
     Config	{BuildTarget}/Config	https://cdn.example.com/{BuildTarget}/Config
     Art	{BuildTarget}/Art	https://cdn.example.com/{BuildTarget}/Art

   • 关键：Load Path必须以https://开头，且域名与CDN一致。

4.2 构建热更内容：一次生成，多端分发的标准化流程

构建流程必须严格遵循“先代码、后资源”的顺序，否则Addressables Catalog会丢失HotUpdate.dll的依赖信息：

1. 构建HybridCLR HotUpdate.dll：

   • 创建一个独立的Unity项目（或在主项目外新建文件夹），导入热更代码（如HotUpdate/HelloWorld.cs）；
   • File → Build Settings，Platform选Any Platform，点击Switch Platform；
   • File → Build Settings → Player Settings → Other Settings → Api Compatibility Level设为.NET Standard 2.1；
   • Build按钮旁点击Build Settings...，勾选Development Build和Script Debugging（仅调试用）；
   • 点击Build，输出路径设为BuildOutput/HotUpdate.dll；
   • 验证DLL：用dotnet ilspycmd反编译，确认Target Framework为.NETStandard,Version=v2.1。

2. 构建Addressables资源包：

   • 回到主项目，确保所有需热更的资源（Prefab、Texture、ScriptableObject）已在Inspector中勾选Addressable，并分配到对应Group；
   • Window → Asset Management → Addressables → Groups；
   • 选中CodeGroup → 右键Build → Build For Development（首次构建）；
   • 选中其他Group → 右键Build → Build For Staging（后续增量构建）；
   • 构建完成后，Assets/AddressableAssetsData/Build目录下生成：
     • catalog.json（主Catalog，含所有资源元数据）；
     • catalog_*.hash（Catalog哈希文件，用于版本比对）；
     • Code/、UI/等子目录（含AssetBundle文件及.bundle.manifest）。

3. 生成热更发布包：

   • 将BuildOutput/HotUpdate.dll复制到Assets/AddressableAssetsData/Build/Code/目录下；
   • 在CodeGroup中，右键Build → Build For Staging，Addressables会自动将DLL打包进CodeBundle，并更新catalog.json；
   • 最终发布包结构：

     cdn.example.com/ ├── catalog.json # 主Catalog ├── catalog_abc123.hash # Catalog哈希 └── Android/ # 或iOS/ ├── Code/ │ ├── hotupdate_assembly.bundle │ └── hotupdate_assembly.bundle.manifest ├── UI/ │ ├── login_panel.bundle │ └── login_panel.bundle.manifest └── ...

4.3 运行时热更逻辑：三步加载，零感知切换

热更逻辑必须封装为可复用的Manager，以下是我在2021项目中稳定运行的HotUpdateManager核心代码：

public class HotUpdateManager : MonoBehaviour { private AddressablesResourceLocator _resourceLocator; // Step 1: 初始化Addressables并加载Catalog public async void Initialize() { // 初始化Addressables await Addressables.InitializeAsync(); // 加载远程Catalog var catalogHandle = Addressables.LoadContentCatalogAsync( "https://cdn.example.com/catalog.json", BuildTarget.Android); // 根据实际平台选择 await catalogHandle.Task; if (catalogHandle.Status == AsyncOperationStatus.Succeeded) { Debug.Log("Catalog loaded successfully"); _resourceLocator = catalogHandle.Result; } else { Debug.LogError($"Catalog load failed: {catalogHandle.OperationException}"); } } // Step 2: 检查并下载热更内容 public async void CheckAndDownloadUpdates() { // 获取当前本地Catalog版本 var localCatalog = Addressables.GetDownloadSizeAsync(_resourceLocator); var remoteCatalog = Addressables.GetDownloadSizeAsync( "https://cdn.example.com/catalog.json", BuildTarget.Android); await localCatalog.Task; await remoteCatalog.Task; if (localCatalog.Result != remoteCatalog.Result) { // 版本不同，触发更新 var updateHandle = Addressables.UpdateCatalogsAsync( new string[] { "https://cdn.example.com/catalog.json" }, BuildTarget.Android); await updateHandle.Task; if (updateHandle.Status == AsyncOperationStatus.Succeeded) { Debug.Log("Catalog updated, downloading bundles..."); // 下载所有变更的Bundle var downloadHandle = Addressables.DownloadDependenciesAsync( _resourceLocator.Keys, MergeMode.Union, true); await downloadHandle.Task; if (downloadHandle.Status == AsyncOperationStatus.Succeeded) { Debug.Log("All bundles downloaded"); } } } } // Step 3: 加载HotUpdate.dll并执行热更逻辑 public async void LoadHotUpdate() { var assemblyHandle = Addressables.LoadAssetAsync<HotUpdateAssemblyAsset>("hotupdate/assembly"); await assemblyHandle.Task; if (assemblyHandle.Status == AsyncOperationStatus.Succeeded) { var assemblyAsset = assemblyHandle.Result; var assembly = HybridCLR.Runtime.RuntimeApi.LoadAssembly(assemblyAsset.assemblyBytes); // 执行热更入口 var entryType = assembly.GetType("HotUpdate.Entry"); var entryMethod = entryType.GetMethod("Start"); entryMethod.Invoke(null, null); Debug.Log("HotUpdate executed successfully"); } } }

关键经验：

• InitializeAsync()必须在Awake()中调用，且不能await，否则会阻塞主线程；
• CheckAndDownloadUpdates()应放在启动画面（Splash Scene）中，利用加载时间后台下载；
• LoadHotUpdate()必须在Addressables.DownloadDependenciesAsync()完成后调用，否则HotUpdateAssemblyAsset可能尚未解压到本地缓存。

4.4 真机测试与问题排查：2021版高频报错对照表

注意：2021版Addressables的DownloadDependenciesAsync在Android 10+上，若未申请READ_EXTERNAL_STORAGE权限，会静默失败。务必在AndroidManifest.xml中添加：
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
并在运行时调用Permission.RequestUserPermission(Permission.ExternalStorageRead)。

5. 生产环境加固与灰度发布：让热更从“能跑”到“敢上”

5.1 版本回滚机制：三重保险策略

热更最大的风险不是失败，而是“成功地失败了”——即热更包加载成功，但逻辑有Bug，导致大面积用户异常。2021项目必须部署三重回滚保险：

1. 客户端强制回滚开关：
   在PlayerPrefs中持久化一个hotupdate_force_rollback键，值为true或false。热更Manager启动时，先读取该键：

   if (PlayerPrefs.GetInt("hotupdate_force_rollback", 0) == 1) { Debug.Log("Force rollback enabled, skip hotupdate"); return; }

   运维可通过后台下发指令，让客户端下次启动时自动跳过热更。

2. 服务端灰度开关：
   在CDN的catalog.json同级目录，放置一个hotupdate_config.json：

   { "enabled": true, "rollout_rate": 0.1, "blacklist": ["1.2.3.4", "5.6.7.8"] }

   客户端启动时，先请求此配置，根据设备IP和rollout_rate计算是否参与灰度（如Math.Abs(ipHash % 100) < rollout_rate * 100），再决定是否加载热更Catalog。

3. 本地Fallback Bundle：
   在Assets/StreamingAssets中预置一个fallback_hotupdate.bundle，内含上一稳定版本的HotUpdate.dll。当远程热更失败时，直接加载该Bundle：

   var fallbackPath = Path.Combine(Application.streamingAssetsPath, "fallback_hotupdate.bundle"); if (File.Exists(fallbackPath)) { var bundle = AssetBundle.LoadFromFile(fallbackPath); var asset = bundle.LoadAsset<HotUpdateAssemblyAsset>("HotUpdateAssembly"); HybridCLR.Runtime.RuntimeApi.LoadAssembly(asset.assemblyBytes); }

5.2 热更监控埋点：用最少代码获取最大可观测性

监控不是为了写报表，而是为了快速定位问题。我在2021项目中只埋了5个关键点：

1. Catalog加载耗时：

   var sw = Stopwatch.StartNew(); await Addressables.LoadContentCatalogAsync(...); sw.Stop(); Analytics.CustomEvent("hotupdate_catalog_load", new Dictionary<string, object> { {"ms", sw.ElapsedMilliseconds} });

2. Bundle下载大小与耗时：
   Addressables.DownloadDependenciesAsync()返回的AsyncOperationHandle有DownloadedBytes和ElapsedTime属性，直接上报。

3. HybridCLR加载成功率：
   HybridCLR.Runtime.RuntimeApi.LoadAssembly()返回null时，上报hotupdate_assembly_load_failed事件，并附带DLL哈希值（BitConverter.ToString(MD5.Create().ComputeHash(bytes))）。

4. 热更逻辑执行异常：
   在HotUpdate.Entry.Start()方法中，用try-catch捕获所有异常，并上报堆栈：

   try { /* 热更逻辑 */ } catch (Exception e) { Analytics.CustomEvent("hotupdate_execution_error", new Dictionary<string, object> { {"stack", e.StackTrace}, {"message", e.Message} }); }

5. 资源加载成功率：
   所有Addressables.LoadAssetAsync<T>()调用后，检查handle.Status，失败时上报addressables_load_failed及资源Address。

这些埋点数据接入公司内部的ELK日志系统后，热更问题平均定位时间从4小时缩短至15分钟以内。

5.3 我的2021双热更实战心得：少走弯路的三条铁律

1. 永远不要在热更DLL里调用Resources.Load或AssetBundle.LoadFromFile：
   这些API会绕过Addressables的缓存和版本管理，导致资源加载混乱。所有资源必须通过Addressables.LoadAssetAsync<T>(address)加载，哪怕是一张小图标。我曾因在热更代码里写了一句Resources.Load<Texture2D>("icon")，导致iOS审核被拒——苹果扫描到Resources文件夹被动态访问，判定为潜在代码注入。

2. HybridCLR的LoadAssembly必须在主线程调用，且不能在协程中yield return：
   LoadAssembly是同步阻塞操作，若在IEnumerator中调用，会卡死协程调度器。正确做法是：在Start()中调用，或用ThreadPool.QueueUserWorkItem异步加载，再用MainThreadDispatcher切回主线程执行逻辑。

3. Addressables的ContentUpdateGroup数量宁少勿多，但每个Group的边界必须绝对清晰：
   我见过最疯狂的案例是把每个Prefab都设为独立Group，结果生成了2000+个Bundle，CDN上传失败。我的经验是：Code、UI、Config、Art四组足够覆盖90%场景；Art组再按模块细分（如art_character、art_ui），但绝不按单个资源划分。边界清晰的标准是：当某个Group更新时，其他Group的资源绝不会因此失效或报错。

最后分享一个真实案例：我们上线双热更后，某次美术同事误传了一个1GB的PSD源文件到Art组，导致ArtBundle体积暴增。Addressables的ContentStateData自动检测到哈希变化，只下载了该Bundle的增量部分（约2MB），而Code组完全不受影响。用户无感，运维零干预——这才是热更该有的样子。