解决警告并使.NET库支持Trimming与AOT

一、核心结论：你的库完全可以适配Trimming/AOT，并非无法使用 #

反射类库和裁剪的核心冲突在于，裁剪器无法静态分析反射调用的依赖，导致必要的类型、成员被误移除。只要针对性解决依赖追踪问题，就能让库在裁剪/AOT环境下正常运行。

二、剩余警告的针对性解决方法 #

你遇到的文档未覆盖的警告，基本属于以下两类场景，对应解决方案如下：

• 动态反射访问未标记的内部/外部成员
  • 若反射访问的是库内部类型/成员：使用[DynamicDependency]属性明确标记被访问的类型、方法或属性。比如你通过反射调用MyInternalType.MyMethod，直接给该方法或其所属类添加这个属性，告知裁剪器“此成员不可被裁剪”。
  • 若反射访问的是用户传入的外部类型：可以在库的文档中要求用户通过[DynamicDependency]或TrimmerRootAssembly标记他们的自定义类型，或者提供类型注册机制（比如RegisterConvertibleType<T>()），让用户提前声明需要转换的类型，帮助裁剪器识别依赖。
• 基于Emit的动态代码生成
  • 若你的库使用ILGenerator生成代码，裁剪器无法追踪生成代码中的依赖。这种情况可以用[RequiresDynamicCode]标记相关API，同时在文档中说明：使用该API时，用户需禁用项目裁剪，或手动标记依赖。如果要完全适配AOT，建议替换Emit为.NET 7+支持的System.Linq.Expressions AOT兼容模式，或者改用静态代码生成。

三、重写库适配Trimming/AOT的可行方向（可牺牲部分功能） #

如果现有代码修改成本过高，可以考虑以下重构思路：

• 静态转换优先，反射降级
  先为常用类型（如基本类型、常见集合、通用DTO）编写静态转换方法，仅在遇到未覆盖的类型时才触发反射逻辑。静态代码能被裁剪器完全识别，不会产生警告。
• 引入源代码生成器
  提供编译时预生成转换代码的能力，让用户在项目编译阶段就生成特定类型的转换逻辑，运行时完全不需要反射，天然适配AOT和裁剪。这是当前.NET生态下最彻底的适配方案，代价是需要编写源代码生成器，且用户需提前声明要转换的类型。
• 限制反射的使用范围
  保留反射逻辑，但仅允许访问用户显式注册的类型。例如添加RegisterConvertType<T>()方法，用户注册后库才会对该类型使用反射。这样裁剪器能通过用户的注册代码追踪到依赖，避免误删。

四、关于适配属性的使用后果说明 #

你担心属性的影响，这里做简单补充：

• [DynamicDependency]：仅告知裁剪器保留指定成员，不会影响其他代码的裁剪，只是确保反射所需的成员不被移除。
• [RequiresDynamicCode]：标记该API在裁剪/AOT环境下存在兼容性风险，编译时会向用户发出警告，提示调整项目设置，属于风险告知的“免责声明”。
• [TrimmerRootAssembly]：标记整个程序集不被裁剪，仅适合小体量库，否则会显著增大应用体积，不推荐大范围使用。

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