关于C# 12 Interceptors的用途与使用合理性的技术问询

核心价值 #

拦截器的核心是编译阶段的方法调用改写能力——它不是运行时的动态拦截（比如传统AOP的动态代理），而是在代码编译为IL之前，直接替换目标方法的调用逻辑。这是它和其他拦截方案最本质的区别，也是其价值的核心所在。

为何不直接调用目标方法？ #

很多场景下，直接调用目标方法要么做不到，要么会导致代码冗余：

• 无法修改目标代码：如果目标方法来自第三方库、框架内置代码（比如HttpClient.GetAsync、EF Core的SaveChanges），你没有权限修改其源码，但又需要给这些方法加统一逻辑（比如超时、事务、日志），拦截器可以在不碰原代码的前提下，替换所有调用。
• 依赖编译期信息的逻辑：有些需求需要用到调用方的文件名、行号、编译模式（Debug/Release）等编译期才存在的信息，运行时AOP拿不到这些数据，拦截器却能在编译阶段直接嵌入这些信息到逻辑里。
• 批量统一修改：如果项目里有上百处重复的方法调用，要统一加相同逻辑（比如给所有API请求加请求头），一个个改业务代码既麻烦又容易遗漏，拦截器能一次性批量替换所有调用。

语法看似不友好，为什么还要用？ #

确实，拦截器的语法不算直观——需要配合[Interceptor]属性、源生成器，还要写模板代码，但它解决的是其他方案搞不定的痛点：

• 编译期安全的无侵入增强：运行时动态代理依赖反射，有性能损耗，而且错误要到运行时才暴露；拦截器是编译时直接生成目标逻辑的IL，没有反射开销，逻辑错误编译阶段就能发现。
• 适配无扩展点的第三方代码：有些框架或库没提供钩子、扩展方法，你想加逻辑只能重写或改源码，拦截器能绕过这些限制，直接拦截方法调用。
• 保持业务代码纯净：把日志、缓存、校验等横切逻辑从业务代码里抽离，用拦截器自动注入，业务代码只需要关注核心逻辑，不用被非业务代码污染。

举个实际场景的例子：给所有业务方法加自动日志埋点。不用拦截器的话，每个方法都要手动写Logger.Log()；用拦截器后，只需要给方法加个标记，编译时自动生成带日志的代码，业务代码完全不用动。

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