用 .NET 写系统级 DLL 一直不是件容易的事：要么借助 COM 接口，要么靠 wwDotnetBridge 这类宿主库来帮你"搭桥"。直到 Native AOT 成熟，才出现了另一条路——把 C# 代码直接编译成原生 Windows DLL，调用方只需遵循标准 WinAPI（StdCall）约定，根本不需要知道背后跑的是 .NET。

电商管理后台里，用户 A 把商品价格从 ¥299 改成 ¥349，用户 B 同时把库存从 100 调成 80。两人几乎同时点击"保存"——没有并发控制的话，后写入的那方会默默覆盖掉另一个人的改动，什么提示也没有，直到客户下单才发现数据出了问题。

这就是

做 EF Core 一段时间后，很多人都会遇到同一个节点：常规 LINQ 能覆盖大多数查询，但一到复杂报表、视图或者历史 SQL 复用场景，就会开始考虑原生 SQL。问题不在于“能不能写 SQL”，而在于怎么写得可维护、可观测、还能和 EF Core 的映射体系配合好。这篇文章讲解 

在本地开发时，

当一个 ASP.NET Core 服务在高负载下开始出问题，"每秒请求数（RPS）"这个指标几乎告诉不了你任何原因。RPS 是结果，真正的原因要具体得多：某个线程被卡住了、某个 Socket 没有被复用、某个队列没有上界。