nameof在编译期获取标识符名称并生成常量字符串，零运行时开销；用于参数校验、INotifyPropertyChanged、数据注解等场景，确保重构安全与编译时检查。
nameof 不是用来“运行时获取名字”的，它在编译期就确定了字符串值，生成的 IL 里直接是常量字符串。你写 nameof(UserName)，和手写 "UserName" 在最终执行上没区别，但前者能被编译器盯住——改名不更新？直接报错。
什么时候必须用 nameof 而不是硬写字符串
核心判断标准：只要这个字符串代表的是你代码里某个真实存在的标识符（变量、属性、方法、类型），且未来可能重命名，就该用 nameof。
- 参数校验抛异常时的参数名：
throw new ArgumentNullException(nameof(userId))—— 改了变量名，这里立刻编译失败，不会漏掉 - 实现
INotifyPropertyChanged时通知的属性名：OnPropertyChanged(nameof(Email))—— WPF/MAUI 绑定靠这个刷新，拼错或没同步就静默失效 - 数据注解里的字段名：
[Required(ErrorMessage = "The " + nameof(Password) + " field is required")]—— 验证消息动态匹配，重构安全 - API 路由跳转别名：
CreatedAtRoute(nameof(GetOrderById), new { id = 123 })—— 方法改名后路由链接自动失效，而不是返回 404 却查不出原因
nameof 能写哪些表达式，哪些会报错
它只接受“可被编译器静态解析出名称”的东西，不是任意表达式都能套进去。
- ✅ 支持：
nameof(User.Name)、nameof(list.Count)、nameof(MyClass)、nameof(TestMethod)、nameof(List<int>)（返回"List"） - ❌ 不支持：
nameof(user?.Name)（带空条件运算符）、nameof(items[i])（含索引器）、nameof(GetValue())（调用方法）、nameof(x => x.Name)（lambda 表达式本身） - ⚠️ 注意：
nameof(@new)返回"new"（去掉@前缀），nameof(System.Collections.Generic)返回"Generic"，不是完整命名空间
常见误用和坑点
看起来简单，实际踩坑不少，尤其在泛型、嵌套和测试场景下。
- 别对局部变量以外的“计算结果”用：
var prop = user.Name; nameof(prop)返回"prop"，不是"Name"—— 它取的是变量名，不是源头 - 泛型类型写法要小心：
nameof(List<string>)和nameof(List<>)都返回"List"，无法区分具体泛型参数；想表达"List<string>"只能手动拼 - 在属性 setter 里慎用
nameof(value)：它返回的是"value"字符串，不是当前属性名；正确做法是nameof(PropertyName) - 单元测试中别依赖
nameof去“猜”方法行为：比如Assert.IsTrue(methodCalled == nameof(DoWork))，这其实把逻辑耦合进了字符串，不如直接验证副作用
它不解决什么问题
nameof 是个轻量级编译期工具，别指望它做运行时反射或动态元编程的事。
- 它不能替代
typeof(T).Name或obj.GetType().GetProperty("Name")—— 那些是运行时行为，nameof根本不参与 - 它不生成任何额外的元数据，也不影响程序集大小（就是个字符串常量）
- 它对性能零影响：没有装箱、没有反射开销、没有字符串拼接，IL 里就是
ldstr "Name"
nameof 的作用域是词法作用域，不是运行时上下文。你写 nameof(x)，编译器只看当前作用域里有没有叫 x 的声明，而不管它背后指向什么对象、有没有值、是不是 null —— 这既是它的健壮性来源，也是它能力边界的所在。 
