.net core

MQTT实战 - Topic设计12条军规：90%的消息混乱都源于命名错误（三）前年我们接手了一个医院设备维保项目，做设备接入层的重构。打开原有的Topic列表，我是懵的：五种风格，三种大小写，两个以 / 开头。更离谱的是，有的Topic用了驼峰，有的用了下划线，还有的直接把设备的位置信息编进了。

MQTT实战 - MQTT vs HTTP：为什么你的物联网项目上线就崩？（二）很多物联网团队做原型阶段，图简单直接选用HTTP做设备接入。Demo环境下三五个设备跑的非常顺畅，接口调通，数据正常上报。

中国.NET研究协会

SimdYolo：纯 C# YOLO 推理实现，CPU SIMD / Vulkan 架构与 PyTorch、ORT 实测项目仓库： https://github.com/hnlyf168/SimdYolo我实现了一个面向 .NET 应用的 YOLO 推理库 SimdYolo：C# 直接解析支持范围内的 .pt 和 ONNX，CPU 使用 SIMD/intrinsics，GPU 通过系统 Vulkan、Metal API 执行嵌入着色器。目前已验证常见 YOLOv8、YOLOv9、YOLOv10、YOLO11 的检测模型，以及 YOLOv8、YOLO11 的分割和姿态模型。

一行代码在 .NET 项目里启用 Satori GC众所周知 Satori GC 是 .NET 上兼具高吞吐、低延时和低占用的 GC。为了更方便地在项目里使用 Satori GC，我把 Satori GC 封装成了 MSBuild SDK 并传到了 nuget 上，这样就能通过仅仅一行代码在发布时启用 Satori GC 了。

CSharp精选营

我用 ASP.NET Core 做了个水稻病虫害检查系统上传一张叶片照片，AI 告诉你它得了什么病大家好，我是码农刚子。前阵子回了趟老家，正赶上水稻抽穗，发现一件挺头疼的事。

△曉風殘月〆

.NET是什么？为什么要选择.NET?自我们启动迭代迅猛的.NET 开源跨平台项目以来，.NET 发生了翻天覆地的变化。我们对整个平台进行了重新梳理与打磨，一方面新增大量面向性能与安全性的底层核心能力，另一方面配套推出侧重开发效率的高层特性，Span<T>、硬件内部函数、可空引用类型便是典型代表。

DOTNET 鉴权系列- JWT 会话撤销与主动登出写这篇的主要原因是记录一下jwt无状态特点下的主动撤销和登出的解决方案，因为之前负责做过类似的用户相关的系统，对于这一块的方案和实现比较粗糙的，登录成功后，计算完整 JWT 字符串的 Hash，将tokenHash + userId存入Redis，每次鉴权时计算请求 Token 的 Hash，去存储中比对是否存在，这套方案虽然实现了登出撤销，但把所有有效 Token 全部落地存储，JWT 只剩下签名验签的能力，几乎退化成传统 Session 模式，丢失了 JWT 无状态的设计初衷。

让 .NET 11 的泛型虚方法变得更快！.NET 中的泛型方法带有一个或多个类型参数，可以在保证类型安全的同时处理不同的数据类型。当我们希望代码针对具体类型进行特化，却又不想为每种类型重复编写一份代码时，泛型方法就很有用。

.NET CORE 授权进阶-数据操作权限实现及扩展.NET Core基于资源的授权-防止水平越权的实现这篇分享内容就是基于图中的后半部分，在功能权限验证通过后，对数据进行操作时，如何使用原生 .NET Core 的授权模块进行实现及扩展。在回顾一下授权的这个简图：

.NET 11 Runtime Async 详解.NET 自古以来就提供了 async/await 异步编程模型，这套机制允许开发者以同步方式编写异步代码，从而简化了异步编程的复杂性。

Surging AI Agent：基于.NET 生态一站式本地大模型 + 向量检索微服务解决方案在.NET 微服务领域，Surging 一直是轻量化、高性能的分布式微服务标杆框架，依托模块化 RPC、服务注册发现、负载均衡能力，广泛应用于企业业务微服务开发。但在 AI 赋能业务的落地阶段，开发者普遍面临两大割裂难题：

.NET CORE 授权进阶-角色、策略与动态权限实现前两篇我们聊过认证鉴权模块，分别介绍了 Cookie、JWT 怎么接入及扩展，并且还分析了认证在请求链路里是怎么跑起来的。那么接下来进入 .NET Core 授权（Authorization）。简单来说就是这篇分享的所有东西，都建立在用户已经登录、Claims 已经在手的前提上，不要串台了。

ASP.NET Core 认证与授权（二）：登录与令牌签发认证管道只能验证客户端带来的凭证，不能凭空产生凭证。用户第一次还没有 Token，只能先提交用户名和密码；登录接口验证成功后，才会签发 Access Token 和 Refresh Token。

ASP.NET Core 认证与授权（三）：请求认证与权限校验登录接口已经返回 Access Token。接下来客户端带着它调用订单接口：这一串字符不会自动变成当前用户。ASP.NET Core 要先选择认证方案，再由 JwtBearerHandler 验证 Token，生成 ClaimsPrincipal（用户身份对象），最后根据 Endpoint 上的授权规则决定是否执行 Controller。

.NET CORE 动态扩展Options-配置运行时热更新玩了半年最近找了新工作，，新工作也是再一次接触到Abp vNext 框架，内部系统开发也是基于这个框架的，最近领导让研究学习框架身份认证权限这一套，然后为现有系统做一些扩展和维护，在研究的过程中发现一些很有趣的设计和代码，刚好有些总结，今天分享出来。

.NET CORE认证模块-注册方案与请求认证探究上一篇我们实战了怎么用 JWT 认证和 Cookie 认证，不得不感叹这套东西设计得很巧妙——我们只要简单配几行，一整套完整的功能就能跑起来。那这一篇，我们就往下钻一层，看看框架到底是怎么实现的。我大概列了 3 个方向入手。在正式开始之前，我先说下按这几个问题去理解，会顺很多。

.NET CORE 认证模块-Cookie、JWT 与自定义 Scheme框架为我们提供了很多默认的实现，在做一些中小项目，在不涉及OIDC，不构建身份认证中心的场景下，通常选择使用Cookie和JWT的方式。同时框架内置了其他的一些实现，例如基于oAuth2.0的实现，包括谷歌、Facebook、GitHub等用于支持第三方登录。

在 .NET 上构建超大托管数组这些年经常看到有人抱怨 .NET 数组的最大长度。在 .NET 里，数组、集合、Span 以及很多相关 API 都是围绕 32 位长度和索引设计的。GitHub 上曾经有一个很长的 issue 讨论 64 位数组支持，但最后以 "won't fix" 关闭，因为这件事会牵涉到运行时、GC、JIT、类型系统、反射以及大量现有代码。

.NET修仙日记

Scrutor：.NET 依赖注入自动化的优雅实现在现代 .NET 开发中，依赖注入（DI）已经成为标配功能。手动注册每一个服务，不仅代码繁琐、重复度高，还容易出现漏注册、错注册的问题，给项目维护带来负担。Scrutor 是一款轻量的 NuGet 扩展库，基于约定优于配置的思想，让 .NET 依赖注入实现全自动注册，大幅简化开发流程。