dotnet通关秘籍

Task 是异步操作的结果载体，async/await 是操作这个载体的语言级语法糖，而真正决定是否占线程、怎么调度、何时恢复执行的，是底层操作类型、上下文和运行时调度机制。

IValueTaskSource 是 ValueTask 异步路径上的低层承载接口，核心价值是让异步操作的状态对象可以复用，从而减少甚至避免额外分配。

ObjectPool 这类工具，真正值钱的地方不是“把所有对象都放进池里”，而是： 对某些创建成本不算低、使用频率高、生命周期短、又能安全复用的对象，减少重复分配和回收的成本。

Mapperly 是一个基于 Source Generator 的对象映射库，它把映射代码放到编译期生成，运行时执行的仍然是普通 C# 代码。

简介 很多人第一次认真看 IL，通常不是因为“想学一门汇编”，而是因为碰到了这些问题： 同一段 C#，编译之后到底变成了什么 async/await、yield、lock 这些语法糖到底被编译成了什么

简介 在 .NET 里提到同步，很多人第一反应通常是： 这没问题。 但只要你继续往下挖，很快就会碰到两个更底层的名字： 它们都能做“互斥”，但解决的问题并不是同一类。 一句话先说透： 所以这篇文章重点

简介 很多人第一次认真看 gRPC，通常不是因为“想学一个新协议”，而是因为项目已经出现了这些信号： 服务和服务之间调用越来越多 REST 的 JSON 体积、契约漂移、字段随意扩张开始让人烦 想要更

TPL Dataflow 不是一个普通并发集合，也不是消息队列，而是一套在进程内组织异步处理管道的工具。

简介 只要你的 .NET 系统开始从单体走向微服务，很快就会遇到这个问题： 这时候你会发现，单库事务那套熟悉的心智模型开始失效了。 在单体应用里，你可以靠： SqlTransaction DbTran

简介 在 .NET 微服务里，只要你开始拆服务，很快就会遇到这几个现实问题： 服务实例越来越多，地址不固定 调用方不能再把 IP:Port 写死 某个实例挂了，调用方最好别继续打过去 配置、注册、发现

简介 在 .NET 里做并发集合选型时，只要需求里出现这几个关键词： 生产者-消费者 任务排队 消息缓冲 先来先处理 很多时候你真正要找的，其实不是 ConcurrentStack<T>，也不是 Co

简介 在 .NET 里做并发集合选型时，很多人最先想到的是： ConcurrentDictionary<TKey, TValue> ConcurrentQueue<T> ConcurrentBag<T

简介 在 .NET 里做并发控制时，最常见的默认答案通常还是： 这没有问题。 但有一类场景，普通互斥锁会显得有点“太保守”： 读很多 写很少 读操作彼此其实并不冲突 比如： 本地缓存查询 配置快照读取

简介 在 .NET 里提到线程同步，很多人的第一反应还是： 这套写法本身没有问题，而且已经用了很多年。 但从 .NET 9 和 C# 13 开始，官方开始明确给出一个更推荐的方向： 也就是说，互斥锁这

简介 在 .NET 里，只要你开始深入看并发控制，很快就会发现这样一个现象： 大多数业务代码都用 lock 异步场景更常见的是 SemaphoreSlim / AsyncLock 简单状态更新则更适合

简介 SignalR 在单节点开发环境里通常很好用。 你本地起一个应用，前端连上来，消息一发，聊天室、通知、在线状态、协作编辑似乎都没什么问题。 但很多团队一到生产环境，问题就开始冒出来了： 应用一扩

简介 只要你开始深入看 .NET 的并行调度模型，很快就会碰到一个高频词： 很多文章会告诉你： 它是“工作窃取” 每个线程有自己的队列 队列空了就去偷别人的任务 这些说法当然没错，但还远远不够。 真正

简介 Task.Run 是 .NET 里最常见、也最容易被误解的 API 之一。 很多人对它的第一印象是： “开个后台线程” “把同步代码变异步” “防止阻塞当前线程” 这些说法不能说全错，但都不够准

简介 在 .NET 里，只要你开始关注性能，尤其是这些场景： 高频字符串处理； 协议解析和编码； 临时 byte / char 缓冲区； 循环里的小数组分配； 希望减少 GC 干扰的热点代码； 你大概

简介 如果说： Span<T> 解决的是“如何高效操作一段连续内存”； Memory<T> 解决的是“如何跨异步边界持有连续内存”； ReadOnlySequence<T> 解决的是“如何处理多段逻辑