debuggerdisplay 特性必须加在类、结构体或属性上且每个类型仅一个，不支持继承；最简写法为[debuggerdisplay("name = {name}, age = {age}")]，其中{name}等需为可访问的public成员。
DebuggerDisplay 特性怎么写才生效
必须加在类、结构体或属性上，且只能有一个 DebuggerDisplay 特性作用于同一个类型。它不支持继承，子类要显示自定义内容得重新加。
最简写法是直接传格式字符串，比如：
[DebuggerDisplay("Name = {Name}, Age = {Age}")]其中 Name 和 Age 是当前类型的可访问字段或属性名，调试器会自动求值并显示。
- 字符串里支持嵌套表达式，如
{ToString(),nq}表示调用ToString()并去掉引号（nq是内建格式说明符） - 不能写复杂语句（如
{GetDisplayName()}除非该方法是 public 且无参数） - 如果引用的成员不存在或不可访问，调试器会显示空白或报错，但不会编译失败
为什么 DebuggerDisplay 显示的是“{Name}”而不是实际值
常见原因是字段/属性名拼写错误、访问级别不对（比如用了 private 字段但没加 get 属性），或者目标成员被标记为 [DebuggerBrowsable(DebuggerBrowsableState.Never)]。
另一个典型情况是：你在格式串里写了 {this.Name} 或 {_name} —— 调试器默认只识别当前实例的公开成员，不支持 this. 前缀，也不推荐直接访问私有字段（即使能访问，也容易因优化或编译器行为变化而失效）。
- 优先用 public 属性封装字段，再在
DebuggerDisplay中引用该属性名 - 避免在格式串中调用可能抛异常的方法（如未初始化的集合的
Count），否则调试器可能卡住或跳过显示 - VS 调试窗口里右键变量 → “快速监视” 可验证表达式是否可求值
想显示复杂逻辑？用 DebuggerDisplay 引用专用调试属性
当需要条件判断、拼接多个字段、或调用计算逻辑时，硬塞在格式串里既难读又难维护。更稳妥的做法是新增一个 private 的、带 [DebuggerBrowsable(DebuggerBrowsableState.Never)] 的只读属性，专供调试器使用。
例如：
private string DebuggerDisplay => $"'{Name}' ({Status ?? "unknown"}) - {Items?.Count ?? 0} items";然后写：[DebuggerDisplay("{DebuggerDisplay}")]
- 这个
DebuggerDisplay属性本身不会出现在 IntelliSense 或生产代码中，仅调试器可见 - 命名不必叫
DebuggerDisplay，只要符合 C# 命名规范即可，比如DebugSummary - 注意不要在该属性里触发副作用（如日志、网络请求），调试器可能多次求值该属性
DebuggerDisplay 在不同 VS 版本或 .NET 运行时下表现不一致
核心机制稳定，但细节有差异：.NET Framework 下对 private 成员访问更宽松；.NET 5+ 默认启用更严格的表达式求值策略，某些反射调用或动态绑定可能被禁用；Visual Studio 2022 对格式串中的空格和换行处理比旧版更严格。
如果你发现本地显示正常，但 CI 构建机器或同事环境里不生效，先检查是否启用了“启用 .NET Framework 源代码调试”或“使用托管兼容模式”（项目属性 → 调试 → 启用本机代码调试）——这些开关会影响调试器加载和解析特性的方式。
- 发布配置（Release）下
DebuggerDisplay仍有效，但若启用了“优化代码”，某些属性可能被内联或消除，导致调试显示异常 - 跨平台调试（如 VS Code + OmniSharp）对
DebuggerDisplay支持有限，部分格式说明符（如nq）可能被忽略
调试器显示逻辑看似简单，但真正稳定可靠的关键在于：把展示逻辑收敛到一个明确、无副作用、访问可控的入口点，而不是依赖调试器的隐式行为。
