nameof是编译期语法糖，将标识符名转为字符串字面量，零开销、零反射；仅支持静态可解析表达式，如nameof(User.Id)，不支持实例成员如nameof(user.Name)，且不检查符号是否存在。
直接说结论：nameof 不是运行时工具，它是编译器在编译期就把标识符名“抄”成字符串字面量的语法糖，零开销、零反射、不查对象状态——用错场景，它就报错；用对地方，它能帮你挡住 80% 的拼写和重构漏改问题。
nameof 为什么在参数校验里几乎必须用
传统写法 throw new ArgumentNullException("userId") 看似简单，但变量一重命名为 id，这个字符串就变成“死代码”，编译不报错、IDE 不提示、运行时报错才暴露。
nameof 把字符串和符号绑定在了一起：
- 变量名改了 →
nameof(userId)立刻变红，编译失败 - 拼错了字母（比如
nameof(usreId)）→ 编译器直接报 CS0103：“名称‘usreId’在当前上下文中不存在” - 它生成的 IL 和手写
"userId"完全一样，没有额外性能负担
典型写法：
public void Process(string input)
{
if (input == null)
throw new ArgumentNullException(nameof(input));
}
nameof(x.Name) 合法，nameof(obj.Name) 却报错？搞清“静态可解析”边界
nameof 只接受编译器能静态确定名字的表达式。它不执行任何访问、不求值、不看实例。
✅ 合法（类型/静态成员路径）：
-
nameof(User.Id)——User是类型名，Id是其公开属性 -
nameof(List<int>.Count)——List<int>是类型，Count是其成员 -
nameof(MyClass)或nameof(MyClass.MyMethod)
❌ 报错（含实例、索引、空条件等）：
-
nameof(user.Name)——user是变量（实例），编译器无法保证它非 null，也不关心它的运行时类型 -
nameof(items[0])—— 索引器不是“成员名”，是调用表达式 -
nameof(obj?.Name)—— 空条件运算符让整个表达式不可静态解析
记住：点号左边必须是类型或命名空间，不能是变量或表达式。
泛型、@符号、嵌套命名空间这些细节怎么处理
nameof 返回的是“标识符原始拼写”，不带泛型参数、不带命名空间、不保留 @ 前缀。
-
nameof(List<string>)和nameof(List<>)都返回"List"，不是"List<string>" -
var @new = 5; nameof(@new)输出"new"（@ 仅用于避免关键字冲突，不参与名称） -
nameof(System.Collections.Generic)输出"Generic"，不是完整命名空间；要取"Collections"得写nameof(System.Collections) -
nameof(Foo.Bar.Baz)要求Foo在当前作用域可见（已using或是嵌套类），否则报 CS0246
想表达带泛型的完整类型名？别用 nameof，改用 typeof(List<string>).Name 或 .FullName。
在属性 setter 里写 nameof(value) 是个经典陷阱
很多人在 set 块里写 throw new ArgumentNullException(nameof(value))，以为它会报出属性名。但它实际返回的是字符串 "value"——因为 value 就是那个隐式参数名。
正确做法永远是显式写出属性名：
- ❌
set => _name = value ?? throw new ArgumentNullException(nameof(value)); - ✅
set => _name = value ?? throw new ArgumentNullException(nameof(Name));
同理，在 INotifyPropertyChanged 中，OnPropertyChanged(nameof(Name)) 才对；nameof(this.Name) 虽然能编译（如果 this 可省略），但语义冗余且易误导——nameof 不认 this. 前缀，它只认后面的 Name。
最常被忽略的一点：它不检查符号是否真被定义——你写 nameof(NonExistentThing)，只要它看起来像合法标识符（比如没拼错语法），编译器就信你，直到真正找不到时才报错。所以别指望它“提前兜底”，它只做名称搬运工，不做存在性担保。
