属性定义必须带 get 或 set 访问器
在 C# 中，
property不是字段的别名，而是封装了
get和/或
set访问器的方法对。没有访问器的“属性”语法不合法——编译器会报错
CS0542: 'X' does not contain a definition for 'Y'或更直接的
CS0501: 'X.Y' must declare a body。
常见误写：
public string Name; // 这是字段，不是属性它不触发属性机制，无法拦截读写、无法绑定 UI、不能被序列化器（如
JsonSerializer）默认识别为可序列化成员。 只读属性：用
get+
private set或 C# 6+ 的
get; init;计算属性：只写
get，内部返回表达式或逻辑结果，不 backing field 自动实现属性：写
get; set;即可，编译器自动生成隐藏字段
自动属性 vs 手动实现属性的区别在哪
自动属性（如
public int Age { get; set; }）由编译器生成一个不可见的 backing field，你无法在 get/
set中直接访问该字段名；而手动属性必须显式声明私有字段，并在访问器中读写它。
这意味着：如果你需要在赋值时校验、触发事件、或做日志，就必须用手动实现。例如：
private string _name;
public string Name
{
get => _name;
set
{
if (string.IsNullOrWhiteSpace(value))
throw new ArgumentException("Name cannot be null or empty");
_name = value.Trim();
}
}而自动属性做不到这点——除非用
init（仅限构造/初始化阶段）或配合
required（C# 11+），但它们仍不支持运行时校验。 自动属性适合数据载体（DTO、POCO）、配置类等无业务逻辑场景 手动属性适合需要控制访问语义的领域模型
get; init;可用于不可变对象构建，但初始化后
set就失效
属性在序列化和 WPF 绑定中的行为差异
多数 JSON 序列化器（如
System.Text.Json、
Newtonsoft.Json）默认只序列化 public 自动属性，忽略字段和 private 成员。但如果你把
set设为
private或
internal，
System.Text.Json仍能反序列化（只要类型有无参构造），而
Newtonsoft.Json需要额外配置
JsonPropertyAttribute或
ContractResolver。
WPF 的
Binding则严格依赖
INotifyPropertyChanged接口：只有在
set中调用
OnPropertyChanged(nameof(X))，UI 才会响应变化。单纯定义
public string X { get; set; } 是不够的。
没实现 INotifyPropertyChanged的属性，WPF 绑定显示值但不更新界面
[JsonIgnore]或
[JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]控制序列化行为，不影响属性本身 使用
record类时，所有自动生成的属性默认是
get; init;，且支持
with表达式
只读属性和 init-only 属性的适用边界
C# 9 引入
init访问器，允许在对象初始化器或
with表达式中赋值，之后不可再改。但它不是运行时只读——编译器只是禁止后续的
=赋值，反射或 unsafe 代码仍可修改。
真正只读应选
getonly + backing field（C# 6+ 支持
get => expr;），或 readonly 字段 + public getter 方法（非属性）。例如：
public string FullName => $"{FirstName} {LastName}"; // 计算属性，无存储开销注意：若
FirstName或
LastName变了，
FullName不会自动刷新，除非你手动触发通知或用
ObservableProperty（MVVM Toolkit）等方案。
get; init;适合 DTO 初始化后不再变更的场景（如 API 响应对象） 纯
get属性适合无状态计算，避免意外副作用 不要在
get中做 I/O、锁、或耗时操作——属性访问预期是轻量的
属性真正的复杂点不在语法，而在语义控制权的让渡：你决定什么时候允许读、谁可以写、写之前要不要检查、写之后要不要通知。漏掉这些判断，后面调试绑定失败、序列化空值、或并发修改异常，都很难一眼定位。
