dotnet通关秘籍

简介 上一篇文章已经把 YARP 的基础反向代理、路由、负载均衡、健康检查、限流都串了一遍。 这篇继续往下走，专门讲一个网关项目里很常见的能力： 也就是说，请求进来以后，先经过网关校验 JWT，校验通

简介 YARP 全称是 Yet Another Reverse Proxy，是微软开源的 .NET 反向代理库。 一句话说清楚： 所以它和 Nginx、Envoy 这类独立代理不太一样。YARP 更像

简介 很多项目一开始做缓存，通常都是这么写的： 刚开始看起来没什么问题。 但只要项目一复杂，这套逻辑很快就会变得又长又散： 每个地方都在手写两级缓存 本地缓存和 Redis 的过期时间不好统一 并发一

简介 很多项目一提到缓存，第一反应就是： 上 Redis 存个字符串 查不到就回数据库 刚开始这样写没什么问题。 但项目一复杂，几个现实问题就会很快冒出来： 多实例部署后，本地缓存各存各的 业务代码里

简介 一提到缓存，很多项目里最先出现的通常是这几样东西： IMemoryCache IDistributedCache Redis 手写一套缓存工具类 刚开始看起来都能用。 但项目一复杂，问题就会慢慢

简介 平时写 C#，很少会主动去碰内存管理。 因为 .NET 已经把最麻烦的一层包掉了： 对象分配不用手动 malloc 对象释放不用手动 free 大部分时候只管写业务，程序也能正常跑 但只要项目一

简介 异步代码一多，参数传递很快就会开始变味。 最常见的场景是这样： 入口层拿到了 TraceId 服务层要打日志 仓储层也想拿到同一个 TraceId 调了好几层 await 以后，这个值还得一直跟

简介 很多业务系统刚开始都差不多： 一个 Service 里面既有新增、修改、删除 也有列表、详情、统计、搜索 前期这样写很顺手。 但只要项目稍微复杂一点，问题就会慢慢冒出来： 读逻辑和写逻辑揉在一起

简介 多线程代码里最麻烦的一个点，不是“怎么开线程”，而是“数据到底该不该共享”。 很多并发问题，本质上都不是线程太多，而是： 好几个线程同时改同一份数据 于是开始加锁 锁一多，性能又掉下去 这时候就

MediatR 是 .NET 里很常见的进程内消息分发库。MediatR 不是消息队列，也不是分布式事件总线，它是应用进程内部的请求分发器。

简介 在 .NET 高性能内存编程里，Span<T> 解决了一个很实际的问题： 但 Span<T> 本身还是比较“规矩”的。 比如： Span<byte> 就是按字节看； Span<int> 就是按整

TaskCompletionSource<T> 的作用，不是启动任务，而是手动控制一个 Task<T> 什么时候完成。

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

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

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

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

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

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

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

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