.net 8编译时拦截器仅支持static、public、无泛型/可选参数、void/基础类型返回、直接调用的场景，需用[interceptslocation]按行精准定位，本质是源码级宏替换，不适用于日志、权限等传统aop需求。
编译时拦截器（Interceptors）在 .NET 8 中不是运行时 AOP 工具，不能替代 Castle.DynamicProxy 或 Microsoft.Extensions.DependencyInjection.Abstractions 的拦截逻辑；它只在编译阶段重写 IL，且仅支持极有限的函数签名和调用场景。
哪些方法能被 Interceptors 拦截
必须同时满足以下全部条件，否则编译器直接忽略或报错：
- 目标方法是
static、public、无泛型参数（包括无T、无ref T）、无可选参数（int x = 0不允许） - 返回类型为
void、bool、int、string、Task、Task<t></t>（T必须是上述基础类型之一） - 所有参数类型必须是“编译时可静态分析”的：如
int、string、DateTime、MyPoco（需无复杂构造/字段初始化），但Span<byte></byte>、ref struct、delegate、dynamic均不支持 - 调用点必须是直接调用（
MyClass.Foo(1)），不能通过反射、委托、接口多态、虚方法派发——这些都会绕过拦截
Interceptors 的注册和使用方式
它不靠 DI 容器或属性标记生效，而是通过 [InterceptsLocation] + 编译器识别源码位置实现。实际流程是：
- 定义一个
static拦截方法，带[InterceptsLocation(...)]属性，参数必须严格匹配被拦截方法（含ref/out修饰符） -
[InterceptsLocation]的参数是字符串字面量，格式为"{文件路径}:{行号}"，例如"Program.cs:12"，且该行必须是完整的方法调用语句（不能是赋值右值、不能嵌套在if内部） - 项目文件中需显式启用：添加
<emitcompilergeneratedfiles>true</emitcompilergeneratedfiles>并引用Microsoft.CodeAnalysisSDK 包（非Microsoft.NET.Sdk默认包含） - 编译后，原调用被替换成拦截方法调用；原方法体仍存在，但不会被执行——除非你手动再调它
示例：Program.cs 第 15 行：
Console.WriteLine(Calculate(42));
拦截器写法：
[InterceptsLocation("Program.cs:15")]
public static int Calculate(int x) => x * 2 + 1;
为什么 Interceptors 很难用于日志/权限等常见场景
它本质是“源码级宏替换”，不是运行时代理。这意味着：
- 无法获取调用栈（
StackTrace在拦截方法里是空的，因为没发生真实调用） - 无法访问
this或实例状态（只支持static方法） - 无法统一拦截整个类或命名空间——必须逐行标注位置，维护成本爆炸
- 调试困难：断点打在原调用行会跳转到拦截方法，但 IDE 不保证跳转准确；生成的
.g.cs文件在obj/下，且默认不加载 - 单元测试容易失效：若测试直接调用被拦截方法（而非触发那行特定调用），拦截器完全不生效
替代方案建议：什么情况下该换别的技术
如果你需要的是传统意义上的“方法拦截”（比如记录耗时、校验参数、自动重试），请立刻放弃 Interceptors，改用：
- 运行时代理：用
DispatchProxy（轻量）或Castle.Core（功能全），适用于接口实现类 - 源码生成器（Source Generators）+ 手动注入逻辑：更可控，适合模板化增强（如自动生成
INotifyPropertyChanged） - 第三方 AOP 库：
Fody.PropertyChanged、AspectInjector，它们在 MSIL 层注入，兼容性更好 - .NET 9 的
Aspire或OpenTelemetry自动仪表化（针对 HTTP/gRPC 等入口）
真正适合 Interceptors 的场景极少：比如 SDK 内部对特定工具函数做零开销包装（如把 JsonSerializer.Serialize 替换为预分配缓冲版本），且你能完全控制调用点格式和路径稳定性。
