.net 8编译时拦截器必须由源生成器生成，手写[interceptslocation]无效；需满足路径/行号/列号精确匹配、静态方法调用、签名完全一致，并在.csproj中启用interceptors特性。

拦截器不是运行时 Hook，不能动态启用/禁用；它只在编译期生效，且必须配合源生成器使用——单独写一个 [InterceptsLocation] 方法毫无作用。

为什么 [InterceptsLocation] 标记后调用没被替换？

最常见原因是：编译器根本没看到这个特性，或它被定义在错误的上下文中。

• [InterceptsLocation] 必须由源生成器（Source Generator）生成，不能手写在用户项目代码里（C# 12 当前限制）
• 该特性类型 InterceptsLocationAttribute 必须定义在 System.Runtime.CompilerServices 命名空间下，否则编译器忽略
• 目标调用点必须是**静态方法调用**，且签名与拦截器方法兼容（参数数量、类型、顺序一致）
• 项目文件（.csproj）中未启用实验性功能：<features>interceptors</features>

[InterceptsLocation] 的三个参数到底怎么填？

它不是“模糊匹配”，而是精确到字符位置的硬绑定。填错任意一项，拦截就失效。

C#

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

• 第一个参数是相对或绝对路径，推荐用相对路径（如 "Program.cs"），但需确保和编译器解析的路径完全一致
• 第二个参数是**行号（从 1 开始）**，对应原始调用语句所在的行，不是方法定义行
• 第三个参数是**列号（从 0 开始）**，指调用表达式的起始字符偏移量（例如 Logger.Log("msg") 中 L 是第 0 列）
• VS 或 VS Code 的“转到定义”+ 光标位置可辅助获取行列信息；但注意：预处理器指令、注释、缩进都会影响列计算

拦截器方法签名有哪些硬性要求？

编译器会严格校验签名兼容性，不满足则静默跳过，不会报错。

• 必须是 static 方法，且不能是 partial（除非整个类是 static partial）
• 返回类型必须与原方法一致（void 对 void，string 对 string）
• 参数列表必须逐项匹配：类型相同、顺序相同；支持 [CallerArgumentExpression] 等编译器特殊参数，但不能多也不能少
• 不能有 ref / out 参数（当前 C# 12 限制）
• 泛型方法调用暂不支持直接拦截（需源生成器展开为具体类型后再绑定）

调试拦截失败时，第一步该看什么？

别急着改代码，先确认编译器是否真的“看见”了拦截意图。

• 检查生成的 .dll 或反编译 IL：用 ildasm 或 dotnet ilc 查看调用点是否已变成对拦截器的调用
• 开启编译器详细日志：dotnet build -v:d，搜索关键词 interceptor 或 InterceptsLocation
• 确认源生成器是否成功执行：在生成器项目中加 Console.WriteLine（仅开发时），或查看 obj/Debug/net8.0/Generated/ 下是否有输出文件
• 注意：拦截器不参与 JIT 编译，也不出现在堆栈跟踪中——它在 IL 层就被替换了，所以调试器里看不到“跳转”过程

真正容易被忽略的是：拦截器不是魔法开关，它是编译器驱动的静态重写。你写的每一处 [InterceptsLocation] 都像一把定制钥匙，只开一把锁——锁的位置、形状、材质都得严丝合缝，差一微米，门就打不开。