C# on 寒流の编程笔记

在 C# 15 的 Union 类型到来之前我们都是怎么过的？

Sat, 09 May 2026 00:00:00 +0000

截止到目前，.NET 11 已经出了三个预览版了，并且也为我们带来了万众期待的 Union 类型。关于这个类型，有不少大佬已经讨论过了，这里贴两个供大家参考：

所以这里我们就不赘述关于 Union 类型的语法、作用、底层原理之类的内容了。我们这次要聊一聊的是，在 Union 类型到来之前，我们都是怎么过的，或者说我们面临的问题都是如何解决的。通过对以往方式的讨论，我们或许会更加意识到 Union 类型有多么棒。

Union 类型的核心目标

在回顾旧方案之前，我们先明确一下 Union 类型想要解决的核心问题：

归类某些类型，但是不必共享行为：我们希望把几种相关的类型归为一组，但它们之间不需要有继承关系或共同的接口实现。
在编译时能够穷尽各种情况：当我们对一个联合类型的值进行处理时，编译器能够检查我们是否覆盖了所有可能的情况。
减少心智负担和运行时错误：类型系统应该在编译期就帮我们排除掉"忘记处理某种情况"的隐患。
锦上添花，最好还能减少装箱的开销。

带着这些目标，我们来看看过去 C# 开发者们是怎么做的。

枚举类型 enum

在了解 Union 类型时，我们常常会看到诸如返回不同状态的代码，比如：

1
2
3


public union Result(Success, Error);

public Result GetResult() { /* 最终返回 Result 中的某种具体类型的实例 */ }

在没有 Union 类型的时候，很多人第一反应就是使用枚举：

1
2
3
4
5
6
7


public enum Status
{
 Success,
 Failed
}

public Status GetResult() { /* ... */ }

枚举类型本质上是值类型，只能包含单个分类，不能包含更多的内部信息。如果 Success 需要携带返回数据，Failed 需要携带错误信息，枚举就无能为力了。你不得不额外定义配套的字段或类来传递这些信息，导致数据和状态分离，增加了维护成本。

包含多个属性的类

既然枚举无法携带数据，很自然的想法就是定义一个"大而全"的类，把所有可能用到的属性都放进去：

1
2
3
4
5
6


class Result<T>
{
 public T? Data { get; set; }
 public Exception? Error { get; set; }
 public bool IsSuccess => Error is null;
}

这样的类型无法限制类成员之间的关系，只能依靠人为的约束和尽可能多的防御性编程。

比如上面这个例子，可能会出现 Data 和 Error 同时存在的情况，导致 IsSuccess 不可靠。如果成员变多，会更加不可控，势必会出现更多人为的检查：

1
2
3
4
5
6
7


var result = GetResult();
if (result.IsSuccess)
{
 // 编译器无法保证 result.Data 不为 null
 // 我们只能祈祷调用方遵守约定
 Console.WriteLine(result.Data!.ToString());
}

类型系统在这里完全帮不上忙，正确性全靠程序员的自觉和代码审查。

object 类型

将变量声明为 object 类型确实可以一定程度上实现表示多种类型的能力，并且借助模式匹配及 switch 语法可以实现灵活的功能：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


object result = GetSomething();

switch (result)
{
 case int i:
 Console.WriteLine($"Integer: {i}");
 break;
 case string s:
 Console.WriteLine($"String: {s}");
 break;
 default:
 throw new NotSupportedException();
}

但有几个明显的问题：

编译时无法得知变量类型，缺乏代码提示：object 可以表示任何东西，IDE 无法给出有意义的智能提示。
难以涵盖所有情况：编译器不会检查你是否处理了所有可能的类型，必须手动提供兜底方案（default 分支）。
可能存在装箱拆箱的开销：值类型赋值给 object 时会发生装箱，带来额外的性能开销。
类型安全性差：任何类型都可以赋值进去，运行时出错的风险很高。

空的抽象基类或接口

比 object 类型稍微好一点的做法是定义一个空的抽象基类或接口：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


public abstract class Result { }

public class Success<T> : Result
{
 public T Data { get; }
 public Success(T data) => Data = data;
}

public class Error : Result
{
 public string Message { get; }
 public Error(string message) => Message = message;
}

这样可以一定程度上限制可能性，提高编译时期的严谨性，但仍然有几个问题：

必须保证所有类型都继承自该抽象类：对于内置类型（如 int、string）或者来自第三方库的类型，我们完全无能为力，无法把它们纳入这个联合体系。
仍然需要提供兜底方案：switch 表达式中编译器不知道有哪些派生类，所以 exhaustive check 无从谈起。
无法保证封闭性：其他开发者随时可以写出新的继承该抽象类的类型，而你无法阻止。这就破坏了"有限种可能"的语义。

OneOf 第三方库

在 C# 社区中，OneOf 是一个非常流行的用于模拟 Union 类型的库。它的基本用法如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


using OneOf;

public OneOf<User, NotFound, ValidationError> GetUser(int id)
{
 if (id <= 0)
 return new ValidationError("Invalid ID");
 
 var user = _db.FindUser(id);
 if (user is null)
 return new NotFound();
 
 return user;
}

// 使用
var result = GetUser(42);
result.Match(
 user => Console.WriteLine(user.Name),
 notFound => Console.WriteLine("User not found"),
 error => Console.WriteLine(error.Message)
);

这个库确实可以实现类型的联合，以及编译时的穷尽检查（通过 Match 方法要求你处理所有类型）。但存在一些弊端：

缺乏语言级别的语法糖

它不是语言特性，无法享受 C# 语法糖带来的便捷。你只能用它自己的 Match 等方法，不能用原生的 switch 语句、模式匹配等：

1
2
3
4
5
6
7
8


// 这是做不到的：
var result = GetUser(42);
var message = result switch // ❌ 编译错误
{
 User u => u.Name,
 NotFound _ => "Not found",
 ValidationError e => e.Message
};

代码繁杂

当联合的类型较多时，代码会显得繁杂。类型声明变成 OneOf<T1, T2, ..., Tn>，而 Match 语法中需要大量的 lambda 表达式：

1
2
3
4
5
6
7
8
9


OneOf<int, string, double, bool, DateTime> value = ...;

value.Match(
 i => HandleInt(i),
 s => HandleString(s),
 d => HandleDouble(d),
 b => HandleBool(b),
 dt => HandleDateTime(dt)
);

缺乏领域签名

OneOf<User, NotFound, ValidationError> 这样的类型虽然能表达联合，但缺乏语义上的清晰度。每次看到这个类型，你都需要在脑海中翻译一遍它的含义。

相比之下，union Result(User, NotFound, ValidationError) 这样的语法更直观，能够直接从类型定义中理解它的用途和意义。

OneOf<int, string> 则更是难以理解它的用途——它到底表示什么业务含义？无法从类型定义中推断出它的意义。

泛型参数顺序泄露到 API 设计里

OneOf<User, NotFound> 和 OneOf<NotFound, User> 是两个不同的类型，虽然它们表达的语义是一样的。这意味着如果你在一个地方用了 OneOf<A, B>，另一个地方用了 OneOf<B, A>，它们之间无法直接兼容，这会给 API 设计带来不必要的约束和混乱。

Union 类型的到来

现在，让我们看看 C# 15 的 Union 类型如何解决上述所有问题：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


public record class User(string Name);
public record class NotFound();
public record class ValidationError(string Message);

public union Result(User, NotFound, ValidationError);

public Result GetUser(int id)
{
 if (id <= 0)
 return new ValidationError("Invalid ID");
 
 var user = _db.FindUser(id);
 if (user is null)
 return new NotFound();
 
 return user; // 隐式转换
}

// 使用
var result = GetUser(42);

// ✅ 原生支持 switch 表达式和模式匹配
var message = result switch
{
 User u => $"Found: {u.Name}",
 NotFound _ => "User not found",
 ValidationError e => $"Error: {e.Message}"
 // 不需要兜底分支！编译器知道只有这三种可能
};

底层原理

本质上，Union 类型是编译器帮你生成的一个结构体，加上一个 object? 字段和隐式转换。当声明 union Pet(Cat, Dog, Bird) 时，实际上编译器后台会生成类似下面的代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


[System.Runtime.CompilerServices.Union]
public struct Pet : System.Runtime.CompilerServices.IUnion
{
 // 为每个情况类型生成构造函数
 public Pet(Cat value) => Value = value;
 public Pet(Dog value) => Value = value;
 public Pet(Bird value) => Value = value;

 // 核心存储：单个 object? 字段
 public object? Value { get; }
}

核心组件是 IUnion 接口，以及 [Union] 特性：

1
2
3
4


public interface IUnion
{
 object? Value { get; }
}

编译器会借助隐式转换等方式，在后台实现相关逻辑：

1
2
3
4
5
6
7
8
9


Pet pet = new Dog("Rex");
// 实际上是 new Pet(new Dog("Rex"))

pet switch
{
 Dog d => d.Name, // 编译器检查：pet.Value is Dog d
 Cat c => c.Name,
 Bird b => b.Name,
};

Tip

如果你现在就想体验 Union 类型，可以下载 .NET 11 预览版 SDK。不过需要注意的是，早期预览版中 UnionAttribute 和 IUnion 尚未内置在运行时中，需要手动添加 Polyfill 代码。

总结

回顾过去，C# 开发者为了模拟 Union 类型的能力，尝试过枚举、“大而全"的类、object、抽象基类、第三方库等各种方案。但它们各自都有明显的缺陷：要么无法携带数据，要么缺乏类型安全，要么语法繁琐，要么语义不清晰。

C# 15 引入的原生 Union 类型，不仅提供了简洁优雅的语法，更重要的是它让类型系统能够在编译期就帮我们保证正确性——穷尽检查、隐式转换、原生模式匹配支持，这些都是过去任何方案都无法同时满足的。

Union 类型的到来，标志着 C# 在类型系统上又迈出了一大步。对于那些熟悉 F#、Rust 或 TypeScript 中联合类型的开发者来说，绝对算得上等来了自己的“福报”。期待 C# 在未来能继续引入更多强大的类型特性，让我们的代码更安全、更简洁、更易维护。

如何在类外移除类的事件订阅？

Thu, 22 Jan 2026 00:00:00 +0000

某些时候，我们出于对第三方类库的定制需求，可能需要在类外移除该类的事件订阅。然而，事件本身就是一个封装良好的成员，直接访问和修改事件的订阅列表并不容易。不仅如此，为事件注册的方法可能还是私有的，这更是增加了难度。我们这次就来探讨如何通过反射机制实现这一目标。

简单情况

我们先来看一个最基本的例子。这里有一个 Demo 类，它定义了一个事件 MyEvent，并在构造函数中为该事件注册了一个事件处理器 MyEventHandler，并且也是这个类的私有方法。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


class Demo
{

 public Demo()
 {
 MyEvent += MyEventHandler;
 }

 public event EventHandler? MyEvent;

 void MyEventHandler(object? sender, EventArgs e)
 {
 Console.WriteLine("MyEvent event triggered");
 }
}

在这个情况下，我们可以借助反射来拿到 MyEvent 事件的底层字段，然后将它置空，从而移除所有的事件订阅。

1
2
3


var demo = new Demo();
var eventField = typeof(Demo).GetField("MyEvent", BindingFlags.Instance | BindingFlags.NonPublic);
eventField.SetValue(demo, null);

这样一来，MyEvent 事件的所有订阅都被移除了。

事件声明在基类上

有时候，事件可能声明在类的基类上，比如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


class Base
{
 public event EventHandler? MyEvent;
}

class Demo : Base
{
 public Demo()
 {
 MyEvent += MyEventHandler;
 }

 void MyEventHandler(object? sender, EventArgs e)
 {
 Console.WriteLine("MyEvent event triggered");
 }
}

这时候上面的方法就不奏效了。我们需要在反射时指定正确的类型：

1
2


var eventField = typeof(Base).GetField("MyEvent", BindingFlags.Instance | BindingFlags.NonPublic);
eventField.SetValue(demo, null);

如果再复杂一点，我们甚至都不知道这个事件到底声明在哪个类上，这时候我们可以通过遍历继承链来查找：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


Type? type = typeof(Demo);
FieldInfo? eventField = null;
while (type != null)
{
 eventField = type.GetField("MyEvent", BindingFlags.Instance | BindingFlags.NonPublic);
 if (eventField != null)
 {
 break;
 }
 type = type.BaseType;
}
eventField.SetValue(demo, null);

移除特定的事件处理方法

上面的方法都会移除所有的事件订阅。如果我们只想移除特定的方法怎么办？此时我们有两种方式。首先我们可以尝试获取事件的委托实例，然后从中移除特定的方法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


var eventField = typeof(Demo).GetField("MyEvent", BindingFlags.Instance | BindingFlags.NonPublic);
var eventDelegate = (MulticastDelegate?)eventField.GetValue(demo);
if (eventDelegate != null)
{
 foreach (var handler in eventDelegate.GetInvocationList())
 {
 if (handler.Method.Name == "MyEventHandler")
 {
 eventDelegate = (MulticastDelegate?)Delegate.Remove(eventDelegate, handler);
 }
 }
 eventField.SetValue(demo, eventDelegate);
}

Info

C# 中事件是基于委托实现的。每个事件在底层都有一个与之关联的委托字段，这个字段保存了所有注册到该事件的处理方法。当事件被触发时，实际上是调用这个委托，从而依次调用所有注册的方法。具体来说，这个委托通常是一个多播委托（Multicast Delegate），它上面有一个方法列表，包含了所有注册的事件处理器。

另一种方式是直接通过反射获取特定的方法，然后借助 Delegate 创造这个方法的委托实例，再从事件中移除：

1
2
3
4


var methodInfo = typeof(Demo).GetMethod("MyEventHandler", BindingFlags.Instance | BindingFlags.NonPublic);
var eventInfo = typeof(Demo).GetEvent("MyEvent", BindingFlags.Instance | BindingFlags.Public);
var handlerDelegate = Delegate.CreateDelegate(eventInfo.EventHandlerType, demo, methodInfo!);
eventInfo.RemoveEventHandler(demo, handlerDelegate);

通过以上方法，我们就可以在类外成功地移除类的事件订阅了。

整理为通用方法

最后，结合上面的方法，我们可以得到两个通用的方法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


static void ClearEventHandler(object obj, string eventName, string handlerName)
{
 Type? type = obj.GetType();
 FieldInfo? eventField = null;
 while (type != null)
 {
 eventField = type.GetField(eventName, BindingFlags.Instance | BindingFlags.NonPublic);
 if (eventField != null) break;
 type = type.BaseType;
 }
 if (eventField is null)
 throw new InvalidOperationException($"Event field '{eventName}' not found.");
 var eventDelegate = eventField.GetValue(obj) as MulticastDelegate;
 if (eventDelegate != null)
 {
 foreach (var handler in eventDelegate.GetInvocationList())
 {
 if (handler.Method.Name == handlerName)
 eventDelegate = (MulticastDelegate?)Delegate.Remove(eventDelegate, handler);
 }
 }
 eventField.SetValue(obj, eventDelegate);
}

static void ClearAllEventHandlers(object obj, string eventName)
{
 Type? type = obj.GetType();
 FieldInfo? eventField = null;
 while (type != null)
 {
 eventField = type.GetField(eventName, BindingFlags.Instance | BindingFlags.NonPublic);
 if (eventField != null) break;
 type = type.BaseType;
 }
 if (eventField != null)
 {
 eventField.SetValue(obj, null);
 }
}

这两个方法分别用于移除特定的事件处理方法和移除所有的事件订阅。并且它们都能处理事件声明在任意基类上的情况。

逆向思考 .NET 一些版本的新特性

Tue, 03 Jun 2025 00:00:00 +0000

.NET 作为一个近年来更新频率稳定的平台，每个版本都会引入一些新的特性和改进。这些新特性往往是为了提高开发效率、增强性能或改善用户体验。然而，很多时候我们可能会对某些新特性的引入感到疑惑，甚至认为它们并不是那么必要。

在这篇文章中，我想借助几个例子来分享我的思考，并给大家提供一个有意思的视角：逆向思考 .NET 新特性背后的逻辑和思考方式。

匿名类型、lambda 表达式和扩展方法

在 C# 3 中，.NET 引入了匿名类型、lambda 表达式和扩展方法等特性。我们先来简单回顾一下这些特性都是什么。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


// 匿名类型
var mapped = people.Select(p => new { p.Name, p.Age });
// Lambda 表达式
var filtered = people.Where(p => p.Age > 18);
// 扩展方法
public static class StringExtensions
{
 public static IEnumerable<T> Where<T>(this IEnumerable<T> source, Func<T, bool> predicate)
 {
 foreach (var item in source)
 {
 if (predicate(item))
 {
 yield return item;
 }
 }
 }
}

相信大家看了上面我“别有用心”的实例之后，一定不难发现：这些新特性似乎都与 LINQ 有关，而 LINQ 正是在 C# 3.0 中引入的。

因此，我们不难得出结论：这些新特性都是为了支持 LINQ 的语法而添加的。它们使得我们可以更简洁地编写查询代码，提升了代码的可读性和可维护性。

当然了，这三个特性绝不仅仅是为了支持 LINQ 而存在的。它们在其他场景下也有着广泛的应用。例如，匿名类型可以用于快速创建临时数据结构，lambda 表达式可以用于方便地声明事件处理和回调，而扩展方法则可以让我们为现有类型添加新的功能。它们都是相当强大的功能。

丢弃运算符

我们再来看一个例子。C# 7 引入了丢弃运算符（_），它可以用于忽略不需要的值。这看起来似乎是一个小特性，但如果我们再去看这个版本引入的其他几个特性，就不难发现它们之间的关系了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


// C# 7.0-
int value;
if (int.TryParse(input, out value))
{
 // ...
}

Tuple<int, string> GetResults() { }
var results = GetResults();
var value = results.Item1; // 忽略 Item2

// C# 7.0+
if (int.TryParse(input, out var _))
{
 // ...
}

(int, string) GetResults() { }
var (value, _) = GetResults(); // 使用元组解构

不难发现，C# 7 还引入了新的 out 变量声明和元组解构语法。而在这些语法中，丢弃运算符都可以起到便捷的作用。因此，我们可以说，这几个新的特性是密不可分的，所以它们也得以在这个版本中同时出现。

`init` 访问器与记录类

C# 9 引入了 init 访问器和记录类（record class）。记录类为我们提供了相当便捷的声明不可变数据类型的方式，并且重写了 Equals、GetHashCode 和 ToString 等方法，来提供更好的语义。

默认情况下，一个记录类中的属性都是只读的，即：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


public record Person(string Name, int Age);

// 相当于
public class Person
{
 public string Name { get; init; }
 public int Age { get; init; }

 public override bool Equals(object? obj) { /* ... */ }
 public override int GetHashCode() { /* ... */ }
 public override string ToString() { /* ... */ }
}

因此，init 访问器与记录类一起出现是很自然的。它们共同提供了一种声明不可变数据类型的方式，使得我们可以更方便地创建和使用不可变对象。

顶级语句与隐式引入

C# 9 引入了顶级语句，而 C# 10 引入了隐式引入。这样我们既不用再写 Program 及 Main 方法，也不用再写很多常见的 using 语句了。然后，在那段时间，我们还得到了什么呢？我们得到了 ASP.NET Core Minimal APIs。

1
2
3
4


var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/", () => "Hello World!");
app.Run();

这些代码就很大程度上借助了顶级语句和隐式引入的特性。它们使得我们可以更简洁地编写 ASP.NET Core 应用程序。C# 用这层简洁的伪装，让更多的人认为用它开发 Web 应用程序是件很简单的事情（笑）。

另外，从此，C# 也可以用 1 行代码实现 Hello World 了。

1

Console.WriteLine("Hello World!");

接口的抽象静态成员

在以前的 C# 版本中，接口只能包含方法、属性、事件和索引器等成员，而不能包含静态成员。相信这是绝大多数 .NET 开发者的共识，也是绝大多数开发者在入门时的认知，以及在其他编程语言中的经验。

然而，在 C# 11 中，我们可以在接口中声明抽象静态成员了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


public interface IShape
{
 double Area { get; }
 static abstract IShape Create(double size);
}

public class Circle : IShape
{
 public double Radius { get; }
 public double Area => Math.PI * Radius * Radius;

 public static Circle Create(double size) => new Circle(size);
}

这样的声明会要求实现该接口的类必须提供这个静态方法。那么这个新特性有什么用呢？

很快，我们在 C# 12 中就看到了它的应用：INumber 接口的引入。这个接口定义了数字类型的通用行为，其中就包含了不少静态的成员，比如 Parse、Zero 等等。

不难想象，如果没有这个新的接口特性，这个接口的实现肯定是做不到的。

结论

其实其他类似的例子还有很多，比如 ref struct、readonly struct 等与 Span 及 Memory 相关的特性，IAsyncEnumerable 与 Channel 等等。

通过这些例子，我们可以看到，.NET 的新特性往往是为了支持某个特定的功能或语法而引入的。它们之间有着密切的关系。有的是为了支持某个功能的实现，有的是为了优化某个语法的使用体验，有的则是为了提供更好的性能或可读性。

至于为什么有的特性并不是完全在同一个版本出现，这也是有一些原因的。其中一个原因是，.NET 的新特性往往需要经过多次迭代和完善才能最终稳定下来。有可能直到某个版本要发布时，想要添加的新特性仍然不够成熟，因此为了辅助它而诞生的特性可能会提前在该版本上线，而它所辅助的特性则会在下一个版本中引入。

希望通过这篇文章，大家能够对 .NET 的新特性有一个更深入的理解。逆向思考这些特性背后的逻辑和思考方式，可以帮助我们更好地理解它们的设计初衷和应用场景，也能让我们在使用这些特性时更加得心应手。这样的例子见得多了，可能会有一种“微软在开发某功能时引入的新特性因为太好用了，所以顺便下放给我们使用”的感觉吧😂。

是不是所有 C# 中实现了 Dispose 方法的类我们都要用完即释放？

Mon, 21 Apr 2025 00:00:00 +0000

C# 作为一个有 GC（垃圾回收）的语言，在使用托管资源时，通常不需要开发者关注资源的释放问题。但如果使用了非托管资源（常见的如文件句柄、数据库连接等），就需要手动释放资源了。为了方便管理资源，并形成一种统一的规范，C# 提供了 IDisposable 接口（后来还提供了 IAsyncDisposable 接口），开发者可以通过这个接口提供的 Dispose 方法来释放资源，还可以借助 C# 的 using 语句来简化资源的释放过程。

那么问题来了：是否所有实现了 IDisposable 接口的类都需要在用后立刻调用 Dispose 方法？答案是：不一定。

这篇文章我们就借助几个典型的例子，来看看在什么情况下可以不调用 Dispose 方法，并从底层的原理出发，给大家提供一个判断是否有必要调用 Dispose 方法的思路。

实现 IDisposable 接口但不涉及资源释放的类

首先我们看第一种情况：有些类实现了 IDisposable 接口，但并不涉及资源的释放。这时候相信有的读者就会问了：这种情况有点太强行凑数了吧？而且这难道不是在滥用 IDisposable 吗，毕竟它本来是用来释放资源的啊？

其实未必。因为 C# 的 using 关键字提供了一个非常方便的语法糖，可以让我们在使用完一个对象后，自动调用它的 Dispose 方法中的逻辑（即便它可能与资源释放无关）。这样我们就可以实现延迟执行，以及在任何情况下（包括抛异常）都能够确保会执行的逻辑了。

首先我们简单回顾一下 using 关键字在幕后做的事情。我们这里看一个简单例子：

1
2


using var fs = new FileStream("test.txt", FileMode.Open);
// 其他逻辑

上面的代码在编译后会变成下面的代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


var fs = new FileStream("test.txt", FileMode.Open);
try
{
 // 其他逻辑
}
finally
{
 if (fs != null)
 {
 ((IDisposable)fs).Dispose();
 }
}

Tip

在上面的例子中，using 关键字并没有搭配花括号进行使用。这是 C# 8.0 中新增的语法糖，可以让我们减少一层缩进。它相当于花括号涵盖了从 using 关键字到作用域的结束这个范围。

我们可以看到，using 语句在编译后会变成一个 try...finally 语句块，确保了在 try 块中的代码执行完后，无论是否出现异常，最终都会执行 finally 块中的代码。

于是我们就可以借助这个语法来实现一些延迟执行的逻辑了，尤其是类似 Go 语言中的 defer 语句。Go 语言中，defer 语句会在函数返回时执行，比如下面这个例子：

1
2
3
4


func main() {
 defer fmt.Println("defer")
 fmt.Println("hello")
}

于是我们可以仿照这个思路，在 C# 中实现一个类似的功能：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


class Defer : IDisposable
{
 private readonly Action _action;

 public Defer(Action action)
 {
 _action = action;
 }

 public void Dispose()
 {
 _action?.Invoke();
 }
}

它在构建时会传入一个 Action 委托，表示需要延迟执行的逻辑。然后我们就可以像下面这样使用它了：

1
2


using var defer = new Defer(() => Console.WriteLine("defer"));
Console.WriteLine("hello");

所以对于这样的一个类，即便它实现了 IDisposable 接口，我们也不必须在使用完后，手动调用它的 Dispose 方法。因为它的 Dispose 方法并不涉及资源的释放，而只是执行一些延迟逻辑而已。

因为基类或接口的约束而实现 IDisposable 接口的类

除了上面提到的为了借助 using 语句来实现延迟执行的逻辑外，还有一些类实现了 IDisposable 接口，但并不涉及资源的释放。

我们都知道，C# 中有一些原生的数据流，比如 FileStream、MemoryStream、GZipStream 等等。它们的基类 Stream 实现了 IDisposable 接口，并且它们根据自己的实际情况，也各自提供了具体的 Dispose 方法的实现，比如 FileStream 会关闭文件句柄，从而释放文件资源，避免文件被占用。

但这其中的 MemoryStream 就有些非同寻常了。它虽然是一个数据流，但它并不涉及资源的释放。因为它的底层数据是存储在内存中的一个字节数组（byte[]）中，而这个字节数组是一个托管资源。在它的源代码中我们可以看到：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


public class MemoryStream : Stream
{
 private byte[] _buffer; // Either allocated internally or externally.
 private readonly int _origin; // For user-provided arrays, start at this origin
 private int _position; // read/write head.
 private int _length; // Number of bytes within the memory stream
 private int _capacity; // length of usable portion of buffer for stream

 private bool _expandable; // User-provided buffers aren't expandable.
 private bool _writable; // Can user write to this stream?
 private readonly bool _exposable; // Whether the array can be returned to the user.
 private bool _isOpen; // Is this stream open or closed?

 // ...

 protected override void Dispose(bool disposing)
 {
 if (disposing)
 {
 _isOpen = false;
 _writable = false;
 _expandable = false;
 // Don't set buffer to null - allow TryGetBuffer, GetBuffer & ToArray to work.
 _lastReadTask = default;
 }
 }
}

所以对于 MemoryStream 这样的 Dispose 方法并不涉及资源释放的类型，即便我们不调用它的 Dispose 方法，也不会造成资源泄漏。当然了，这并不意味着我们就不需要甚至不应该去做这件事情，因为规范的开发习惯仍旧是可以为我们的代码带来更好的可读性和可维护性的。

在特定情况下可以不调用 Dispose 方法的类

有些类提供了 Dispose 方法，但是在某些情况下，对这一方法的调用并不是至关重要的。这里有一个典型的例子就是我们在异步编程中常见的 CancellationTokenSource（下面简称为 CTS）。

首先我们来写一个简单的代码，并观察它在运行时的内存占用：

1
2
3
4


for (int i = 0; i < 100000000; i++)
{
 var cts = new CancellationTokenSource();
}

运行后我们会发现，内存几乎没有任何变化。这是否意味着，CTS 的 Dispose 方法并不重要呢？其实并不是，但是在上面的这个用法中，调用与否确实没有太大的区别。这是怎么回事呢？

我们来观察 CTS 的 Dispose 方法的实现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


protected virtual void Dispose(bool disposing)
{
 if (disposing && !_disposed)
 {
 ITimer? timer = _timer;
 if (timer != null)
 {
 _timer = null;
 timer.Dispose();
 }

 _registrations = null;

 if (_kernelEvent != null)
 {
 ManualResetEvent? mre = Interlocked.Exchange<ManualResetEvent?>(ref _kernelEvent!, null);
 if (mre != null && _state != States.NotifyingState)
 {
 mre.Dispose();
 }
 }

 _disposed = true;
 }
}

可以发现，这里它对两个“可有可无”的对象进行了回收，分别是：

_timer：一个 ITimer 对象，表示一个定时器
_kernelEvent：一个 ManualResetEvent 对象，是一个信号量

它们分别是做什么用的呢？首先我们来看定时器。我们知道，CTS 提供了延时自动取消的功能。比如我们希望在 5 秒后自动取消，那么实现方法可以是：

1
2
3


var delay = TimeSpan.FromSeconds(5);
var cts = new CancellationTokenSource(delay);
// 或者也可以在创建后调用 CancelAfter 方法

此时，CTS 内部就会创建这个定时器，从而实现这个功能。在这一情况下，就会产生需要我们去释放的资源了。

另外一个信号量又是怎么回事呢？

我们都知道，CTS 现在常用于异步编程。它的 CancellationToken 可以传给标准库提供的 Async 结尾的方法，从而实现任务的取消。但是一些老的库函数可能并不支持 CancellationToken，这时候我们就可以借助 token 上的这个 WaitHandle 来实现任务的取消了。下面是 CTS 中关于 WaitHandle 属性的实现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


internal WaitHandle WaitHandle
{
 get
 {
 ThrowIfDisposed();

 // Return the handle if it was already allocated.
 if (_kernelEvent != null)
 {
 return _kernelEvent;
 }

 // Lazily-initialize the handle.
 var mre = new ManualResetEvent(false);
 if (Interlocked.CompareExchange(ref _kernelEvent, mre, null) != null)
 {
 mre.Dispose();
 }

 if (IsCancellationRequested)
 {
 _kernelEvent.Set();
 }

 return _kernelEvent;
 }
}

可以发现，它默认是没有值的；当我们第一次访问它时，它便会创建一个新的，并返回它。这样的操作就会产生一个需要我们去释放资源的对象。我们可以做这样的一个实验：

1
2
3
4
5


for (int i = 0; i < 100000000; i++)
{
 var cts = new CancellationTokenSource();
 var handle = cts.Token.WaitHandle;
}

Tip

WaitHandle 在 CTS 上是 internal 的，我们只能也应当在 CancellationToken 上去访问，因为通常情况下，我们传给方法的参数并不是 CTS 对象本身，而是它的 Token。

然后运行程序，就会发现内存在不断增加。只要我们调用了 CTS 的 Dispose 方法，内存便会不再上升。

所以我们可以得出结论：如果我们在使用 CTS 时，既不使用延时自动取消的功能，也不使用 WaitHandle 属性，那么我们不调用 Dispose 方法也不会造成资源的泄漏。

虽然提供了 Dispose 方法，但不应该用完立即释放的类

还有一种情况是，虽然类实现了 IDisposable 接口，但我们并不应该在用完后立即释放它。它被设计出来就是希望我们能够复用的。典型的例子就是 HttpClient。

比如下面这个错误例子：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


List<string> urls = new List<string>()
{
 "https://www.baidu.com",
 "https://www.sogou.com",
 "https://www.sohu.com",
};

foreach (var url in urls)
{
 using var client = new HttpClient();
 await client.GetAsync(url);
}

这个例子就是一个错误的用法。正确的做法应该是将 HttpClient 的声明移动到循环外部，或者还可以声明为一个静态对象等。这是为什么呢？

简单来说，HttpClient 底层会使用 HttpClientHandler 去处理涉及到连接池、Socket、TCP 连接等资源的管理。TCP 连接因为比较昂贵（比如有三次握手、四次挥手等），所以它通常会被复用。当我们使用 HttpClient 去访问一个链接时，访问结束后这个 TCP 连接并不会立即关闭，而是会被放入连接池中，等待下次的复用。

但是，如果我们在每次请求时都创建一个新的 HttpClient 对象，那么这个 TCP 连接就会占据连接池中的一个位置，还有本地端口等资源，最终可能会导致连接池或本地端口的耗尽，进而抛出 SocketException 等异常。

因为 HttpClient 是一个包装好的功能相当灵活的类，因此我们完全可以只创建一个，并且多次使用。不管我们访问的链接是否可以复用，怎么复用，保持连接状态多久，都会被它妥善处理。所以对于一个本地项目（如控制台应用、WPF 应用等），我们完全可以创建一个单例并处处使用它。

如果我们在项目中还使用了 DI 容器（比如微软官方提供的 Microsoft.Extensions.DependencyInjection），那么我们可以将 HttpClient 注册为一个单例的服务。这样我们就可以在整个项目中复用它了。

1
2
3
4
5


var services = new ServiceCollection();
services.AddSingleton<HttpClient>();
var serviceProvider = services.BuildServiceProvider();

var client = serviceProvider.GetService<HttpClient>();

当然了，这个方式并不是最推荐的方式（不过对于简单的本地项目来说是可取的）。对于复杂些的项目，我们更应该考虑的方式是使用 HttpClientFactory。要使用它，我们还要引入一个包：Microsoft.Extentions.Http（控制台或 WPF 等本地程序通常需要，而 ASP.NET Core 项目会自动引入它，因此就不需要额外安装包了），然后就可以使用了：

1
2
3
4
5
6


var services = new ServiceCollection();
services.AddHttpClient();
var serviceProvider = services.BuildServiceProvider();

var factory = serviceProvider.GetService<IHttpClientFactory>();
var client = factory.CreateClient();

对于更加复杂的情况，比如我们希望为不同的服务类注入配置不同的 HttpClient（比如不同的 BaseAddress、Header、Timeout 等），我们可以使用 AddHttpClient 的“命名客户端”的方法来实现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


var services = new ServiceCollection();
services.AddHttpClient("baidu", c =>
{
 c.BaseAddress = new Uri("https://www.baidu.com");
 c.Timeout = TimeSpan.FromSeconds(30);
});
services.AddHttpClient("sogou", c =>
{
 c.BaseAddress = new Uri("https://www.sogou.com");
 c.DefaultRequestHeaders.Add("User-Agent", "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3");
});
var serviceProvider = services.BuildServiceProvider();

var factory = serviceProvider.GetService<IHttpClientFactory>();
var baiduClient = factory.CreateClient("baidu");
var sogouClient = factory.CreateClient("sogou");

这样我们就可以为不同的服务类注入不同的 HttpClient 了。关于 HttpClientFactory 的更多用法，可以参考官方的教程。

总结

在这篇文章中，我们讨论了在 C# 中是否需要总是调用 Dispose 方法的问题。我们通过几个典型的例子，来看看在什么情况下可以不调用 Dispose 方法，并从底层的原理出发，给大家提供一个判断是否有必要调用 Dispose 方法的思路。

在实际的开发中，与其说我们需要分辨出哪些对象是可以不用释放的，不如说我们应当明白如何对这一操作的必要性进行正确的判断，并养成统一且规范的开发习惯。这样不管是对团队的其他开发者，还是未来的自己，都是有好处的。

为什么我们一般不使用公共字段，而是选择自动属性？

Thu, 13 Jun 2024 00:00:00 +0000

本文有对应的视频教程：哔哩哔哩

在写 C# 代码的时候，我们经常会写诸如此类的自动属性：

1
2
3
4


public Person
{
 public int Age { get; set; }
}

这时候相信很多人都会有疑问：为什么我们要费劲写成这样的自动属性？为什么不能直接简单地把它写成一个公共字段呢？就比如这样：

1
2
3
4


public Person
{
 public int Age;
}

其实这是有一些原因的。我们这次就来探讨一下。

看待属性与字段的方式不同

首先最重要的，就是我们看待属性与字段的方式，或者对于它们所扮演的角色的理解是不一样的。

当我们看到一个属性时，通常我们都会期望它拥有一个公共的读权限，同时拥有一个可能不公开的写权限还可能在初始化上存在一些限制。通常我们写一个属性时，都是希望它存在被外界访问的价值，并且我们也充分考虑了后果（比如我们可以在 setter 中添加逻辑，或干脆不开放 setter）。

也就是说，通常情况下我们希望一个属性它是一个：

（一般情况下）可以在类外被访问到，并且具有一定的意义，是开发者故意暴露出来的成员
它的初始化可能包含一些逻辑，比如可以在什么时候被初始化，是否必须被初始化，初始化后还能否更改等
它后台未必一定对应一个字段，而是会通过一些方式来得到它的值

Info

对于第 3 条，我可以举出一些例子：

List.Count 实际与底层的 Array 的长度有关
AsyncRelayCommand.IsRunning 与底层的 Task 的状态有关
ObservableValidator.HasErrors 与底层用于存放错误信息的列表有关
CheckBox.IsChecked 与底层的依赖属性有关

但是当我们看到字段时，通常会怎么考虑呢？我们先来看一段简单的代码：

1
2
3
4
5
6
7


class Manager
{
 private readonly int _uniqueId; // 一个可能有特殊作用的唯一 ID
 private readonly IConfiguration _config; // 一个通过依赖注入的方式在构造中初始化的接口对象
 private bool _flag = false; // 一个只用于内部方法间传递状态的标志位
 private readonly object _syncRoot = new(); // 一个只用于类内部的线程锁
}

大家对于字段的印象是否一般都是这样的呢？如果是的话，那么相信在看到下面的代码时，一定会有点恍惚和不知所措吧：

1
2
3
4
5
6


class Manager
{
 protected readonly int UniqueId;
 public bool Flag = false;
 public string ErrorMessage = "Oops!";
}

所以这里面的道理相信大家应该已经有一定感觉了。是的，我们通常对于字段所扮演角色的理解是：

它通常只用于类内，作为其他属性或方法的辅助角色（比如线程锁、标志位、依赖注入的对象等）
它通常不包含太多的逻辑，只是一个简单的值，而且也不如属性那样具有多种初始化的方式
它通常不太“安全”，或者说开发者在不了解的情况下不太敢轻易去操作它

基于这样不同的看待方式，相信大家应该都能理解为什么我们一般不直接使用公共字段了。

当然了，例外情况肯定也是有的。比如说我们在开发一个简单的 Unity 游戏，那么通常我们会写出这样的代码：

1
2
3
4
5
6
7


public class Player : MonoBehaviour
{
 [SerializeField]
 private int health; // Unity 官方推荐的命名习惯是首字母小写
 public int attack;
 public int defense;
}

或者当我们想要与 C/C++ 写的 DLL 交互时，我们可能会写出这样的代码：

1
2
3
4
5
6
7


[StructLayout(LayoutKind.Sequential)]
public struct MyData
{
 public ushort Index;
 public uint Value;
 public byte[] Data;
}

这些情况下，我们可能会直接使用公共字段，而不是属性。

长期的约定俗成

既然我们有这样不同的看待方式，所以就出现了相当多类似的开发习惯，甚至连标准库及第三方库也在有意无意贯彻着这样的习惯。

Info

当然了，这里面其实还有一个“先有鸡还是先有蛋”的问题。也就是说，我们是因为有了这样的习惯，所以才会有这样的标准库设计，还是因为标准库设计的如此，所以我们才会有这样的习惯呢？不过这个问题就不在我们的讨论范围内了。

这里我可以举很多例子：

在 WPF 开发中，如果你想在 XAML 中绑定一个类（通常为 Model 或 ViewModel）的变量，那么这个变量必须是一个属性，而不能是一个字段。此外，WPF 中另一个相当重要的功能——依赖属性——也会充分和属性打交道。
在进行类的序列化与反序列化时，Json.NET、System.Text.Json 等库默认只会序列化属性，而不会序列化字段。
DataGrid、PropertyGrid 等会根据数据类型来自动生成界面的控件都是关注属性而非字段。
在 EntityFramework Core 中，如果你想要使用代码优先（Code-First）的方式，那么你的实体类中的属性必须是属性，而不能是字段；而使用数据库优先（Database-First）的方式时，工具自动生成的也是属性。
C# 的接口可以包含属性，但不能包含字段。
C# 的记录类（record）底层也是使用属性来实现的。

其他还有一些别的例子，比如我们在使用数据映射的工具（如 Mapster、AutoMapper 等）时，可能也会发现属性和字段的一些不同之处。

所以，既然这样的习惯广泛存在，我们为什么要选择做一个另类的开发者呢？

灵活性与封装性

属性具有无与伦比的灵活性。我们可以在属性的 getter 和 setter 中添加任意的逻辑，比如数据校验：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


public class Person
{
 private int _age;

 public int Age
 {
 get => _age;
 set
 {
 if (value < 0)
 {
 throw new ArgumentOutOfRangeException(nameof(value), "Age must be greater than 0.");
 }

 _age = value;
 }
 }
}

再比如通知功能：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


class ViewModel : INotifyPropertyChanged
{
 private string _name;

 public string Name
 {
 get => _name;
 set
 {
 if (_name != value)
 {
 _name = value;
 OnPropertyChanged(nameof(Name)); // 事件与方法的实现略
 }
 }
 }
}

但更重要的是它的封装性。比如常见的 setter 就有这么几种：

public：公共的 setter，任何人都可以修改这个属性
protected：受保护的 setter，只有继承这个类的子类才能修改这个属性
private：私有的 setter，只有这个类内部的方法才能修改这个属性
internal：内部的 setter，只有同一个程序集内的方法才能修改这个属性
init：初始化 setter，只能在构造函数中初始化这个属性
空：只读属性，只能在构造函数中初始化这个属性

不仅如此，还可以配合诸如 required、virtual 等关键字，使得属性的灵活性和封装性更上一层楼。这些都是字段完全无法比拟的（我知道上面的一些关键字也可以用于字段，但效果都很有限，比如会同时限制读写的权限等）。

性能方面的考虑

这时候可能有同学又要说了：我知道自动属性其实是个语法糖，最终还是会被编译器转换成字段和方法，形如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


class Person
{
 [CompilerGenerated]
 private int <Age>k__BackingField;

 public int Age
 {
 [CompilerGenerated]
 get
 {
 return <Age>k__BackingField;
 }
 [CompilerGenerated]
 set
 {
 <Age>k__BackingField = value;
 }
 }
}

那么调用方法去读写字段的值，效率上理应比直接读写字段要低对吧？如果是这样的话，把 { get; set; } 这样的自动属性直接写成公共字段，不是更好吗？

这是个好问题，我们来看这样一个例子。下面的 Person 类中，我们定义了两个属性，一个是自动属性，一个是字段：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


var p = new Person();

p.Age1 = 10;
p.Age2 = 20;

public class Person
{
 public int Age1 { get; set; }
 public int Age2; 
}

如果我们观察 IL 代码，会发现：

1
2
3
4
5
6
7


IL_0000: newobj instance void Person::.ctor()
IL_0005: dup
IL_0006: ldc.i4.s 10
IL_0008: callvirt instance void Person::set_Age1(int32)
IL_000d: ldc.i4.s 20
IL_000f: stfld int32 Person::Age2
IL_0014: ret

好像确实不大对劲啊。Age1 就是使用了 Person::set_Age1 方法，而 Age2 却直接使用了 stfld 指令。那是不是说明修改属性的速度就是会略微慢于直接修改字段呢？先别急，我们再来看一看 JIT 编译后的代码：

1
2
3
4
5
6


Program.<Main>$(System.String[])
 L0000: mov ecx, 0x33a4ca1c
 L0005: call 0x066f300c
 L000a: mov dword ptr [eax+4], 0xa
 L0011: mov dword ptr [eax+8], 0x14
 L0018: ret

这里我们可以看到，自动属性的 setter 其实会被 JIT 编译器优化成直接的内存写入操作。这就意味着，实际上在运行时，修改属性和直接修改字段的速度是一样的。所以，自动属性的性能和公共字段是完全一样的。大家大可以打消这个顾虑了。

.NET 9 即将到来的新语法特性

如果你还在犹豫的话，我还可以再告诉你一个好消息：.NET 9（C# 13）即将引入一个新语法特性：field 关键字（这个关键字曾经在 C# 11 的时候就释放过信号，但因为一些原因姗姗来迟）。这个新特性可以让你更加方便地声明一个属性。

我们都知道，以前我们写完整属性（propfull）时，需要写成这样：

1
2
3
4
5
6
7


private int _age;

public int Age
{
 get => _age / 2;
 set => _age = value * 2;
}

但是现在，有了 field 关键字，我们可以这样写：

1
2
3
4
5


public int Age
{
 get => field / 2;
 set => field = value * 2;
}

这里的 field 就相当于那个 _age 字段。这样一来，我们就可以更加方便地声明一个属性了。

总结

通过上面的讨论，相信大家对于为什么我们一般不使用公共字段，而是选择自动属性有了更深的理解。当然了，这并不是说我们就不能使用公共字段了。在一些特殊的场景下，我们还是可以使用公共字段的。但是在大多数情况下，我们还是应该选择自动属性。

C# 后面不断新增的语法特性，一直在优化我们使用属性的体验。在比较旧的 C# 版本中，我们甚至不能给自动属性直接赋值，而是需要通过构造函数来初始化。但是随着 C# 版本的不断更新，我们可以看到，自动属性的使用变得越来越方便了。除了上面提到的即将到来地 field 关键字，我们在 C# 9 还迎来了记录类型，在 C# 12 又迎来了主构造函数。这些都是为了让我们更加方便地使用属性。

相信大家今后可以更加无忧无虑地使用属性。

如何在 C# 中模拟 Go 的 defer 关键字并用于客户端开发

Tue, 28 May 2024 00:00:00 +0000

本文有对应的视频教程：哔哩哔哩

Go 中的 defer 大概是怎么一回事

Go 语言中有一个非常好用的 defer 关键字。defer 会在函数返回之前执行，可以用来释放资源，关闭文件等。比如我们想打开并读取一个外部文件的内容，我们可以这样写：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


func ReadFile() {
 file, err := os.Open("file.txt")

 // 如果打开文件失败，直接返回
 if err != nil {
 log.Fatal(err)
 }

 // 在函数返回之前关闭文件
 defer file.Close()

 // 读取文件内容
 content := make([]byte, 1024)
 file.Read(content)
 fmt.Println(string(content))
}

在这个例子中，我们使用 defer 关键字来确保在函数返回之前关闭文件。这样我们就不用担心忘记关闭文件，导致资源泄漏。

其实在 C# 和 Python 中，我们也可以借助一些特殊的语法来实现类似的效果。比如在 C# 中，我们可以使用 using 关键字来确保资源在使用完之后被释放；在 Python 中，我们可以使用 with 关键字来确保资源在使用完之后被释放。

但有些时候，我们想要实现的功能只是希望在离开作用域之前执行一些代码，而不是释放资源。这种情况下，我们仍然可以借助 using 关键字来实现，可以为我们带来意想不到的便利。

在 C# 中模拟 Go 的 defer

前面已经提到，我们需要在 C# 中使用 using 关键字来模拟 Go 的 defer。但是 using 关键字只能用于“释放资源”，或者说需要对一个实现了 IDisposable 接口的对象进行操作。那么我们就必须实现 Dispose 相关的逻辑了。话虽如此，并没有人规定我们必须在 Dispose 方法中执行释放资源的逻辑。比如我们前面提到的，希望在离开作用域之前执行一些代码，就可以放在 Dispose 方法中去执行。

基于这个思路，我们可以写出这样的代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


public class MyDisposable : IDisposable
{
 private readonly Action _callback;

 public MyDisposable(Action callback)
 {
 _this._callback = callback;
 }

 public void Dispose() => _callback();
}

这样我们就可以在 Dispose 方法中执行我们想要执行的代码了。比如我们可以这样使用：

1
2
3
4
5
6


void Foo()
{
 using var md = new MyDisposable(() => Console.WriteLine("Job is done."));

 // Do something
}

我们在上面的例子中还用到了 C# 8.0 的新特性：using 语法的改进。在 C# 8.0 中，我们可以省略 using 语句中的大括号，直接在 using 语句后面写一个表达式。这样我们就可以更加简洁地使用 using 语法了。

它实际对应的底层 C# 代码是这样的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


void Foo()
{
 MyDisposable md = new MyDisposable(() => Console.WriteLine("Job is done."));
 try
 {
 // Do something
 }
 finally
 {
 if (md != null)
 {
 md.Dispose();
 }
 }
}

所以可以保证 finally 语句中的代码一定会被执行，即使在 try 语句中抛出了异常。

这一技巧在 WPF 开发中的妙用

其实这个小妙招并不是我的原创，而是油管上的 Jason Williams 在他的一期视频中提到的。在他的视频中，他为我们提供了一个绝妙的点子。

我们在做 WPF（以及其他诸如 Win UI、Avalonia 等）的客户端开发时，经常会遇到一个问题，就是需要去管理一个进度条的可见状态。比如我们现在有一个异步任务，我们希望任务在执行期间能够显示一个进度条，任务执行完毕（不管成功与否）后进度条消失。通常我们的做法是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


// 模拟搜索电影的异步任务
public bool IsBusy { get; set; } = false; // 控制进度条是否可见，且该属性具备通知功能

async Task SearchMovieAsync(string movieName)
{
 IsBusy = true;

 if (!CanSearch())
 {
 IsBusy = false;
 return;
 }

 var resList = await SearchMoviesFromInternetAsync(movieName);
 if (resList == null || resList.Count == 0)
 {
 IsBusy = false;
 return;
 }

 foreach (var res in resList)
 {
 // Do something
 }

 IsBusy = false;
}

可以看到，我们在方法中需要多次根据情况设置 IsBusy 属性。这样的代码看起来不太优雅。为了解决这个问题，我们就可以用上前面实现的类了。不过我们需要稍微修改一下，使它的回调函数可以接受一个参数：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


public class BusyDisposable : IDisposable
{
 private readonly Action<bool> _busySetter;

 public BusyDisposable(Action<bool> busySetter)
 {
 _busySetter = busySetter;
 _busySetter(true);
 }

 public void Dispose() => _busySetter(false);
}

然后我们就可以这样使用了：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


async Task SearchMovieAsync(string movieName)
{
 using var _ = new BusyDisposable(value => IsBusy = value);

 if (!CanSearch())
 {
 return;
 }

 var resList = await SearchMoviesFromInternetAsync(movieName);
 if (resList == null || resList.Count == 0)
 {
 return;
 }

 foreach (var res in resList)
 {
 // Do something
 }
}

Info

这里有一个需要注意的点：我们是在 ViewModel 中对 IsBusy 进行的操作，并借助绑定来控制前台进度条的显示。这无形中帮助我们解决了一个重要的隐患：线程安全。即便我们在非 UI 线程中修改了 IsBusy 属性，由于 WPF 的数据绑定机制，我们也不用担心线程安全问题。

但如果是在 View 中去直接操作进度条的 Visibility 属性，那么就可能需要我们自己去处理线程安全问题了。常见的方式比如使用 Dispatcher，或参考我的这篇关于使用 IProgress 的文章。

相信大家立刻就能够明白这个方式有多么简洁和优雅了。我们通过使用 using 关键字，保证了当前作用域中的代码不管是正常执行还是异常退出，都会在离开作用域之前执行 IsBusy = false 这一行代码。这样我们就不用在方法中多次设置 IsBusy 属性了。

甚至我们还能再稍微优化一下，比如使用一个自动属性来简化 BusyDisposable 的实例化：

1
2
3
4
5
6
7
8
9


private BusyDisposable NewBusyDisposable 
 => new BusyDisposable(value => IsBusy = value);

async Task SearchMovieAsync(string movieName)
{
 using var _ = NewBusyDisposable;

 // ...
}

这样我们就可以进一步简化这一语法，从而使其更接近 Go 语言中的 defer 关键字的使用方式。

总结

本期内容主要介绍了 Go 语言中的 defer 关键字，以及如何在 C# 中模拟 defer 的实现。虽然我们似乎一定程度上“滥用”了 using 关键字以及 IDisposable 接口，但这种方式确实可以带来一些意想不到的便利。

油管上的这位 Jason Williams 也绝对是一位大神。虽然他视频非常少，粉丝也只有几百，但是每期内容都堪称精品。大家有机会的话也可以去关注一下他，相信一定会有所收获。

C# 鸭子类型汇总

Thu, 04 Apr 2024 00:00:00 +0000

什么是“鸭子类型”？

鸭子类型的名字来源于一句俚语：

如果它走起来像鸭子，叫起来像鸭子，那么它就是鸭子。

这句话的意思是，如果一个对象具有某个方法或属性，那么它就可以被当作拥有这个方法或属性的类型来使用，而不需要严格地遵循一些规定与要求。

在 C# 中，通常我们会认为，如果想要使用一些语法，需要实现一些接口。比如你很可能会觉得：

如果想要使用 foreach 语句，需要实现 IEnumerable 接口
如果想要使用 await 语句，需要与 Task 类或一些底层接口扯上关系
如果想要使用 using 语句释放资源，需要实现 IDisposable 接口

实际上真的如此吗？这篇文章我们就来总结一下 C# 中的那些不为人知的鸭子类型。

C# 中的鸭子类型

`foreach` 语句

C# 标准库为我们提供了大量的集合类型，比如 List、Stack、Queue、ObservableCollection 等等。这些集合类型都实现了 IEnumerable 接口，所以我们可以使用 foreach 语法来遍历它们。

但实际上，foreach 语法并不要求类必须实现 IEnumerable 接口。只要类中有一个名为 GetEnumerator 的方法，返回一个 IEnumerator 类型的对象，就可以使用 foreach 语法。比如下面这个例子：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


var c = new MyEnumerableClass();
foreach (var item in c)
{
 Console.WriteLine(item);
}

class MyEnumerableClass
{
 private int[] items = new[] { 1, 2, 3 };

 public IEnumerator GetEnumerator()
 {
 return items.GetEnumerator();
 }
}

我们还可以玩一些“花活”。事实上，这个 GetEnumerator 方法其实都不需要直接出自这个类型，甚至可以是一个扩展方法。所以，我们可以对一些我们无法修改的类添加扩展方法，从而使它们变得可以被 foreach 语法遍历。比如 C# 8.0 引入了 Range 与 Index 两个类型，表示数组的范围与索引。

Info

通常我们不会直接声明一个 Range 对象，而是会使用形如 array[1..5] 这样的语法来表示一个范围。在底层，这个 1..5 会被转换为一个 Range 对象。

你甚至可以不在数组的索引器中使用这个语法，而是直接声明一个变量并这样进行赋值：

1
2


var range = 1..5;
Console.WriteLine(range.GetType().Name); // Range

我们可以为 Range 类型添加一个扩展方法，使得它们可以被 foreach 语法遍历：

1
2
3
4
5
6
7
8


static class MyExtensions
{
 public static IEnumerator<int> GetEnumerator(this Range range)
 {
 for (int i = range.Start.Value; i <= range.End.Value; i++)
 yield return i;
 }
}

然后就可以这样玩了：

1
2
3
4
5
6
7
8
9


foreach (var i in 1..3) // 1..3 是一个 Range 类型
{
 Console.WriteLine(i);
}

// 输出：
// 1
// 2
// 3

`await` 语句

类似地，await 语法也不要求类必须继承 Task 类或实现一些底层接口。只要类中有一个名为 GetAwaiter 的方法，返回一个 IAwaiter 类型的对象，就可以使用 await 语法。并且与上面 foreach 的例子相同，我们也可以把 GetAwaiter 方法定义为一个扩展方法，从而“扩展”一些我们无法修改的类。

1
2
3
4
5


static class Extensions
{
 public static TaskAwaiter GetAwaiter(this TimeSpan ts) => Task.Delay(ts).GetAwaiter();
 public static TaskAwaiter GetAwaiter(this double sec) => Task.Delay(TimeSpan.FromSeconds(sec)).GetAwaiter();
}

上面的静态类中声明了两个扩展方法，分别为 TimeSpan 与 double 类型添加了 GetAwaiter 方法。然后我们就可以这样使用 await 语法了：

1
2


await TimeSpan.FromSeconds(1);
await 1.0;

是不是感觉越来越离谱了？不过实际开发中，轻易还是不要使用这样的技巧，因为这会严重污染常用的类型，可以说是有百害而无一利。

`using` 语句

如果你认为 using 语句只能用于实现了 IDisposable 接口的类，那你终于基本上对了一次😂。的确，对于一个 class 类型的对象，如果它没有实现 IDisposable 接口，那么即便它拥有 public void Dispose() 方法，它仍然是无法使用 using 语句的（编译器会提示，这个对象必须可以隐式转换为 IDisposable 对象）。

但是！

C# 中还有一个不太常用的 ref struct 类型。这种类型的对象在离开作用域时会自动被销毁，所以它们不需要实现 IDisposable 接口。即便如此，我们可以为这种类型的对象添加一个 Dispose 方法，这样我们就可以使用 using 语句来释放资源了。

1
2
3
4
5
6
7
8
9


ref struct MyDisposableStructType
{
 public void Dispose()
 {
 Console.WriteLine("MyDisposableStructType Disposed.");
 }
}

using var s = new MyDisposableStructType();

这样的话，我们就可以对一个没有实现 IDisposable 接口的对象使用 using 语句了。

集合初始化器

C# 中的很多集合类型都支持集合初始化器语法 { } 来初始化集合对象。比如 List 类型可以这样初始化：

1

var list = new List<int> { 1, 2, 3 };

实际上，只要类实现了 IEnumerable 接口，并且包含一个名为 Add 的方法，那么这个类就可以使用集合初始化器语法。比如下面这个例子：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


class PlanetCollection<T> : IEnumerable
{
 public T[] Planets { get; init; }

 private int _index = 0;

 public PlanetCollection(int count)
 {
 Planets = new T[count];
 }

 public void Add(T item)
 {
 if (_index >= Planets.Length)
 throw new IndexOutOfRangeException();
 Planets[_index++] = item;
 }

 public IEnumerator GetEnumerator() => Planets.GetEnumerator();
}

然后我们就可以这样初始化：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


var collection = new PlanetCollection<string>(8)
{
 "mercury", "venus", "earth", "mars", "jupiter", "saturn", "uranus", "neptune"
};

// 会被编译为：
PlanetCollection<string> source = new PlanetCollection<string>(8);
source.Add("mercury");
source.Add("venus");
source.Add("earth");
source.Add("mars");
source.Add("jupiter");
source.Add("saturn");
source.Add("uranus");
source.Add("neptune");

元组拆分

C# 在引入了元组后，也引入了元组拆分语法。比如我们可以这样写：

1
2


var (a, b) = (1, 2);
(int c, int d) = (3, 4);

很多原生的类型也支持元组拆分。比如：

1
2
3
4
5


var pair = new KeyValuePair<string, int>("key", 42);
var (key, value) = pair;

var dt = DateTime.Now;
var (year, month, day) = dt;

此外，如果我们声明一个 record 类型，那么底层也会为我们提供元组拆分的功能。

实际上，元组拆分的语法是通过 Deconstruct 方法实现的。只要类中有一个名为 Deconstruct 的方法，并且用 out 的方式进行传参，那么这个类就可以使用元组拆分语法。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


class Point2d
{
 public int X { get; set; }
 public int Y { get; set; }
 public void Deconstruct(out int x, out int y)
 {
 x = X;
 y = Y;
 }
}

var point = new Point2d { X = 1, Y = 2 };
var (x, y) = point;

LINQ 的 `SelectMany` 方法

最后再说一个比较冷门且不常用的，就是 LINQ 中的 SelectMany 方法，以及多层 from 语句。比如我们现在有一个“数组的数组”一样的结构，例如：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


class Person
{
 public string Name { get; set; }
 public List<Pet> Pets { get; set; }
}

class Pet
{
 public string Name { get; set; }
}

我们可以使用 SelectMany 方法来展开这个结构：

1
2
3
4
5
6
7


var people = GetPeople();
// 使用查询表达式
var pets = (from person in people
 from pet in person.Pets
 select pet).ToList();
// 或者链式表达式
var pets = people.SelectMany(p => p.Pets).ToList();

实际上，只要我们为类提供正确的 SelectMany 方法，那么我们就可以使用多层 from 语句来展开这个结构。比如我们可以为上面集合初始化器中的 PlanetCollection 类型提供一个 SelectMany 方法，从而展开这个结构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


static class Extensions
{
 public static IEnumerable<TResult> SelectMany<TSource, TCollection, TResult>(
 this PlanetCollection<TSource> source,
 Func<TSource, IEnumerable<TCollection>> collectionSelector,
 Func<TSource, TCollection, TResult> resultSelector
 )
 {
 foreach (var item in source.Planets)
 {
 foreach (var subItem in collectionSelector(item))
 {
 yield return resultSelector(item, subItem);
 }
 }
 }
}

var query = 
 from planet in collection 
 from letter in planet 
 select letter;

Console.WriteLine(new string(query.ToArray()).ToUpper());

这个 SelectMany 方法的要求相对比较复杂，这里我们就不展开讨论了。

总结

看了这篇文章之后，相信大家会对 C# 这门编程语言有一个更新的认识了吧？

事实上，上面提到的大多数鸭子类型，都是与底层 C# 代码密不可分的。这里我给大家提供一个探索的方向，比如可以借助 SharpLab 这样的工具，查看诸如 foreach 语句、await 语句、以及集合初始化器等语法对应的底层 C# 代码。相信大家一定会有所收获。

C# on 寒流の编程笔记

在 C# 15 的 Union 类型到来之前我们都是怎么过的？

Union 类型的核心目标

枚举类型 enum

包含多个属性的类

object 类型

空的抽象基类或接口

OneOf 第三方库

缺乏语言级别的语法糖

代码繁杂

缺乏领域签名

泛型参数顺序泄露到 API 设计里

Union 类型的到来

底层原理

总结

如何在类外移除类的事件订阅？

简单情况

事件声明在基类上

移除特定的事件处理方法

整理为通用方法

逆向思考 .NET 一些版本的新特性

匿名类型、lambda 表达式和扩展方法

丢弃运算符

init 访问器与记录类

顶级语句与隐式引入

接口的抽象静态成员

结论

是不是所有 C# 中实现了 Dispose 方法的类我们都要用完即释放？

实现 IDisposable 接口但不涉及资源释放的类

因为基类或接口的约束而实现 IDisposable 接口的类

在特定情况下可以不调用 Dispose 方法的类

虽然提供了 Dispose 方法，但不应该用完立即释放的类

总结

为什么我们一般不使用公共字段，而是选择自动属性？

看待属性与字段的方式不同

长期的约定俗成

灵活性与封装性

性能方面的考虑

.NET 9 即将到来的新语法特性

总结

如何在 C# 中模拟 Go 的 defer 关键字并用于客户端开发

Go 中的 defer 大概是怎么一回事

在 C# 中模拟 Go 的 defer

这一技巧在 WPF 开发中的妙用

总结

C# 鸭子类型汇总

什么是“鸭子类型”？

C# 中的鸭子类型

foreach 语句

await 语句

using 语句

集合初始化器

元组拆分

LINQ 的 SelectMany 方法

总结

`init` 访问器与记录类

`foreach` 语句

`await` 语句

`using` 语句

LINQ 的 `SelectMany` 方法