默认开启 publishtrimmed=true 会导致运行时崩溃，因其依赖静态分析裁剪“不可达”代码，但 system.text.json、di、ef core 等库大量使用运行时反射，裁剪器无法识别动态调用路径，误删 jsonserializeroptions 构造逻辑、泛型服务注册元数据等，引发 missingmethodexception、invalidoperationexception 及 notsupportedexception；需配合 trimmerrootassembly 兜底保留程序集或 dynamicdependency 精准标记反射入口，并注意第三方库未声明 istrimmable 时需手动加固，同时必须组合 publishsinglefile、禁用 publishreadytorun、启用压缩才能实现有效瘦身。
默认开启 PublishTrimmed=true 会直接导致运行时崩溃，不是“开就完事”，必须配合反射根、类型保留和库兼容性处理。
为什么 PublishTrimmed=true 一加就报错？
裁剪不是简单删代码，而是靠静态分析判断“哪些类型/方法永远不会被调用”。但 System.Text.Json、Microsoft.Extensions.DependencyInjection、ORM（如 EF Core）等主流库大量依赖运行时反射——编译器看不到它们在哪儿被动态调用，就直接把 JsonSerializerOptions 的构造逻辑、服务注册的泛型擦除信息全删了。
常见崩溃现象：
System.MissingMethodException: No parameterless constructor defined for type 'X'System.InvalidOperationException: Cannot create an instance of type Y because it has no public parameterless constructor- 序列化时抛
NotSupportedException，提示“无法访问私有成员”或“类型未注册”
根本原因：裁剪器把反射实际需要的元数据（RuntimeTypeInfo、属性访问器、泛型实例）当“死代码”移除了。
TrimmerRootAssembly 和 DynamicDependency 怎么选？
两者都是告诉裁剪器“别动这部分”，但适用层级不同：
-
<trimmerrootassembly>System.Text.Json</trimmerrootassembly>：粗粒度，保整个程序集。适合你只用它做基础 JSON 序列化，且不想深究细节。 -
[DynamicDependency(nameof(JsonSerializer.Serialize), typeof(JsonSerializer))]：细粒度，只保指定方法及可达路径。适合已知具体反射入口，想最小化保留范围。 - 更稳妥的做法是组合使用：
TrimmerRootAssembly兜底 +DynamicDependency精准加固关键路径。
注意：TrimmerRootAssembly 必须写在 .csproj 的 <propertygroup></propertygroup> 里，不是 <itemgroup></itemgroup>；而 DynamicDependency 要加在调用反射的类或方法上（比如你的 Startup 或 Program 类顶部）。
第三方库不标 IsTrimmable 怎么办？
很多 NuGet 包（尤其是老版本 SDK 工具链写的）没声明自己支持裁剪，裁剪器就会对它们“保守处理”——要么跳过分析，要么误删。这时你有两个选择：
- 升级到已标注
<istrimmable>true</istrimmable>的新版库（查其.nuspec或 GitHub release notes） - 在自己项目中手动补全根引用：
<trimmerrootassembly>Newtonsoft.Json</trimmerrootassembly>或<trimmerrootassembly>MyCompany.Core</trimmerrootassembly> - 如果库内部用了自定义反射（比如通过
Assembly.GetExecutingAssembly().GetTypes()扫描），必须用[UnconditionalSuppressMessage]抑制警告，并加DynamicDependency显式声明所有可能被扫到的类型。
别指望 SuppressTrimAnalysisWarnings=true ——它只是藏起警告，不解决实际缺失。
裁剪后体积没变小？检查这三处
裁剪效果差，往往不是配置没开，而是被以下因素抵消了：
-
<publishsinglefile>true</publishsinglefile>没开：裁剪只减 IL 大小，不压缩资源/依赖打包，单文件模式才能体现体积优势 - 启用了
<publishreadytorun>true</publishreadytorun>：R2R 会保留大量 JIT 缓存，和裁剪目标冲突，建议关掉 - 项目含大量嵌入资源（
<embeddedresource></embeddedresource>）、图标、本地化卫星程序集：这些不会被裁剪，但会塞进单文件包，拉高最终体积；可改用按需加载或外部文件
真正有效的瘦身组合永远是：裁剪 + 单文件 + 压缩（EnableCompressionInSingleFile=true），缺一不可。
裁剪不是开关，是契约——你得告诉工具哪些反射路径不能动，否则它按规则办事，删得干净利落，也崩得猝不及防。最常被忽略的，是那些没写在源码里、却在运行时靠字符串拼接触发的反射调用，比如 Activator.CreateInstance(Type.GetType("MyType")) 这种，连 DynamicDependency 都救不了，只能靠 TrimmerRootAssembly 或改代码。
