很多 C# 初学者第一次接触类设计时，都会把字段和属性当成“语法上差不多的两种写法”，结果要么把数据完全裸露出去，要么把简单模型写得过度繁琐。要真正用好它们，关键不在于背定义，而是先看两者分别负责什么，再看业务约束该落在哪一层。读完这篇，你可以明确判断：哪些场景适合直接存值，哪些场景必须通过属性做校验、只读控制或初始化约束。
字段是什么，为什么不适合随便公开
字段（Field）是类或结构中直接声明的变量，它最核心的职责只有一个：作为对象状态的一部分，实际存储数据。
字段的基本声明
public class Student
{
// 这就是两个字段
public string Name; // 学生姓名
public int Age; // 学生年龄
}
这类写法很好理解：类里有什么状态，就声明什么变量。字段本身不负责访问规则，也不负责校验，它只是数据真正放置的位置。
公开字段的问题在哪
Student stu = new Student();
stu.Name = "张三";
stu.Age = -10; // 灾难！年龄怎么可能是负数？
Console.WriteLine($"{stu.Name}的年龄是 {stu.Age}岁。");
// 输出: 张三的年龄是 -10岁。
当字段使用 public 暴露出去时，外部代码可以在任何地方直接读写它。这样做的风险很直接：对象虽然有了值，但这些值不一定合法。年龄被写成 -10 这种问题，编译器不会帮你拦住，类本身也没有任何缓冲层。
所以，公开字段最大的问题不是“语法不优雅”，而是它让对象失去边界感。只要值能写进去，类就只能被动接受。
把字段设为 private 后，通常要补一层访问方法
更常见的思路是把字段隐藏起来，只允许类自己直接接触数据；外部如果要读写，就通过公开方法进入。
public class Student
{
// 将字段设为private，外界无法直接访问
private string _name;
private int _age;
// 为了让外界能设置和获取值，我们提供一对公开的方法
public string GetName()
{
return _name;
}
public void SetName(string name)
{
// 可以在这里加入验证逻辑
if (string.IsNullOrWhiteSpace(name))
{
Console.WriteLine("姓名不能为空！");
return;
}
_name = name;
}
public int GetAge()
{
return _age;
}
public void SetAge(int age)
{
// 验证逻辑！
if (age < 0 || age > 150)
{
Console.WriteLine("年龄不合法！");
return;
}
_age = age;
}
}
// === 使用 ===
Student stu = new Student();
stu.SetName("李四");
stu.SetAge(-10); // 输出: 年龄不合法！
stu.SetAge(25);
Console.WriteLine($"{stu.GetName()}的年龄是 {stu.GetAge()}岁。");
这时类就获得了最关键的能力：外部虽然还能操作数据，但必须走你规定的入口。你可以在入口里加校验、日志、权限判断，或者阻止非法值落入对象内部。
不过，这种 GetXxx/SetXxx 写法虽然有效，也开始暴露出一个问题：代码会变得机械重复。属性正是为了解决这个问题出现的。
属性的本质：像字段一样访问，像方法一样可控
属性（Property）可以理解为字段外面的一层正式访问接口。它通常服务于私有字段，对外提供统一的读取和写入入口，同时又保留字段式的使用体验。
它的关键价值在于把“封装能力”和“调用简洁度”合在一起：调用者写起来像访问成员变量，类内部却仍然能在读写时执行逻辑。
完整属性由字段和 get/set 访问器组成
一个完整属性通常包含私有字段，以及一对 get/set 访问器。
public class Student
{
// 1. 私有字段，用于实际存储数据
private int _age;
// 2. 公开属性，作为外界访问的入口
public int Age
{
// 3. get访问器：当读取属性时执行
get
{
// 可以加入逻辑，比如权限检查
return _age;
}
// 4. set访问器：当给属性赋值时执行
set
{
// 'value'是一个上下文关键字，代表赋过来的值
if (value < 0 || value > 150)
{
// 可以抛出异常，这是更推荐的做法
throw new ArgumentOutOfRangeException(nameof(Age), "年龄必须在0到150之间。");
}
_age = value;
}
}
}
// === 使用属性 ===
Student stu = new Student();
try
{
stu.Age = 25; // 调用set访问器，value为25
Console.WriteLine(stu.Age); // 调用get访问器
stu.Age = -10; // 调用set访问器，value为-10，抛出异常
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
这里最值得注意的是两点。
第一，Age 对外看起来像字段，写法仍然是 stu.Age = 25 和 Console.WriteLine(stu.Age)，调用成本很低。
第二，类内部并没有失去控制权。只要进入 set，就能基于 value 做合法性判断；一旦值超出 0 到 150 的范围，就通过 ArgumentOutOfRangeException 立即阻止写入。
这也是属性在 C# 中成为主流写法的根本原因：它不是“字段的别名”，而是带访问语义的成员。
字段和属性到底该怎么区分
一个更实用的判断方式是：
- 字段关注的是“数据存在哪里”
- 属性关注的是“数据允许怎样被访问”
如果某个值只是类内部实现细节，通常放在私有字段里；如果某个值需要暴露给外界读写，且希望未来还能增加校验、只读限制或计算逻辑，优先用属性。
也正因为如此，在现代 C# 开发里，公开字段通常非常少见。大多数对外成员，最终都会落到属性上。
日常开发最常见的属性写法
C# 后续版本不断简化属性语法，使很多场景不再需要手写完整字段和访问器。理解这些“语法糖”，能帮助你在简洁与可控之间做更合适的取舍。
自动实现属性：没有额外逻辑时的首选
如果属性只是单纯保存和返回一个值，不需要额外验证逻辑，那么完整写出字段和 get/set 就显得很啰嗦。这时可以直接使用自动实现属性。
public class Product
{
// 这就是自动属性
// 编译器会自动在幕后创建一个私有的、匿名的字段
public string Name { get; set; }
public decimal Price { get; set; }
}
// === 使用 ===
Product phone = new Product();
phone.Name = "Phone X"; // 背后调用了自动生成的set
phone.Price = 999.99m;
这类写法在业务模型、DTO、配置对象中极其常见。它的本质并没有变，依然是属性；只是字段由编译器代为生成了。
实际经验上可以这样记：默认先写自动属性，只有当你确实需要自定义读写逻辑时，再退回完整属性实现。
为 get 和 set 分别控制访问级别
属性的另一个强项，是读写权限可以拆开设计。也就是说，你可以允许外部读取，但限制外部修改。
public class Order
{
// Id只能在类的内部被设置（比如在构造函数中）
// 但可以在任何地方被读取
public int Id { get; private set; }
public DateTime OrderDate { get; } // 只有get，这是一个只读属性
public Order(int id)
{
this.Id = id; // 在内部设置是合法的
this.OrderDate = DateTime.UtcNow; // 只读属性只能在构造函数或声明时赋值
}
}
Id { get; private set; } 的意义很明确：对象一旦创建好，外部代码不能再随意篡改标识，但依然能读取它。至于 OrderDate { get; }，则进一步收紧为只读属性，只允许在声明时或构造函数中赋值。
这种模式很适合处理“创建后应保持稳定”的状态，例如编号、创建时间、生命周期关键节点等。
表达式主体属性：适合计算型只读值
有些属性并不真正存储数据，而是根据其他成员即时计算结果。对于这种只读且逻辑简单的场景，表达式主体属性更紧凑。
public class Person
{
public string FirstName { get; set; }
public string LastName { get; set; }
// 这个只读属性的值是计算出来的
public string FullName => $"{FirstName} {LastName}";
}
FullName 没有独立字段，也不需要手动同步。每次读取时，都会基于 FirstName 和 LastName 计算结果。这样既避免了重复存储，也减少了数据不一致的风险。
C# 中更值得注意的特殊属性能力
除了常规的 get/set，C# 还为属性加入了一些更偏现代设计风格的能力，用来表达“初始化后不可改”或“创建时必须提供”的意图。
`init` 访问器：只能在初始化阶段赋值
init 访问器提供了一种“初始化时可写，完成后只读”的语义。它尤其适合那些在对象创建时就应确定、后续不该再变的值。
public class Book
{
public string Isbn { get; init; } // 注意是init
public string Title { get; init; }
}
// === 使用 ===
var book = new Book
{
Isbn = "978-0321765723", // 合法！在对象初始化器中赋值
Title = "The C# Programming Language"
};
// book.Title = "New Title"; // 编译错误！初始化完成后，不能再修改
和只读属性相比，init 更灵活，因为它允许你继续使用对象初始化器；但和普通 set 相比，它又更安全，因为初始化完成后就不再允许外部修改。
当你希望对象具备一定的不可变性，同时又不想牺牲初始化体验时，init 是非常合适的选择。
`required` 修饰符：把必填要求前移到编译期
required 的作用是告诉调用方：创建对象时，这个属性必须赋值，否则代码就不完整。
public class User
{
public int Id { get; set; }
public required string Username { get; set; } // 必须在创建时提供值
public string Email { get; set; } // 可选
}
// === 使用 ===
// var user1 = new User(); // 编译错误！Username是required的，但没有被赋值。
var user2 = new User { Username = "alice" }; // 正确
它的价值在于把“缺少关键数据”这类问题尽量提前到编译阶段，而不是等对象跑到业务流程中再暴露空值问题。对于账户、配置、命令对象这类有明确必填项的模型，required 往往比运行时补检查更直接。
实际开发里怎么选：记住这几个判断标准
把全文内容压缩成可执行的判断规则，大致可以归纳为下面几条。
- 如果只是类内部保存状态，优先使用私有字段。
- 如果成员需要对外暴露，通常优先使用属性，而不是公开字段。
- 如果没有额外逻辑，优先使用自动实现属性
{ get; set; }。 - 如果需要校验、异常、权限或派生计算，就使用手动实现属性。
- 如果外部只能读不能改，可以使用
private set、只读属性或init。 - 如果属性在创建对象时必须提供值，可以考虑
required。
从设计角度看，字段是存储层，属性是边界层。前者决定对象“把值放在哪里”，后者决定对象“允许别人怎样接触这些值”。一旦把这层关系理顺，很多关于封装、只读性和模型设计的判断就会自然清晰起来。
