加了[Obsolete]却没警告，大概率是漏传非空字符串消息；它只影响编译期静态分析，对反射调用、序列化、路由等运行时行为完全无效。
加了 [Obsolete] 却没警告？大概率是漏传消息字符串，或者误以为它能拦住反射调用。
为什么加了[Obsolete]但编译器不报任何提示？
最常见原因是只写了 [Obsolete] 而没提供描述性字符串。编译器确实会识别该标记，但仅生成极简警告（如“'OldMethod()' 已过时”），且部分 IDE 或构建配置可能默认隐藏这类低优先级警告。
- ✅ 正确写法必须带非空字符串：
[Obsolete("请改用 UserService.GetActiveUsers()")] - ❌
[Obsolete]（无参）或[Obsolete(null)]都不会显示有效提示 - ⚠️ 字符串必须是编译期常量：不能是
$"Use {NewMethod}"或拼接变量，否则编译直接失败
[Obsolete] 的第二个参数 true 到底做什么？
它把警告升级为编译错误（CS0612 / CS0618），让调用点无法通过编译。不是“更严重警告”，而是彻底阻断。
- 设为
true后，哪怕只在单元测试里调用一次OldMethod()，也会中断整个构建 - 类上标
[Obsolete("", true)]：所有new OldClass()、继承、静态访问都会报错 - ⚠️ 风险高：若该方法被基类公开、又被多个子类间接调用，开启
true可能导致几十处编译失败——建议先用false观察一周，再切
哪些地方[Obsolete]根本不起作用？
它只影响编译器静态分析，对运行时行为完全透明。以下场景不会触发任何警告或错误：
- 通过反射调用：
typeof(MyClass).GetMethod("OldMethod").Invoke(obj, null) - 序列化反序列化（如 JSON.NET 读取含旧字段的 JSON）
- ASP.NET Core 中已注册的路由仍可访问被标记的 Action ——
[Obsolete]不影响路由匹配 - 属性的
set被弃用，但只标记整个属性：应单独标记set访问器，而非get和set一起
弃用一个类时，容易漏掉哪些关键入口？
类级别标记看似一劳永逸，但实际调用路径往往绕过类声明本身：
- 构造函数（尤其是
public OldClass()）需单独确认是否也标记 - 静态工厂方法（如
OldClass.Create()）必须各自加[Obsolete] - JSON 序列化用的
[JsonConstructor]构造函数，即使类已标记，它仍可被反序列化调用 - 若类实现接口，接口方法未同步弃用，外部仍可通过接口引用调用旧逻辑
真正起效的弃用，得顺着所有可能的调用链手动检查——编译器不会替你推导间接依赖。
