码栈工坊_源代码分享,技术文章,精品素材,网站模板,网站源码,建站源码,模板下载

委托的五个基本使用步骤

Wed, 15 Jul 2026 23:49:18 +0800

委托的五个基本使用步骤

1. 委托使用流程

委托用于保存并调用符合指定签名的方法。

基本流程：

声明委托类型。
编写符合签名的方法。
创建委托变量。
关联具体方法。
调用委托变量。

2. 第一步：声明委托类型

使用 delegate 关键字声明委托：

public delegate void AlarmHandler(
    string equipmentId,
    string message);

该声明规定了方法签名：

返回值必须为 void。
参数数量、类型和顺序必须兼容。
方法名称不受限制。

委托可以声明在命名空间中，也可以嵌套在类中。需要被多个类使用时，通常放在命名空间中。

3. 第二步：编写匹配方法

static void ShowAlarm(
    string equipmentId,
    string message)
{
    Console.WriteLine(
        $"界面报警：{equipmentId}，{message}");
}

static void WriteAlarmLog(
    string equipmentId,
    string message)
{
    Console.WriteLine(
        $"写入日志：{equipmentId}，{message}");
}

下面的方法不能关联到 AlarmHandler：

// 错误：缺少 message 参数
// static void InvalidMethod(string equipmentId)
// {
// }

签名不匹配时会产生编译错误。

4. 第三步：创建委托变量

委托是引用类型，可以先创建空变量：

AlarmHandler handler = null;

也可以在创建时直接指定方法：

AlarmHandler handler = ShowAlarm;

完整写法如下，但通常不需要：

AlarmHandler handler =
    new AlarmHandler(ShowAlarm);

5. 第四步：关联委托方法

使用 `=` 赋值

handler = ShowAlarm;

= 会替换委托变量原来关联的方法。

使用 `+=` 添加

handler += WriteAlarmLog;

此时委托依次关联：

ShowAlarm
WriteAlarmLog

一个委托关联多个方法，称为多播委托。

使用 `-=` 移除

handler -= ShowAlarm;

-= 会移除一个匹配的方法关联。方法不存在时不会报错。

6. 第五步：调用委托

可以像调用普通方法一样调用委托：

handler("EQ-001", "温度过高");

更安全的写法：

handler?.Invoke(
    "EQ-001",
    "温度过高");

?.Invoke() 会先检查委托是否为 null，避免 NullReferenceException。

7. 完整工控示例

public delegate void AlarmHandler(
    string equipmentId,
    string message);

classProgram
{
    static void Main()
    {
        AlarmHandler handler = ShowAlarm;
        handler += WriteAlarmLog;

        CheckTemperature(86.5, handler);

        handler -= ShowAlarm;
        CheckTemperature(90, handler);
    }

    static void CheckTemperature(
        double temperature,
        AlarmHandler handler)
    {
        if (temperature > 80)
        {
            handler?.Invoke(
                "EQ-001",
                $"温度过高：{temperature}");
        }
    }

    static void ShowAlarm(
        string equipmentId,
        string message)
    {
        Console.WriteLine(
            $"界面报警：{equipmentId}，{message}");
    }

    static void WriteAlarmLog(
        string equipmentId,
        string message)
    {
        Console.WriteLine(
            $"报警日志：{equipmentId}，{message}");
    }
}

第一次检测会显示界面报警并记录日志。移除 ShowAlarm 后，第二次检测只记录日志。

8. 关联实例方法

委托既可以关联静态方法，也可以关联实例方法。

public class AlarmService
{
    public void Save(
        string equipmentId,
        string message)
    {
        Console.WriteLine(
            $"保存报警：{equipmentId}，{message}");
    }
}

AlarmService service = new AlarmService();
AlarmHandler handler = service.Save;

handler("EQ-002", "压力过高");

关联实例方法时，委托会同时保存对象引用和方法引用。

9. 多播委托注意事项

方法按照添加顺序依次执行。
某个方法抛出未处理异常时，后续方法不会继续执行。
多播委托有返回值时，调用结果是最后一个方法的返回值。
= 会覆盖原有关联，添加方法应使用 +=。
长期保存实例方法的委托，会同时保留对应对象的引用。

查看已关联的方法：

foreach (Delegate item in handler.GetInvocationList())
{
    Console.WriteLine(item.Method.Name);
}

10. WinForms 事件中的委托

buttonStart.Click += buttonStart_Click;

这段代码将 buttonStart_Click 方法关联到 Click 事件内部使用的委托。

private void buttonStart_Click(
    object sender,
    EventArgs e)
{
    Console.WriteLine("启动设备");
}

事件处理方法必须符合 EventHandler 规定的签名。

11. 常见错误

问题	原因
方法无法关联	返回值或参数签名不兼容
调用时空引用	委托变量未关联方法
原方法意外消失	错把 `+=` 写成 `=`
移除方法未生效	移除的不是同一个方法关联
后续方法没有执行	前面的方法抛出了异常

12. 小结

委托类型规定可关联方法的签名。
委托变量用于保存具体方法。
= 负责赋值，+= 负责添加，-= 负责移除。
调用多播委托时，方法按照关联顺序执行。
推荐使用 ?.Invoke() 安全调用可能为空的委托。

写给 .NET Core 开发者的 AI Prompt 工程：把需求说成可生成的代码

Tue, 14 Jul 2026 09:21:24 +0800

AI 能写代码，但它不会自动知道你的项目边界、命名风格、异常策略、测试框架、数据库约定和架构规则。很多生成结果差，不是模型完全不行，而是 Prompt 只给了一个模糊任务：“帮我写一个 API”。

对 .NET Core 开发来说，一个有效 Prompt 应该像一份小型开发任务说明：上下文清楚、技术栈明确、边界具体、验收条件可验证。这样生成出来的代码才更接近项目真实需要。

差的 Prompt 为什么差

类似这样的请求很常见：

Create a user API in .NET Core.

它缺少所有关键约束：使用 Minimal API 还是 Controller？是否用 EF Core？数据库是什么？是否需要验证？返回什么错误格式？是否写测试？项目分层如何？AI 只能按默认猜测生成，结果往往看起来能运行，但很难直接进入项目。

好的 Prompt 要先给上下文

上下文不需要写成长篇文档，但要足够具体：

我在一个 ASP.NET Core 8 Web API 项目中新增用户注册功能。
项目使用 Controller + MediatR + FluentValidation + EF Core。
返回错误统一使用 ProblemDetails。
请只生成 Application 层 command、validator、handler，以及 Controller action。
不要生成数据库迁移。

这段话把技术栈、分层边界和不要做的事情都说清楚了。AI 最怕的不是任务难，而是边界模糊。

把架构规则写进 Prompt

如果你的项目有 Clean Architecture 约定，就不要只说“使用 Clean Architecture”。要写成具体规则：

架构约束：
1. Domain 层不能引用 EF Core。
2. Application 层只能依赖接口，不直接使用 DbContext。
3. Infrastructure 层实现仓储接口。
4. Controller 不写业务逻辑，只发送 MediatR command。
5. 所有公开 DTO 使用 record。

这样生成结果更容易保持引用方向正确。

让 AI 输出可编译的 C# 代码

Prompt 里最好明确文件边界。比如注册用户功能可以要求输出这些文件：

请按文件分段输出：
- RegisterUserCommand.cs
- RegisterUserValidator.cs
- RegisterUserHandler.cs
- UsersController.cs
- RegisterUserTests.cs

生成的核心 command 可以长这样：

public sealed record RegisterUserCommand(
    string Email,
    string Password,
    string DisplayName) : IRequest<Result<Guid>>;

public sealed class RegisterUserValidator : AbstractValidator<RegisterUserCommand>
{
    public RegisterUserValidator()
    {
        RuleFor(x => x.Email).NotEmpty().EmailAddress();
        RuleFor(x => x.Password).MinimumLength(12);
        RuleFor(x => x.DisplayName).NotEmpty().MaximumLength(80);
    }
}

这类输出比“一段完整代码”更容易复制到现有项目，也更容易逐文件审查。

明确错误处理策略

.NET 项目里错误处理风格差异很大：有人抛异常，有人返回 Result<T>，有人统一 ProblemDetails。Prompt 必须说明。

错误处理要求：
- 校验错误由 FluentValidation 产生。
- 业务冲突返回 Result.Conflict，不抛异常。
- Controller 将 Result 映射为 200、400、409。
- 不要返回裸字符串错误。

对应的 Controller 可以是：

[HttpPost("register")]
public async Task<IActionResult> Register(
    RegisterUserCommand command,
    CancellationToken cancellationToken)
{
    var result = await sender.Send(command, cancellationToken);

    return result.Status switch
    {
        ResultStatus.Success => Ok(new { userId = result.Value }),
        ResultStatus.Conflict => Conflict(CreateProblem(result.Error)),
        ResultStatus.Invalid => ValidationProblem(result.ValidationErrors),
        _ => StatusCode(StatusCodes.Status500InternalServerError)
    };
}

Prompt 写得越清楚，AI 越不容易把异常、状态码和响应模型混成一团。

验收条件要可执行

只说“代码要好”没有意义。可以把验收标准写成测试要求：

请同时生成单元测试，至少覆盖：
1. 邮箱格式错误时验证失败。
2. 邮箱已存在时返回 Conflict。
3. 注册成功时返回新用户 ID。
4. handler 不直接引用 Controller 或 HttpContext。

测试示例：

[Fact]
public async Task Handle_ShouldReturnConflict_WhenEmailAlreadyExists()
{
    var repository = Substitute.For<IUserRepository>();
    repository.ExistsByEmailAsync("test@example.com", Arg.Any<CancellationToken>())
        .Returns(true);

    var handler = new RegisterUserHandler(repository);
    var command = new RegisterUserCommand("test@example.com", "StrongPassword123!", "Test");

    var result = await handler.Handle(command, CancellationToken.None);

    result.Status.Should().Be(ResultStatus.Conflict);
}

Prompt 也是团队工程资产

对个人来说，Prompt 可以临时写。对团队来说，常用 Prompt 应该像代码模板一样沉淀下来。比如“新增 CRUD 模块”“新增后台任务”“新增集成测试”“重构 Controller 到 Minimal API”，都可以形成固定格式。

好的 .NET Prompt 不追求华丽措辞，而是把真实工程约束告诉 AI：项目怎么分层、依赖怎么注入、错误怎么返回、测试怎么验证、哪些文件不能碰。越接近开发任务单，生成结果越可控。

Windows .NET生产环境高可用：NLB的工程价值与边界

Tue, 14 Jul 2026 09:20:02 +0800

很多.NET团队做高可用，第一反应是上Nginx或云厂商的ALB，往往忽略了Windows Server自带的NLB。NLB不需要额外买软件，不用改代码，在Windows生态里开箱即用。但它也有明显的局限——不检测应用健康、网络配置稍有不慎就翻车。这篇把NLB是什么、怎么接、适合谁、坑在哪说清楚，帮你快速判断它值不值得用。

NLB 是什么

NLB（Network Load Balancing）是Windows Server操作系统内置的网络负载均衡功能。它工作在传输层（第四层），基于TCP/IP协议将客户端请求分发到集群中的多台服务器上。NLB集群对外暴露一个虚拟IP地址（VIP），客户端访问这个VIP，NLB根据配置的端口规则将流量转发到集群内某台真实服务器。

官网：

https://learn.microsoft.com/en-us/windows-server/networking/technologies/network-load-balancing

GitHub（PowerShell模块文档）：

https://github.com/MicrosoftDocs/windows-powershell-docs/tree/main/docset/winserver2025-ps/NetworkLoadBalancingClusters

核心机制与工程价值：

集群化流量分发：
最多支持32台服务器组成一个NLB集群，所有节点共享同一个虚拟IP。客户端感知不到后端有多台服务器，集群表现为一个逻辑节点。
故障自动剔除：
NLB节点之间通过心跳检测（默认每秒一个心跳包）判断彼此存活状态。节点离线后，流量在数秒内自动重新分发到其他节点。但要注意：NLB只检测节点是否在线，不检测应用程序是否正常工作——IIS停了，NLB照常把请求发过去。
三种运行模式：
单播（Unicast）、多播（Multicast）、IGMP多播。单播配置最简单但可能导致交换机洪泛；多播和IGMP多播对带宽利用更友好，但需要网络设备支持静态ARP或IGMP Snooping。集群内所有节点必须使用同一种模式。
无需改代码：
NLB工作在操作系统层面，应用本身不需要任何改造——这对遗留.NET Framework应用尤其友好。
运维成本低：
通过Windows Server的“网络负载平衡管理器”或PowerShell的NetworkLoadBalancingClusters模块管理，Windows运维人员上手成本低。
支持非HTTP协议：
NLB工作在四层，不仅能负载均衡IIS的HTTP/HTTPS流量，还能支持WCF服务、自定义TCP绑定的Windows服务、.NET Remoting甚至FTP服务。这些老项目往往没有现成的七层代理方案，NLB几乎是唯一不改代码就能实现高可用的路径。

怎么引入

NLB是Windows Server功能，不需要额外下载安装包。在每台要加入集群的服务器上通过服务器管理器添加角色和功能，勾选“网络负载平衡”即可。

PowerShell脚本接入方式（适合批量自动化部署）

以下脚本在首台节点（WEB01）上执行，创建集群并添加第二台节点：

# 1. 安装NLB功能（所有节点都需要执行，建议加上管理工具）
Install-WindowsFeature -Name NLB -IncludeManagementTools

# 2. 在首台节点（WEB01）上创建集群
# -InterfaceName 需替换为实际网卡名称，可通过 Get-NetAdapter 查看
New-NlbCluster -ClusterPrimaryIP "192.168.1.100" `
    -InterfaceName "Ethernet" `
    -OperationMode Unicast

# 3. 将默认的“所有端口（0-65535）”规则删掉
# NLB默认放行所有端口，生产环境建议精细化管理
Get-NlbClusterPortRule | Remove-NlbClusterPortRule -Force

# 4. 精确添加80端口规则（利用管道规避ClusterName参数不存在的Bug）
Get-NlbCluster |Add-NlbClusterPortRule -StartPort 80-EndPort 80-Protocol TCP -Affinity Single

# 5. 将第二台节点（WEB02）拉入集群
# -HostName 指定现有集群中的任一节点，-NewNodeName 指定新节点
Add-NlbClusterNode -HostName "WEB01" `
    -NewNodeName "WEB02" `
    -NewNodeInterface "Ethernet"

图形化和脚本方式可混用——界面上创建的集群同样可以通过PowerShell管理，反之亦然。两种方式选择取决于团队习惯：少量服务器、临时测试用图形界面更直观；大批量部署或自动化运维场景建议优先脚本。

必须项：

每台节点的NLB功能已安装
每台节点配置静态IP（不能用DHCP）
集群虚拟IP与节点真实IP在同一子网
所有节点操作系统版本一致（跨版本混用存在兼容性风险）
集群内所有节点使用相同的操作模式

可选项：

双网卡：建议业务网卡和NLB心跳通信使用不同网卡
IGMP多播模式：如果交换机支持IGMP Snooping，可考虑启用
Drainstop：节点下线前先用Drainstop排空现有连接，避免连接中断

验证是否接入成功：

打开“网络负载平衡管理器”，确认所有节点状态为“已聚合”（绿色对勾）
从客户端ping集群虚拟IP，确认可达
访问集群VIP上的服务（如HTTP），确认能正常返回
手动停止其中一台节点的NLB服务（管理器右键节点 → “停止”，或Stop-NlbClusterNode -NodeName WEB01），观察流量是否在数秒内切换到其他节点

快速上手

示例1：最小可用接入——两台IIS服务器构成NLB集群

目标：两台Windows Server（WEB01、WEB02）上部署相同的IIS站点，通过NLB集群VIP对外提供服务。

前置条件：两台服务器已安装IIS，站点内容已同步（可用DFS或手动复制）。

PowerShell配置（在WEB01上执行）：

# 在WEB01和WEB02上分别安装NLB
Install-WindowsFeature -Name NLB -IncludeManagementTools

# WEB01上创建集群，VIP为192.168.1.100
New-NlbCluster -ClusterPrimaryIP "192.168.1.100" `
    -InterfaceName "Ethernet" `
    -OperationMode Unicast

# 删除默认端口规则
Get-NlbClusterPortRule | Remove-NlbClusterPortRule -Force

# 添加80端口规则
Get-NlbCluster |Add-NlbClusterPortRule -StartPort 80-EndPort 80-Protocol TCP -Affinity Single

# 添加WEB02到集群
Add-NlbClusterNode -HostName "WEB01" `
    -NewNodeName "WEB02" `
    -NewNodeInterface "Ethernet"

预期输出：NLB管理器显示两个节点状态均为“已聚合”。客户端访问http://192.168.1.100能看到站点页面。

验证步骤：

访问VIP，确认页面正常返回
停止WEB01的NLB服务（管理器右键节点 → “停止”，或Stop-NlbClusterNode -NodeName WEB01），再次访问VIP，确认请求被转发到WEB02
重新启动WEB01的NLB服务（管理器右键节点 → “启动”），等待状态恢复“已聚合”

示例2：典型业务场景——ASP.NET Core应用+NLB + Redis共享Session

目标：多台服务器运行同一套ASP.NET Core应用，通过NLB分发流量，Session状态存储在Redis中，实现无状态水平扩展。

关键依赖：每台服务器安装.NET运行时；Redis作为分布式缓存（独立部署或云服务）。

核心配置（Program.cs）：

var builder = WebApplication.CreateBuilder(args);

// 配置Redis作为分布式Session存储
builder.Services.AddDistributedRedisCache(options =>
{
    options.Configuration = "192.168.1.200:6379"; // Redis地址
    options.InstanceName = "Session";
});

builder.Services.AddSession(options =>
{
    options.IdleTimeout = TimeSpan.FromMinutes(30);
    options.Cookie.HttpOnly = true;
    options.Cookie.IsEssential = true;
});

var app = builder.Build();

app.UseSession();
app.MapGet("/", (HttpContext ctx) =>
{
var count = ctx.Session.GetInt32("Count") ?? 0;
    count++;
    ctx.Session.SetInt32("Count", count);
return$"访问次数：{count}，节点：{Environment.MachineName}";
});

app.Run();

NLB端口规则配置（与示例1相同，80端口，亲和性选“单一”或“无”均可——因为Session已外置，不需要保持会话粘滞，选“无”可实现更均匀的轮询分发）。

预期输出：多次刷新页面，Environment.MachineName可能在WEB01和WEB02之间切换（取决于NLB的分发策略），但Session中的计数持续累加——说明Session在Redis中共享。

验证步骤：

在WEB01和WEB02上分别部署同一应用
配置NLB集群VIP
多次访问VIP，确认Session状态不丢失
停止其中一台节点的NLB服务，确认Session仍然可用

示例3：典型业务场景——HTTPS站点（NLB四层透传）

目标：NLB在四层透传TCP 443流量，SSL证书在每台后端服务器上独立配置，NLB不做SSL卸载。

图形化配置： 在端口规则页面添加443端口的规则，协议选TCP，亲和性选“单一”。

PowerShell配置：

Get-NlbCluster | Add-NlbClusterPortRule -StartPort 443 -EndPort 443 -Protocol TCP -Affinity Single

后端IIS绑定SSL证书（每台服务器独立导入证书，绑定到443端口）。

预期输出：客户端访问https://VIP，证书正常、页面正常返回。

验证步骤：

在各节点分别配置SSL证书（证书需一致或使用通配符证书）
通过浏览器访问https://VIP，确认无证书警告
抓包确认NLB没有解密流量，TCP payload原样透传

示例4：进阶能力——通过PowerShell脚本实现自动化节点上下线

目标：发布新版本时，通过脚本将节点从NLB集群中优雅摘除，更新完成后重新加入。

# 将节点置为"排空"状态——停止接收新连接，但保持现有连接
Suspend-NlbClusterNode -NodeName "WEB02"

# 等待现有连接处理完毕（可根据业务自定义等待时间）
Start-Sleep -Seconds 60

# 停止该节点的NLB服务
Stop-NlbClusterNode -NodeName "WEB02"

# ---- 在此执行应用更新 ----

# 启动NLB服务
Start-NlbClusterNode -NodeName "WEB02"

# 恢复节点接收流量
Resume-NlbClusterNode -NodeName "WEB02"

图形化对应操作：右键节点 → “控制主机” → “排空” → 等待 → “停止” → 更新完成后右键 → “启动” → 再右键 → “恢复”。

预期输出：节点WEB02进入暂停状态后，新请求不再转发到该节点；已有连接继续服务直至完成。更新完成后恢复。

实战常见报错

报错现象	触发条件	修复方式
NLB管理器显示节点状态为“未聚合”	节点间心跳不通，通常因防火墙阻挡、网络隔离或MAC地址冲突	检查防火墙放行NLB相关端口（UDP 2504、TCP 2505）；确认所有节点在同一二层网络；单播模式下确认交换机未因MAC冲突导致丢包
跨网段访问VIP间歇性失败	单播模式下，交换机ARP表学习异常	改用多播模式，或在交换机上配置静态ARP条目
节点离线后流量切换超过10秒	心跳参数`AliveMsgTolerance`默认值过大，或网络延迟高	调整注册表`AliveMsgPeriod`和`AliveMsgTolerance`值；检查网络质量

适用场景

高并发、无状态服务： NLB工作在四层，转发效率高、延迟低，适合对性能敏感的场景。单实例可支撑亿级并发连接。但如果业务对请求路由有七层需求（如按URL路径分发），NLB做不了——需要用ALB或反向代理。

Windows Server + IIS技术栈： 这是NLB最经典的落地场景。如果你的团队主要维护Windows Server上的.NET应用，NLB与IIS的集成度是最高的，运维成本也最低。

老旧TCP服务的救星： 很多.NET团队的后端还有WCF服务、自定义TCP绑定的Windows服务、.NET Remoting甚至FTP服务。这些场景下，Nginx/ALB这类七层代理要么原生不支持，要么需要大量改造。NLB工作在四层，不管上层协议是HTTP还是TCP，照单全收，这是NLB相比七层方案的独特优势。

微服务架构： 通常不建议直接拿NLB做微服务网关。微服务需要七层路由、灰度发布、熔断降级等能力，NLB只提供四层负载均衡。更常见的做法是：NLB作为入口的第一层（四层负载），后端接API网关（如Ocelot、YARP）或Kubernetes Ingress。

单体应用水平扩展： NLB非常适合。业务逻辑无状态或状态外置（如Session存Redis），加几台服务器、配好NLB，扩展就完成了。代码零改动。

前置条件：

应用必须是无状态或状态已外置（如Session存Redis/数据库）；如有状态应用依赖本地Session，开启Affinity Single可基于源IP保持会话粘滞，但客户端IP变化或大量用户挤在同一NAT出口时会失效，需自行评估
服务器必须在同一二层网络（除非用多播+静态路由）
所有节点操作系统版本需一致
网络设备需支持NLB所选的操作模式

风险：

NLB不检测应用健康，应用进程挂了但节点在线，流量照常转发
单播模式下可能引发交换机洪泛，影响整个网络性能
不支持跨子网集群（除非借助多播+静态路由等复杂配置）

实战建议

高频坑位1：单播模式导致交换机洪泛

触发条件： 采用默认的单播模式，NLB将所有节点的网卡MAC地址修改为同一个虚拟MAC地址。交换机MAC地址表混乱，将发往VIP的流量广播到所有端口。

错误表现： 网络性能骤降，非NLB节点也收到大量无关广播包，严重时整个网段瘫痪。

修复策略：

方案A：改用多播模式（需在交换机配置静态ARP和MAC表项）
方案B：在交换机和NLB节点之间加一台Hub
方案C：为NLB节点单独划分VLAN
方案D：启用IGMP多播模式（需交换机支持IGMP Snooping）

图形化修改操作模式：右键集群 → “群集属性” → “群集参数”选项卡 → 将“群集操作模式”从“单播”改为“多播”或“IGMP多播”。

高频坑位2：应用挂了但节点还在集群里

触发条件： IIS或ASP.NET Core进程崩溃，但操作系统正常运行，NLB心跳正常发送。

错误表现： 部分请求返回500或超时，监控显示节点在线但服务不可用。

修复策略：

部署外部健康检查脚本，定时探测应用端口/健康检查接口，发现问题时通过PowerShell暂停该节点的NLB服务
或在前端再加一层ARR（Application Request Routing），由ARR做七层健康检查
廉价平替方案：用Windows任务计划程序，写一个PowerShell脚本每分钟执行Invoke-WebRequest访问本机localhost的健康检查接口。如果连续3次返回非200状态码，执行Stop-NlbClusterNode -NodeName $env:COMPUTERNAME让节点自残下线；应用恢复后再通过脚本执行Start-NlbClusterNode -NodeName $env:COMPUTERNAME重新上线。这是成本最低的应用级健康检查方案。

高频坑位3：跨Windows Server版本的节点混用

触发条件： 集群中混用不同版本的Windows Server（如2016和2019）。

错误表现： 节点无法聚合、心跳异常、流量分发不规则。实测跨版本混用存在较高概率的兼容性问题。

修复策略： 所有NLB节点统一使用相同版本的操作系统镜像。规划阶段就明确版本标准，避免临时拼凑。

其他建议

建议为NLB心跳配置独立网卡，避免心跳流量与业务流量互相干扰
节点下线时优先用“排空”（Drainstop）而非直接“停止”，避免粗暴切断现有连接
部署新版本时，逐台摘节点、更新、加回，实现零停机发布
定期检查事件日志中的NLB相关警告（Event ID 34等）
图形化管理器支持远程管理其他服务器的NLB集群：打开管理器 → “群集”菜单 → “连接到现存的” → 输入目标集群的任意节点IP

选型建议

更适合NLB的场景：

团队以Windows Server运维为主，不想引入额外的负载均衡软件
应用是传统的.NET Framework + IIS，改造为容器化或云原生成本高
只需要四层负载均衡，没有七层路由需求
服务器数量不多（2-8台），网络环境可控
对延迟敏感，需要四层的高转发效率
需要负载均衡的服务不是HTTP协议（如WCF、自定义TCP服务、FTP等）

不太适合NLB的场景：

需要七层路由（按URL、Header分发）——选ALB或反向代理（Nginx、YARP）
服务器分布在多个子网或混合云环境——选云厂商LB或软件定义LB
应用严重依赖本地Session，且客户端网络环境复杂（如移动端频繁切换IP，或大量客户端隐匿在同一个企业NAT大网IP后面导致负载极度不均衡）——NLB基于IP的亲和性在NAT场景下会失效
需要细粒度的健康检查（如检查具体API返回值）——NLB只做端口级检测
团队对Linux更熟悉、没有Windows Server运维能力

判断倾向： 如果你的应用跑在Windows Server上、只需要四层负载均衡，NLB是一个值得优先考虑的方案——成本低、上手快、与Windows生态集成好。但如果网络环境复杂或对七层路由有要求，不要把NLB硬撑到它不擅长的领域，前端加一层Nginx或YARP是更稳妥的做法。

参考建议：

小团队（2-3人）、并发量不大（百万级以下）、上线周期紧：NLB可以快速落地
中大规模（并发千万级以上）、有专职运维：建议NLB + ARR组合，或云厂商LB
容器化/K8s环境：不用NLB，用Ingress Controller或Service LoadBalancer

总结收尾

NLB解决的是Windows Server环境下多台服务器之间流量分发和故障转移的问题——开箱即用、不改代码、运维友好。图形化管理器让不熟悉命令行的运维人员也能十分钟内搭起一套集群。但它不检测应用健康、网络配置有坑，也不是七层路由的替代方案。如果你们的应用跑在Windows Server上、无状态、只需要四层负载均衡，NLB值得认真考虑；如果需要七层能力或网络环境复杂，别硬撑，加一层Nginx或YARP更稳妥。先从一个最小集群试起来，把网络模式和健康检查想清楚，再往生产推。

前端又一个 “全家桶” 出现了！

Mon, 13 Jul 2026 14:36:59 +0800

做后台系统的人，迟早都会碰到一个需求：

附件在线预览。

一开始看着很简单，图片直接展示，PDF 接个 pdf.js，文本塞进代码编辑器，视频交给浏览器。

真正麻烦的是后面。

用户开始上传 doc、xls、pptx、wps、et，再混进压缩包、邮件、图纸、代码文件，原本一个小功能，很快就变成一套独立系统。

我自己也被这个问题折腾过很多次。

所以我做了一个文件预览 SDK：

Open File Viewer。

目前已经支持原生 JavaScript、Vue、React、Svelte，Office 方向也覆盖了 doc、docx、xls、xlsx、pptx 等常见格式。

这篇文章不讲概念，直接聊它解决了什么，以及这套 SDK 是怎么设计的。

文件预览最难的地方，是失控

很多项目最早的预览代码，大概都是这样：

if (isPdf(file)) {
  openPdf(file);
} else if (isImage(file)) {
  openImage(file);
} else if (isOffice(file)) {
  openOffice(file);
} else {
  download(file);
}

刚开始没问题。

等格式一多，业务就会慢慢失控：

PDF 有一套工具栏
图片有一套缩放逻辑
Office 有一套加载状态
视频有自己的控制器
压缩包只能下载
错误状态各写各的

同一个预览功能，弹窗里写一遍，详情页再写一遍，审批流和附件中心继续复制。

最后项目里没有“文件预览能力”，只有一堆散落的格式判断。

我开发 Open File Viewer，最先解决的就是这个问题：

把所有文件预览统一收口到一个入口。

业务层只负责传文件，剩下的格式识别、插件匹配、渲染、错误处理、下载兜底，全部交给 SDK。

一套 Core，支持四种技术栈

Open File Viewer 没有把能力绑死在某个框架里。

它的核心结构分成几层：

JavaScript / Vue / React / Svelte
                ↓
         Framework Adapter
                ↓
      Open File Viewer Core
                ↓
          Plugin System
                ↓
             Renderer

底层 Core 负责：

文件识别
插件调度
状态管理
容器生命周期
工具栏
主题
错误处理
Fallback

上层的 Vue、React、Svelte 只负责框架适配。

所以不管项目用什么技术栈，底层走的都是同一套预览能力。

一个团队里完全可能同时存在：

老后台：原生 JavaScript
管理端：Vue
新产品：React
轻量页面：Svelte

以前需要分别维护四套方案，现在可以共用一套插件和渲染逻辑。

这也是我一开始就把它做成 SDK，而不是只做一个 Vue 组件的原因。

插件系统才是核心

文件格式太多，靠一个超级组件硬扛，后面一定会越来越重。

所以 Open File Viewer 把不同格式拆成独立插件。

比如：

const plugins = [
  officePlugin(),
  pdfPlugin(),
  imagePlugin(),
  textPlugin()
];

文件传入之后，内部流程大致是：

读取文件信息
    ↓
识别扩展名和 MIME
    ↓
匹配对应插件
    ↓
创建 Renderer
    ↓
渲染到统一容器

每个插件只处理自己负责的内容。

officePlugin() 关注 Office，pdfPlugin() 处理 PDF，imagePlugin() 负责图片，后面也可以继续扩展音视频、压缩包、CAD、GIS、3D 等能力。

这种结构有两个好处。

第一，格式之间互不干扰。Office 插件出问题，不会影响图片和 PDF。

第二，业务可以按需加载。项目只需要 PDF 和 Office，就只注册这两个插件，不必把所有能力全部打进包里。

doc / xls 支持，才是真正进入业务系统

很多 Office 预览方案都会写一句：

支持 Word、Excel、PPT。

真正点进去一看，支持的是：

docx
xlsx
pptx

碰到 doc、xls 就没了。

但在真实项目里，老版 Office 文件根本绕不开。

特别是这些系统：

OA
档案管理
合同系统
财务系统
政企项目
内部知识库

历史数据里往往有大量 doc 和 xls。

用户不会区分 doc 和 docx，也不会关心二进制格式和 XML 格式的区别。他只知道这个文件明明是 Word，为什么点不开。

所以这次我把 doc、xls 也补了进来。

目前 Office 方向覆盖：

doc
docx
xls
xlsx
pptx
rtf
odt
csv
wps
et
dps

对国内业务来说，wps、et、dps 同样很重要。

文件格式从来不会按照开发者最舒服的方式出现，预览组件能不能处理这些“脏数据”，直接决定了它能不能落地。

四种技术栈，接入方式保持一致

原生 JavaScript

import {
  OpenFileViewer,
  officePlugin,
  pdfPlugin,
  imagePlugin
} from"@open-file-viewer/core";

const viewer = new OpenFileViewer({
  container: document.querySelector("#viewer"),
  plugins: [
    officePlugin(),
    pdfPlugin(),
    imagePlugin()
  ]
});

viewer.open(file);

原生项目、老后台、WebView、低代码平台都可以直接使用，不需要额外引入框架。

Vue

<OpenFileViewer
  :file="file"
  :file-name="file.name"
  :plugins="plugins"
  width="100%"
  height="640px"
  toolbar
/>

React

<OpenFileViewer
  file={file}
  fileName={file.name}
  plugins={plugins}
  width="100%"
  height="640px"
  toolbar
/>

Svelte

<OpenFileViewer
  {file}
  fileName={file.name}
  {plugins}
  width="100%"
  height="640px"
  toolbar
/>

四套写法看起来不同，底层调用的是同一个 Core。

这意味着格式支持、工具栏、异常状态、插件能力都不会因为框架不同而割裂。

真正难做的，还有失败状态

文件预览不可能永远成功。

真实项目里经常会碰到：

文件链接过期
对象存储跨域
文件体积过大
格式伪装
文件损坏
浏览器能力不足
插件加载失败

所以一套能落地的预览 SDK，必须把完整状态链路处理掉：

loading
preview
error
unsupported
download fallback

Open File Viewer 把这些状态统一放进容器里。

业务层不用给每一种格式重复写加载动画、错误提示和下载按钮。

预览成功，就进入 Renderer。

预览失败，就进入 Fallback。

格式不支持，也可以直接提示下载，或者接入服务端转换。

Office 高保真预览，必须保留服务端路线

浏览器端预览 Office 有天然边界。

复杂 Word 里可能有：

特殊字体
页眉页脚
浮动图片
文本框
修订记录
嵌套表格

Excel 里也会出现复杂公式、图表、冻结窗格和大数据量。

前端可以完成基础预览，但很难百分之百复刻 Microsoft Office 或 WPS 的排版结果。

所以更稳的工程方案通常是：

普通文件
前端直接预览

复杂文件
服务端转换为 PDF
前端继续预览

Open File Viewer 可以把两条路线统一起来。

前端能直接处理的，交给 Office 插件；需要高保真的，服务端转成 PDF，再交给 PDF 插件。

用户看到的仍然是同一个预览容器，业务页面也不用维护两套 UI。

官网已经可以在线体验

我做了一个在线官网，可以直接体验：https://open-file-viewer-workspace.void.app/

里面可以查看不同格式的预览效果，也可以了解插件体系和接入方式。

正在做这些项目的朋友，可以重点试一下：

附件中心
OA 审批
ERP 单据
CRM 合同
知识库
网盘
低代码平台
档案系统
企业文档平台

这些系统看起来完全不同，底层碰到的问题却高度一致：

文件类型杂，预览逻辑乱，后期维护成本高。

Open File Viewer 想做的，就是把这部分能力统一沉淀下来。

完全免费开源，求个 Star

项目目前完全免费开源。

GitHub 地址：

https://github.com/xushanpei/open-file-viewer

我开发这个项目的原因很简单：

希望把自己踩过的坑做成一套通用能力，帮助更多开发者少重复造轮子。

文件预览这种项目，表面上没有多复杂，真正做起来全是细节。

每一种格式、每一种异常状态、每一个浏览器差异、每一条 Fallback 路径，都需要一点点补齐。

如果你正在做文件预览，欢迎直接拿去试。

觉得项目有用，也希望能顺手给个 Star。

开源不易，一个 Star，真的会成为我继续维护下去的动力。

官网地址：https://open-file-viewer-workspace.void.app/
GitHub 地址：https://github.com/xushanpei/open-file-viewer
npm 地址：https://www.npmjs.com/package/@open-file-viewer/core

一套覆盖8大业务场景的 .NET 企业级快速开发框架

Mon, 13 Jul 2026 10:01:16 +0800

做过企业信息化的人都知道：每个新项目都要重新搭权限、写登录、搞审批流、接消息队列……重复造轮子，乏味且耗时。

有没有一套开箱即用的框架，把这些基础设施全部封装好，让你专注业务逻辑？

Scm.Net 就是为此而生。

笔者多年从事供应链系统及企业信息化系统的产品与研发，在梳理多种项目经验的过程中，开发了这套企业级中后台管理系统的快速开发框架。它采用前后端分离架构，内置权限管理、代码生成、工作流引擎、实时消息、数据可视化等企业级核心能力，目前已支撑 8 款产品落地运行。

01 项目背景与定位

在企业信息化领域，供应链管理系统（SCM）是覆盖面最广、复杂度最高的场景之一。一个完整的供应链体系涉及订单、仓储、运输、配送、计费、园区管理、资产管理和物联网等多个子系统。每个子系统都需要认证授权、权限管控、工作流审批、消息推送、定时任务、数据可视化等基础能力。

Scm.Net 的作者将这些年在多个项目中反复使用的基础设施提炼为一套通用框架，目标只有一个：让开发者不再重复搭建基础设施，专注于业务实现。

🎯 核心定位

企业级中后台管理系统快速开发框架 | 前后端分离架构 | 开箱即用 | 可扩展插件机制

Scm.Net 框架全景

02 已落地产品矩阵

框架的价值不在 PPT 里，而在实际产品中。目前基于 Scm.Net 已开发并运行的产品包括：

简称	产品全称	业务领域
OMS	订单管理系统	订单全生命周期管理
WMS	仓储管理系统	入库/出库/盘点/库存
TMS	运输管理系统	运单调度/路线优化
DMS	配送管理系统	最后一公里配送
BMS	计费管理系统	费用计算/账单生成
YMS	园区管理系统	园区资源/出入管控
EAM	资产管理系统	资产全生命周期
IOT	物联网管理系统	设备接入/数据采集

从订单到仓储，从运输到计费，从园区到物联网——一套框架，8 个产品，覆盖供应链全链路。这足以证明框架的通用性和可扩展性。

03 核心特性全景

Scm.Net 的特性覆盖面非常广，我们按四个维度逐一拆解。

🔐 认证与安全

多维度安全体系

账号登录手机号登录邮箱登录 OAuth OIDC SAML 面部识别指纹识别声纹识别 TOTP 双因素 AES/DES 加密 JWT Bearer

多种登录方式
— 支持账号、手机号、邮箱，以及 OAuth、OIDC、SAML 等第三方联合登录，满足企业内外部多种接入场景
生物识别
— 面部识别、指纹识别、声纹识别接口预留，未来可无缝接入
双因素认证
— 基于 TOTP 的 OTP 动态口令，为高安全场景提供第二道防线
数据加密
— 前后端传输参数支持 AES/DES 加密签名，防止中间人攻击
JWT 鉴权
— Bearer Token 认证，支持自动刷新，无需频繁登录
六级权限体系
— 公司 / 部门 / 岗位 / 分组 / 用户 / 角色，精细到按钮级别

⚙️ 系统与框架

基础设施全覆盖

多数据库多缓存代码生成器工作流引擎动态API 定时任务实时通信 MQTT物联

多数据库支持
— SQLite、MySQL、MariaDB、PostgreSQL、SQL Server、Oracle、Firebird、MongoDB，8 种数据库一个框架全覆盖
多种缓存机制
— MemoryCache、Dictionary、Redis 三种方案灵活切换
代码生成器
— 自动生成实体、DAO、DTO/VO，支持自定义模板，彻底告别手写 CRUD
工作流引擎
— 可视化流程设计、节点配置、表单绑定、在线审批，开箱即用
动态 API
— 自动注册服务为 Web API，无需手动编写 Controller，大幅减少样板代码
API 文档
— Scalar + Swagger UI 双引擎生成，支持自定义注释
定时任务
— Quartz.NET 集成，支持动态任务增删改查
实时通信
— SignalR WebSocket 实时推送与在线聊天
设备物联
— MQTT 协议支持，内置 Broker，直连物联网设备

💼 业务能力

能力	说明
MQTT 通信	轻量级物联网通信协议，支持内置 Broker
RabbitMQ	消息队列，发布者/消费者模式集成
AI 大模型	集成 7+ 主流大语言模型
图像处理	条码生成识别、图片水印、图形验证码、头像裁剪
数据可视化	ECharts 图表集成，Dashboard 看板布局
文件管理	文件上传、导入导出、在线预览
ID 生成器	雪花 ID、序列 ID、格式 ID 等多种方式
插件扩展	Plugin/Addon 动态加载机制

🌐 平台兼容

跨平台运行
— Windows、macOS、Linux、HarmonyOS 全覆盖
响应式布局
— 电脑、平板、手机多种终端自适应
多租户架构
— 可扩展为多租户、多组织架构应用

04 技术栈深度解析

后端核心依赖

Scm.Net 后端基于 .NET 10.0，兼容 .NET 6/7/8/9/10 多个版本。以下是核心依赖一览：

技术	版本	用途
.NET	10.0	跨平台运行时
SqlSugarCore	-	ORM 数据访问框架
ImageSharp	^3.1.12	跨平台图像处理
MQTTnet	-	MQTT 通讯（客户端 + Broker）
RabbitMQ.Client	-	消息队列
Quartz.NET	-	定时任务调度
SignalR	-	实时 Web 通信
Mapster	10.0.7	对象映射（比 AutoMapper 更快）
Serilog	4.3.1	结构化日志
Newtonsoft.Json	-	JSON 序列化
JWT Bearer	10.0.8	认证授权
Scalar	2.16.6	API 文档可视化（新）
Swagger UI	10.2.3	API 文档可视化

💡 技术选型亮点

ORM 选用 SqlSugar 而非 Entity Framework Core，是因为 SqlSugar 对多数据库支持更友好，且 API 更简洁。对象映射选用 Mapster 而非 AutoMapper，性能高出数倍。API 文档同时集成 Scalar 和 Swagger，给开发者更多选择。

前端技术栈（Scm.Vue）

前端独立仓库 Scm.Vue，基于 Vue 3 + Vite 8 + Element Plus 构建：

技术	版本	用途
Vue	^3.5.32	渐进式 JS 框架
Vite	^8.0.3	构建工具（Rolldown 打包）
Element Plus	^2.13.6	Vue 3 桌面端组件库
Pinia	^3.0.0	状态管理
ECharts	^6.0.0	数据可视化
Axios	^1.7.0	HTTP 客户端
SignalR	^10.0.0	实时通信客户端
Vue I18n	^11.0.0	国际化

前端还内置了 40+ 业务组件（scTable、scSearch、scUpload、scDynamicForm 等），支持 三种界面模式：

工作台模式
（Console）— 支持default/header/menu/dock四种风格
云桌面模式
（Desktop）— 类 Windows 桌面体验
大屏模式
（Monitor）— 数据可视化大屏展示

05 架构设计与项目结构

Scm.Net 采用了清晰的分层架构，各模块职责明确：

Scm.Net/
├── Scm.Net/                     # Web API 主入口
│   ├── Controllers/             #   API 控制器
│   ├── Resources/               #   资源文件
│   ├── data/                    #   数据文件（SQLite、上传文件）
│   ├── Program.cs               #   应用入口与启动配置
│   └── appsettings.json         #   应用配置
├── Scm.Core/                    # 核心业务逻辑层
├── Scm.Dao/                     # 数据访问层（DAO）
├── Scm.Dto/                     # 数据传输对象层（DTO）
├── Scm.Common/                  # 公共枚举、工具类
├── Scm.Common.Dto/              # 公共 DTO 定义
├── Scm.Common.Excel/            # Excel 导入导出
├── Scm.Common.Log/              # 日志记录
├── Scm.Common.Os/               # 操作系统工具
├── Scm.Dsa.Dba.Sugar/           # SqlSugar 仓储基类
├── Scm.Dsa.Dfa.Json/            # JSON 数据格式转换
├── Scm.Server/                  # 服务端核心（接口+基础服务）
├── Scm.Server.Api/              # 动态 API 注册
├── Scm.Server.Bearer/           # JWT Bearer 认证
├── Scm.Server.Cache/            # 缓存扩展
├── Scm.Server.Dao/              # 服务端 DAO 扩展
├── Scm.Server.Dvo/              # DTO/VO 映射
├── Scm.Server.MQTT/             # MQTT 通讯
├── Scm.Server.RabbitMQ/         # RabbitMQ 集成
├── Scm.Server.SignalR/          # SignalR 实时通讯
├── Scm.Server.Quartz/           # Quartz 定时任务
├── Scm.Server.Swagger/          # Swagger 文档
├── Scm.Server.Scalar/           # Scalar 文档
├── Scm.Server.Aiml/             # AI 大模型集成
├── Scm.Server.Service/          # 业务服务扩展
├── Scm.Email/                   # 邮件服务
├── Scm.Phone/                   # 短信服务
├── Scm.Generator/               # 代码生成器
├── Samples.*/                   # 示例项目
├── Libs/                        # 预编译库
├── Test/                        # 测试项目
└── Scm.Net.sln                  # 解决方案文件

架构设计上有几个值得关注的点：

模块化拆分策略

注意看项目命名规律：Scm.Server.* 是服务端扩展模块，每个模块负责一个独立能力（MQTT、RabbitMQ、SignalR、Quartz、Swagger、Scalar、AI等）。这种设计让你可以按需引用——如果你的项目不需要 MQTT，就不引用 Scm.Server.MQTT，保持项目轻量。

动态 API 机制

Scm.Server.Api 实现了动态 Web API 注册——你只需要写 Service，框架自动将其注册为 Web API，无需手写 Controller。这借鉴了 Panda.DynamicWebApi 的思路，大幅减少样板代码。

三层分离

Scm.Dao
— 数据访问层，封装数据库操作
Scm.Dto
— 数据传输对象，接口数据契约
Scm.Core
— 核心业务逻辑，真正的业务代码

06 四大设计原则

好的框架背后一定有清晰的设计哲学。Scm.Net 有四条核心设计原则，值得每个使用者理解：

原则一：数据库仅用于存储数据

除 CRUD 外不使用任何依赖特定数据库的特性（如存储过程、触发器、视图等），可平滑迁移到任何支持标准 SQL 的数据引擎。这意味着你今天用 SQLite 开发，明天切到 Oracle，几乎零成本。

原则二：单表操作为主

原则上仅允许单表操作（最多不超过两张表），通过数据冗余设计提升查询效率。这看似"反范式"，实则是用空间换时间——在高并发场景下，避免 JOIN 带来的性能问题。

原则三：JSON 数据交互

多端数据交互基于 JSON 格式，保证低噪音的同时提升可扩展性。新字段加上去不需要改接口签名，前后端解耦更彻底。

原则四：蛇形命名 DTO

DTO 统一使用 snake_case 命名，适配多场景异构应用需求。Python、Java、Go 等语言默认蛇形命名，这样可以无缝对接多语言生态。

07 五分钟快速启动

Step 1：获取代码

# 克隆后端
git clone https://gitee.com/leadiot/scm.net.git

# 克隆前端
git clone https://gitee.com/leadiot/scm.vue.git

Step 2：配置数据库

编辑 Scm.Net/appsettings.json，修改数据库连接串：

{
  "Sql": {
    "Type": "Sqlite",
    "Text": "Data Source=data/scm.db;"
  }
}

💡 零配置启动

默认使用 SQLite，系统启动时自动初始化数据库和种子数据，无需手动建表。开箱即用，拉下来就能跑。

Step 3：启动后端

cd Scm.Net
dotnet run

访问 http://localhost:5000/scalar 确认后端接口正常。

Step 4：启动前端

cd Scm.Vue
npm install
npm run dev

访问 http://localhost:2800 进入前端页面。

演示账号

角色	用户名	密码
管理员	`admin`	`123456`

在线演示地址：http://www.c-scm.net

08 AI 大模型集成

在 AI 蓬勃发展的当下，Scm.Net 也没有缺席。Scm.Server.Aiml 模块集成了 7+ 主流大语言模型：

7+大模型接入，1统一接口

大模型	厂商
DeepSeek	深度求索
华为盘古	华为
通义千问	阿里云
腾讯元宝	腾讯
文心一言	百度
豆包	字节跳动
ChatGPT	OpenAI

这意味着你可以在企业系统中直接集成 AI 能力——智能客服、文档摘要、数据分析、代码辅助等场景，一个接口切换不同模型，无需为每个模型单独适配。

09 核心配置一览

appsettings.json 是整个系统的配置中枢，以下是核心配置节点说明：

配置节点	说明
`Kestrel`	HTTP 监听端点（默认 9999 端口）
`Cache`	缓存配置（MemoryCache / Dictionary / Redis）
`Uid`	ID 生成器配置
`Sql`	数据库连接（8种数据库可选）
`Jwt`	JWT 认证配置
`Cors`	跨域访问配置
`Quartz`	定时任务调度
`Email`	邮件服务（SMTP）
`Oidc`	第三方联合登录
`Otp`	动态口令（TOTP）
`Generator`	代码生成器
`Serilog`	结构化日志
`Scalar`	API 文档可视化
`Swagger`	API 文档可视化

10 内置 API 接口

框架自带以下基础控制器，无需额外开发：

控制器	功能
`CaptchaController`	图形验证码生成
`UploadController`	文件上传
`DownloadController`	文件下载
`GeneratorController`	代码生成
`QuartzController`	定时任务管理
`HbController`	心跳检测
`OnLineController`	在线用户管理

启动后访问 http://localhost:5000/scalar 查看完整 API 文档，所有接口均可在线调试。

11 界面预览

工作台模式

功能	截图
控制台首页
用户管理
文件管理
日程管理
电子邮件
系统监控
在线文档

云桌面模式

功能	截图
桌面首页
云文件管理
记事本
图片查看
音频播放
待办事项
终端管理

C# .NET 周刊｜2026年5月2期

Sun, 12 Jul 2026 22:53:59 +0800

C# .NET 周刊｜2026年5月2期 2026-05-10 dotnet_week_26_5_2

国内文章

OpenHarmony.Avalonia 归档事件对中国自主软件生态的影响--信任的坍塌与生态的异化

https://www.cnblogs.com/shanyou/p/19998663

2026年5月8日，开发者“布布”宣布 OpenHarmony-NET/OpenHarmony.Avalonia 停更并归档，引发技术圈强烈讨论。布布称他以业余身份推进 Avalonia 在鸿蒙的底层适配，并与 Avalonia 官方接触，期待官方或华为合作并获聘。布布为保护商业利益曾放缓公开发布并移至闭源仓库。后来他发现华为在与 Avalonia 洽谈同时在招标平台发布技术标书，外包公司如软通动力中标并在招聘中寻觅 Avalonia 工程师。布布据此怀疑存在利用官方交流信息进行招标的行为。此事触发对企业诚信、开源治理和国产操作系统生态建设路径的广泛争议。

.NET 8 Web开发入门(二)：C# 现代语法速成——为 Web API 量身定制

https://www.cnblogs.com/shenchuanchao/p/19990124/dotnet-8-web-development-part2-modern-csharp-for-webapi

文章讲述在现代.NET 8中将 DTO 从 class 迁移到 record，展示 record 的构造、不变性、值相等性与 with 用法。文章强调异步编程(async/await)对提升 Web 并发的关键性，并用餐厅类比解释同步阻塞的问题。示例直观且实用。文章技术深度中等，原创性一般，缺少引用，个别章节未完整展开。

记一次 .NET 某智慧工厂视觉程序崩溃分析

https://www.cnblogs.com/huangxincheng/p/19980635

文章记录作者用 WinDbg 分析 .NET 程序崩溃的过程。作者提供 dump 输出，显示 CLR 异常 e0434352 和 System.Reflection.TargetInvocationException。作者用 !t 查看线程与托管异常，用 !pe -nested 展开异常链。示例真实，步骤可复现，适合有调试基础的读者。文章实践性强但细节与解决步骤不足，引用缺乏。

【EF Core】值转换器

https://www.cnblogs.com/tcjiaan/p/19966652

作者开篇提及近况和裁员观察，认为多数裁员与 AI 无关。正文介绍 EF Core 值转换器的概念与用途。文章区分两种值：Provider(数据库映射到 .NET 的类型)与 Model(实体属性类型)。当二者不一致时需要值转换器。文中举例说明枚举与数据库字符串互转，以及将自定义 Point 结构序列化为“100,85”字符串保存并还原的场景。文章还提供了建表脚本和部分 C# 实体代码示例。技术性为入门到中级，注重实用示例，未见引用说明来源。

.NET 10 使用 Microsoft.AspNetCore.OpenApi 实现 API 版本管理

https://www.cnblogs.com/denglei1024/p/19975811

文章说明 API 版本管理的重要性，目标是在不破坏现有用户的前提下持续迭代。列举了 URL 路径、查询参数、请求头和媒体类型四种常见策略。指出在 C# 生态中长期用 Swashbuckle 配合 Asp.Versioning，而 .NET 10 推出 Microsoft.AspNetCore.OpenApi，且 Asp.Versioning v10 已支持该库，实现版本管理与文档生成的无缝结合。给出需安装的 NuGet 包列表并示例 Program.cs 配置流程：AddApiVersioning、AddApiExplorer、为每个版本 AddOpenApi、MapOpenApi 和 MapScalarApiReference。示例展示为每个版本生成独立 OpenAPI 文档，并在路由中通过 apiVersion 指定版本，但控制器示例未完整展开。

C# 也能像 Python 一样写脚本 | .NET 10 构建基于文件的应用

https://www.cnblogs.com/denglei1024/p/19979190

文章介绍 .NET 10 的基于文件的应用功能。开发者可在单个 .cs 文件中编写、运行和构建应用，适合快速原型、脚本和小型工具。需要安装 .NET 10 SDK。文中给出两个示例：一个显示当前日期，另一个用 CsvHelper 处理销售数据并生成 CSV。说明了 #:package、#:property、#:sdk、#:reference、#:project 等指令用法及版本写法，并展示 dotnet run <file.cs> 等 CLI 命令。文章实用清晰，但缺少引用和更深入的性能或限制分析。

OpenClaw.NET .NET 原生插件开发完全指南：以 Mempalace 插件为范例

https://www.cnblogs.com/shanyou/p/19974437

文章介绍 OpenClaw.NET，一个用 C#13 从零构建的独立 AI Agent 网关与运行时。项目以 NativeAOT 为核心设计以实现毫秒级冷启动和低内存占用。默认以本地 AOT 模式在回环地址 18789 运行，插件以内进程方式加载以换取性能。框架支持多种插件加载模式并允许标记为仅 JIT 的插件以兼顾扩展性。为兼容 OpenClaw 生态，采用语义兼容的插件契约和配置，并利用 Microsoft.Extensions.AI 与依赖注入实现与 LLM 提供商的集成。插件承担模型接入、消息通道、工具、记忆和后台服务等核心职责，记忆采用独占插槽策略。

.NET 8 Web开发入门(一)：启程——.NET生态全景与开发环境构建

https://www.cnblogs.com/shenchuanchao/p/19972855/dotnet-8-web-development-part1-ecosystem-setup

.NET 8 是LTS版本，具备跨平台、高性能与统一生态。作者纠正了“.NET很老”的误解，指出其可在Linux和macOS上稳定运行并在基准测试中表现优异。文章分解技术栈：CLR 负责将IL即时编译并管理垃圾回收，BCL 提供丰富基础库，SDK 包含运行时、编译器与CLI。文中区分了Runtime与SDK的安装用途并提示常见部署错误。作者回顾了从.NET Framework到.NET Core再到.NET 5+的演进。最后给出安装.NET 8 SDK并用 dotnet --info 验证的实操步骤。

.NET+AI | Harness | MAF 1.4 发布，Harness Engineering 如约而至，智能体工程化更进一步

https://www.cnblogs.com/sheng-jie/p/19995466

文章将 Harness Engineering 定义为模型外的可执行脚手架，强调四要素：有输入、有步骤、有验收、有兜底。文章指出 Harness 解决任务接入、任务拆解、状态管理、环境安全、长上下文收敛与失败恢复等工程问题。作者认为 MAF 1.4 把 Harness 提升为运行时控制面，推动智能体开发从能力拼装走向工程化。文章区分 Skills(能力包)与 Harness(执行治理)，并拟用简单的 .NET 示例说明 Harness 的实际价值。

基于AScript的python3脚本语言发布啦！

https://www.cnblogs.com/rockey627/p/19971851

AScript是开源C#动态脚本引擎，2026-05-04发布AScript.Lang.Python3 0.0.1。它支持Python3基础语法、主要数据类型、函数、列表/集合/字典操作，以及字符串插值和切片。文中提供NuGet安装命令和丰富的C#示例，示范注册语言、上下文指定、@lang嵌入与集合行为。技术深度中等，覆盖基础特性但缺少高级互操作与安全细节。实用性高，示例可直接运行。表达清晰，可读性好。原创性一般，时效性佳，但缺乏引用与性能评估。总体评价良好。

C# SwaggerLoginAuthPlugin 一款给Swagger文档加登录页面的小插件

https://www.cnblogs.com/zhangboyan/p/20001532

文章介绍一款用于局域网限制Swagger查看权限的小插件。作者提供NuGet包和示例代码，说明在非最小API的Web API项目中通过 builder.Services.AddSwaggerAuth 配置默认用户名密码，并在 UseSwagger 前调用 app.UseSwaggerAuth 实现拦截。作者提醒插件仅适合内网使用并给出开源仓库地址。插件由作者借助 deepseek 和 AI 在约2小时内开发，功能简单实用但技术细节和安全说明有限，适合项目组快速加固Swagger访问控制。

.NET生态系统中的A2A(Agent-to-Agent)协议支持与跨平台多智能体协同

https://www.cnblogs.com/shanyou/p/19974558/dotnet-a2a

文章论述从单一大语言模型向分布式多智能体的架构演进。提出A2A v1.0作为跨智能体互操作性标准，基于HTTP+JSON与JSON-RPC 2.0，并通过SSE支持流式传输。引入Agent Card实现发现优先机制，声明身份、能力、数据模式与认证。将交互建模为有状态的Task，消息由多种Parts(TextPart、FilePart、DataPart)构成，输出为可被下游消费的Artifact。重点评估.NET生态对A2A的采用与实现路径，列举Microsoft Agent Framework、BotSharp(PR 1345)与OpenClaw.NET(PR 90)的具体集成与安全、NativeAOT等优化。文章技术深度高且面向企业实用场景。

一款基于 C# 开发的 Windows 10/11 系统增强工具，精简、优化、定制一站完成！

https://www.cnblogs.com/Can-daydayup/p/20007914

Winhance 是一款基于 C# 的开源 Windows 10/11 系统增强工具。它以图形界面整合应用管理、系统优化、隐私设置、界面定制、常用软件安装、配置导入导出和自定义 ISO 制作等功能。适合新机初始化、系统重装后快速恢复和日常优化维护。核心模块包括软件管理(移除/安装应用、WinGet 支持)、系统优化(隐私、性能、更新、通知等)、界面定制和高级工具(生成 autounattend.xml)。项目托管在 GitHub，并已收录于 C#/.NET 项目精选，便于开发者参考和贡献。

Memgraph 与 Neo4j 图数据库对比及 .NET 生态适配分析

https://www.cnblogs.com/shanyou/p/19976092/neo4jvsmemgraph

文章比较 Memgraph 与 Neo4j 在设计哲学、实现语言、存储模型、事务一致性、索引策略、查询兼容性和 .NET 生态适配上的差异。Neo4j 基于 Java、磁盘优先、采用 Index-Free Adjacency、保持 ACID 强一致并拥有成熟的 .NET 工具链。Memgraph 基于 C++、内存优先、提供亚毫秒延迟和高吞吐、兼容 openCypher 与 Bolt、采用 BSL 许可并提供可选的分析模式以换取吞吐。文章引用实测数据比较内存占用、延迟和持久化差异，并指出对于万级节点的读分析场景优先选 Neo4j，对于实时增量更新和高吞吐写入优先选 Memgraph。

AScript中一个很有意思的语法

https://www.cnblogs.com/rockey627/p/19998021

文章介绍AScript开源C#动态脚本引擎的static语法。解析执行模式下，static语句与普通语句等效；编译执行模式下，static语句在编译期执行并返回结果，static内定义的变量在脚本执行前已计算。通过示例展示static在eval函数中用于预拼接表达式，以及在编译委托中用于初始化配置。最后给出StaticTokenHandler实现片段以说明实现原理。

OpenClaw.NET 外部 CLI 连接器 (External CLI Connectors) 详细技术总结

https://www.cnblogs.com/shanyou/p/20009085

本文介绍 OpenClaw.NET 的 External CLI Connectors，封装官方平台 CLI 为 AI Agent 可控工具。设计默认禁用，不接受自由命令，只允许预配置具名命令。安全采用多层防护：命名命令白名单、风险评分、dry-run 预览、审批流程、脱敏、超时限制和审计日志。Agent 通过指定连接器名、命令名和命名参数调用，运行时将参数展开为 ProcessStartInfo.ArgumentList，不经 Shell。文档列出顶层配置和连接器示例，关键默认值包括 Enabled=false、AllowFreeformCommands=false、RequireApprovalForMutatingCommands=true、RiskLevel=high、ReadOnly=false。

【EF Core】使用自定义的值比较器

https://www.cnblogs.com/tcjiaan/p/20008424

文章讨论 EF Core 的值比较器问题。默认比较器按值比较，但有时不同格式表示同一含义。以 Company.Phone 为例，固话可写成 (010)88988989 或 010-88988989，默认比较器会误判为不同。作者介绍通过继承 ValueComparer 自定义比较器。需要提供三种委托：相等判断、哈希计算与快照创建。示例通过正则解析区号与号码，重写相等与哈希逻辑，快照可用内置实现，从而实现语义相等比较并避免错误的状态变更检测。

我的开源项目分享-基于SharpBrowser二次开发的定制浏览器，过程中填坑无数

https://www.cnblogs.com/rrooyy/p/19995607

为满足仅允许固定电脑登录的安全需求，作者定制浏览器。每个请求头加入设备ID，由服务器校验。项目基于C#开源SharpBrowser。作者发现多个缺陷。包括不支持alert/prompt/confirm、window.open无返回、下载页面日期与排序错误及CEF不支持H.264。作者修正安装脚本路径、内置存储位置、下载日期显示及window.open返回值。作者新增中文界面、打开文件夹功能、公司打印管理器自定义协议、设备ID与设备密钥设置。对不支持H.264的视频，选择上传时自动转换为webm。构建需自行放置ffmpeg.exe于src\bin\net8.0-windows，安装包用Inno Setup并加中文语言包。

【译】Azure MCP 工具现已内置集成至 Visual Studio 2022，无需额外安装扩展

https://www.cnblogs.com/MeteorSeed/p/19979206

文章说明Azure MCP工具已内置于Visual Studio 2022的Azure开发工作负载(自17.14.30起)，无需单独安装扩展。作者指出内置后可避免扩展兼容性问题并随VS统一更新，但Visual Studio 2026独有功能不包含在2022中。Azure MCP通过GitHub Copilot Chat提供覆盖45项Azure服务的230余种工具。示例包括列出订阅中的存储账户、将ASP.NET Core应用通过azd部署到Azure、使用AppLens诊断应用服务和在Log Analytics中运行KQL查询。工具默认禁用，需在IDE中手动启用即可在所有会话中持续使用。

CsGrafeq: 比 Desmos 更“能折腾”的几何函数画板(.NET + Avalonia)

https://www.cnblogs.com/StuLittleLi/p/20005397

CsGrafeq 是一款由高中生开发的跨平台几何草图與隐函数作图工具。它支持点、线、圆等几何构造与拖拽交互，能高质量绘制隐函数 f(x,y)=0 的图像。项目基于 .NET 与 Avalonia，强调即时交互与易用性，适合学习、验证与探索数学问题。作者说明了开发动机、功能场景與跨平台优势，并开源在 GitHub，欢迎 Issue 与 PR。文章实用性与可玩性强，但技术实现细节与引用较少。

【译】TypeScript 7 测试版已在 Visual Studio 2026 18.6 Insiders 3 中默认启用

https://www.cnblogs.com/MeteorSeed/p/19996925

Visual Studio 2026 18.6 预览版3 将内置 TypeScript SDK 升级为 TypeScript 7 Beta 原生预览版。该更新影响使用内置 SDK 的所有项目，包括 TypeScript 项目和使用 npm 的 ASP.NET Core 项目。TypeScript 7 带来原生执行和共享内存并行处理，编译速度最高提升约 10 倍，内存占用显著下降，项目加载和语言服务响应约提升 8 倍。编辑体验的智能感知、查找引用、转到定义和错误诊断均明显加速。若需使用其他版本，可在项目中安装 typescript@^6.0.0 或 @typescript/native-preview@beta，Visual Studio 优先使用本地 node_modules。可在 Tools > Options > Preview Features 中禁用原生预览。文末列出若干正在修复的已知问题。

国际周报

话题

.NET 10.0.7 带外安全更新 - .NET 博客

https://devblogs.microsoft.com/dotnet/dotnet-10-0-7-oob-security-update/

Aspire 13.3 最新动态 | Aspire 博客

https://devblogs.microsoft.com/aspire/whats-new-aspire-13-3/

Windows 应用 SDK 2.0 发布说明 - Windows 应用

https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/release-notes/windows-app-sdk-2-0?pivots=stable

• 发布 Windows 应用 SDK 2.0 (2.0.1) 🎉 · microsoft/WindowsAppSDK^[1]

VSTest 正在移除其 Newtonsoft.Json 依赖 - .NET 博客

https://devblogs.microsoft.com/dotnet/vs-test-is-removing-its-newtonsoft-json-dependency/

Visual Studio 四月更新 – 云代理集成 - Visual Studio 博客

https://devblogs.microsoft.com/visualstudio/visual-studio-april-update-cloud-agent-integration/

Copilot Studio 在 WebAssembly 上运行 .NET 10 加速 - .NET 博客

https://devblogs.microsoft.com/dotnet/copilot-studio-dotnet-10-migration/

欢迎来到SkiaSharp 4.0预览1 - .NET博客

https://devblogs.microsoft.com/dotnet/welcome-to-skia-sharp-40-preview1/

Ubuntu 26.04 中 .NET 的新内容 - .NET 博客

https://devblogs.microsoft.com/dotnet/whats-new-for-dotnet-in-ubuntu-2604/

宣布WinApp VS Code扩展——在VS Code中运行、调试和打包Windows应用 - #ifdef 窗户

https://devblogs.microsoft.com/ifdef-windows/announcing-the-winapp-vs-code-extension-run-debug-and-package-windows-apps-in-vs-code/

宣布WinUI 3图库2.9 - #ifdef Windows

https://devblogs.microsoft.com/ifdef-windows/announcing-winui-3-gallery-2-9/

TypeScript 7 测试版现已默认启用，已在Visual Studio 2026 18.6 Insiders 3 - Visual Studio 博客

https://devblogs.microsoft.com/visualstudio/typescript-7-beta-now-enabled-by-default-in-visual-studio-2026-18-6-insiders-3/

通过代理治理工具包在.NET中管理MCP工具调用 - .NET博客

https://devblogs.microsoft.com/dotnet/governing-mcp-tool-calls-in-dotnet-with-the-agent-governance-toolkit/

SDK 风格的扩展项目支持 - Visual Studio 博客

https://devblogs.microsoft.com/visualstudio/sdk-style-support-for-extension-projects/

发布

• AvaloniaUI/Avalonia^[2]

• 12.0.2^[3]

• aws/aws-sdk-net^[4]

• 4.0.235.0^[5]，4.0.236.0^[6]，4.0.237。 0^[7]， 4.0.238.0^[8]， 4.0.239.0^[9]， 4.0.240.0^[10]， 4.0.241.0^[11]， 4.0.242.0^[12]， 4.0.243.0^[13]， 4.0.244.0^[14]， 4.0.245.0^[15]， 4.0.246.0^[16]

• Azure/azure-cosmos-dotnet-v3^[17]

• 3.59.0^[18]

• Azure/azure-sdk-for-net^[19]

• Azure.AI.Projects_2.0.1^[20]，Azure.Core_1.54.0^[21]，Azure.Core_1.55.0^[22]，Azure.Extensions.AspNetCore.DataProtection.Blobs_1.5. 2^[23]、Azure.Extensions.AspNetCore.DataProtection.Keys_ 1.6.2^[24]，Azure.Monitor.OpenTelemetry.AspNetCore_1.5. 0^[25]，Azure.Monitor.OpenTelemetry.Exporter_1.8。 0^[26]，Azure.ResourceManager.Automanage_1.1。 2^[27]，Azure.ResourceManager.Automation_1.1。 2^[28][Azure.ResourceManager.Billing_1.2.2](https://github.com/Azure/azure-sdk-for-net/releases/tag/Azure.ResourceManager.Billing_1.2.2 年)，Azure.ResourceManager.CarbonOptimization_1.0. 1^[29]，[Azure.ResourceManager.ChangeAnalysis_1.1. 2](https://github.com/Azure/azure-sdk-for-net/releases/tag/Azure.ResourceManager.ChangeAnalysis_1.1.2 年)，Azure.ResourceManager.Chaos_1.1。 1^[30]，Azure.ResourceManager.ComputeLimit_1.0. 0^[31]，Azure.ResourceManager.ConnectedVMwarevSphere_1.1。 2^[32]，Azure.ResourceManager.CostManagement_1.0. 3^[33]，Azure.ResourceManager.CustomerInsights_1.0. 0^[34]，Azure.ResourceManager.DataBox_1.1。 1^[35]，Azure.ResourceManager.DataLakeAnalytics_1.1. 2^[36]，Azure.ResourceManager.DataLakeStore_1.1。 2^[37]，Azure.ResourceManager.DataShare_1.1。 2^[38]，Azure.ResourceManager.DeviceUpdate_1.0. 2^[39]，Azure.ResourceManager.DevOpsInfrastructure_1.0. 0^[40]，Azure.ResourceManager.DevSpaces_1.0. 0^[41]，Azure.ResourceManager.DigitalTwins_1.3。 2^[42]，Azure.ResourceManager.EdgeOrder_1.1. 2^[43]，[Azure.ResourceManager.ExtendedLocations_1.1。 2](https://github.com/Azure/azure-sdk-for-net/releases/tag/Azure.ResourceManager.ExtendedLocations_1.1.2 年)，Azure.ResourceManager.FluidRelay_1.1。 2^[44]，Azure.ResourceManager.GraphServices_1.1。 3^[45]，Azure.ResourceManager.GuestConfiguration_1.2。 2^[46]，Azure.ResourceManager.HardwareSecurityModules_1.0. 1^[47]，Azure.ResourceManager.HealthcareApis_1.3. 2^[48]，Azure.ResourceManager.HealthDataAIServices_1.0。 1^[49]，Azure.ResourceManager.HybridConnectivity_1.1. 1^[50]，Azure.ResourceManager.HybridContainerService_1.0. 2^[51]，Azure.ResourceManager.InformaticaDataManagement_1.0. 0^[52]，Azure.ResourceManager.KubernetesConfiguration_1.2。 1^[53]，Azure.ResourceManager.KubernetesConfiguration.Extensions_1.0.0^[54]，Azure.ResourceManager.LabServices_1.1。 2^[55]，Azure.ResourceManager.LambdaTestHyperExecute_1.0. 1^[56]，Azure.ResourceManager.Logic_1.2。 0^[57]，Azure.ResourceManager.ManagedNetworkFabric_1.1. 3^[58]，Azure.ResourceManager.ManagedServiceIdentities_1.4。 1^[59]Azure.ResourceManager.Marketplace_1.1.3^[60]，Azure.ResourceManager.MarketplaceOrdering_1.1. 2^[61]， [Azure.ResourceManager.MongoDBAtlas_1.0. 1](https://github.com/Azure/azure-sdk-for-net/releases/tag/Azure.ResourceManager.MongoDBAtlas_1.0.1 年)，Azure.ResourceManager.NetApp_1.16。 0^[62]，Azure.ResourceManager.NetworkFunction_1.0. 0^[63]，Azure.ResourceManager.Orbital_1.1. 2^[64]，Azure.ResourceManager.Peering_1.2。 3^[65]，Azure.ResourceManager.PlanetaryComputer_1.0. 0^[66]，Azure.ResourceManager.PostgreSql_1.4。 2^[67]，Azure.ResourceManager.PowerBIDedicated_1.0. 0^[68]，Azure.ResourceManager.PrivateDns_1.2。 2^[69]，Azure.ResourceManager.PureStorageBlock_1.0. 1^[70]，Azure.ResourceManager.RecoveryServicesSiteRecovery_1.3. 1^[71]，Azure.ResourceManager.ScVmm_1.0. 0^[72]，Azure.ResourceManager.Sphere_1.0. 2^[73]，Azure.ResourceManager.StorageActions_1.0. 1^[74]，Azure.ResourceManager.StorageMover_1.4。 0^[75]，Azure.ResourceManager.Subscription_1.1. 2^[76]，Azure.ResourceManager.Synapse_1.2。 2^[77]，Azure.Search.Documents_12.0. 0^[78]，Azure.Security.KeyVault.Administration_4.8。 0^[79]，Azure.Security.KeyVault.Keys_4.10。 0^[80]，Azure.Security.KeyVault.Secrets_4.11。 0^[81]，Microsoft.Extensions.Azure_1.14. 0^[82]， System.ClientModel_1.11.0^[83]

• CommunityToolkit/Maui^[84]

• 14.1.1^[85]

• DataDog/dd-trace-dotnet^[86]

• v3.43.0^[87]

• dotnet/诊断^[88]

• v10.0.721401^[89]

• dotnet/SqlClient^[90]

• v6.1.5^[91]， v7.0.1^[92]

• googleapis/google-cloud-dotnet^[93]

• Google.Cloud.Redis.Cluster.V1-1.7.0^[94]， Google.Shopping.Merchant.Products.V1-1.6.0^[95]， Google.Shopping.Merchant.Reports.V1-1.2.0^[96]

• grpc/grpc-dotnet^[97]

• v2.80.0^[98]

• icsharpcode/ILSpy^[99]

• v10.0.1^[100]

• 微软/Aspire^[101]

• v13.2.3^[102] v13.2.4^[103]， v13.3.0^[104]

• microsoft/WindowsAppSDK^[105]

• v1.8.7^[106]， v2.0.1^[107]

• newrelic/newrelic-dotnet-agent^[108]

• v10.51.0^[109]

• 开放遥测/开放遥测点网^[110]

• core-1.15.3^[111]

• 开放遥测/开放遥测点网贡献^[112]

• Exporter.Instana-1.1.0^[113]， PersistentStorage-1.0。 3^[114]， PersistentStorage-1.1. 0^[115]

• unoplatform/uno^[116]

• 6.5.229^[117]

文章、幻灯片及更多内容

Doco 用到 C# 吗？ 2026

https://zenn.dev/inuinu/articles/where-is-csharp-used-2026

理解 Microsoft 代理框架的 Harness 机制及 LM Studio 和本地大型语言模型的执行流程

https://zenn.dev/yy7613/articles/74265daaf7929a

AI 子代理“即将登陆”Visual Studio Copilot——Visual Studio 杂志

https://visualstudiomagazine.com/articles/2026/05/06/ai-subagents-coming-to-visual-studio-ides-copilot.aspx

Microsoft代理框架中的持久工作流 - .NET 博客

https://devblogs.microsoft.com/dotnet/durable-workflows-in-microsoft-agent-framework/

试试带本地LLM的Microsoft代理框架第13部分(中间件)

https://zenn.dev/yy7613/articles/bb5fa8cdb6bf64

Microsoft代理框架 - AI构建模块第三部分 - .NET博客

https://devblogs.microsoft.com/dotnet/microsoft-agent-framework-building-blocks-for-ai-part-3/

绑定列举

https://zenn.dev/shinta0806/articles/enum-binding

用 Blazor WebAssembly 制作的工程师诊断应用 - 本地化、通用协议和 cookie 同意

https://zenn.dev/nekojoker/articles/c9f17b69690031

[C#] CSharpier 推荐

https://zenn.dev/nuskey/articles/csharpier-is-good

ASP.NET 生产中核心 Cookie 大小限制：原因与修复

https://duendesoftware.com/blog/20260429-aspnet-core-cookie-size-limits

渴望WPF界面，最终回归.NET MAUI Blazor Hybrid - Qiita的故事

https://qiita.com/maki_s/items/527469f0ff9fa94cefb2

. 如何在 .NET - Qiita 中使用 OpenAI API

https://qiita.com/qOpenDev/items/fc3ca29355956c1d0381

. 如何通过API将.NET包上传到NuGet

https://zenn.dev/loach/articles/upload-nuget

解释SQL和LINQ中的范畴论 - Qiita

https://qiita.com/yaju/items/38a283f4b1fba434f620

[Blazor + Syncfusion] 我在实现以SfGrid为中心的商业应用列表界面后——Qiita的感受

https://qiita.com/af-dev-hub/items/79eb00a4306a01a2a12f

[树莓派5] 从Antigravity远程SSH连接开发C#

https://zenn.dev/minenote/articles/2c93232bab8b61

现金策略深度比较专注于懒惰现金 - Qiita

https://qiita.com/Mitsuki0003/items/260d0f64cdc580de181c

用.NET代码生成模板尝试的多个代理开发循环

https://zenn.dev/tomokusaba/articles/14f2373c51e1f2

在.NET中评估CRON和RRule表达式 - Gérald Barré

https://www.meziantou.net/evaluating-cron-and-rrule-expressions-in-dotnet.htm

在C#中用Facet .NET：.NET的TypeScript工具类型

https://tim-maes.com/blog/2026/04/17/pick-and-omit-in-csharp-with-facet/

.NET 11 预览版3 基于文件的应用文件拆分

https://zenn.dev/prozolic/articles/a861cc1da6b0e1

让我们读ZString (4) 缓冲区 - Qiita

https://qiita.com/kuto110/items/75c0336a25c6d0afd1af

System.CommandLine 稳定版发布 - Qiita

https://qiita.com/KM_20005/items/94d1db2f49c7436d598b

C#：自动将只调用一次的动作集中

https://zenn.dev/ruccho/articles/csharp-pooled-actions

构建一个由 . NET的可组合AI协议栈——.NET博客

https://devblogs.microsoft.com/dotnet/building-ai-conference-app-dotnet-composable-stack/

试试带本地LLM的Microsoft代理框架第12部分(结构化输出)

https://zenn.dev/yy7613/articles/27d7ed3c97ff1a

联盟类型性能比较：非拳击定制联盟 [C#15预览]

https://zenn.dev/inuinu/articles/csharp-union-performance

尝试带本地LLM的Microsoft代理框架第11部分(带AIContextProvider的简化RAG)

https://zenn.dev/yy7613/articles/d5b22b11d40fca

Azure 上 .NET 和 Postgres 的高性能分布式缓存 - .NET 博客

https://devblogs.microsoft.com/dotnet/high-performance-distributed-caching-dotnet-postgres-azure/

尝试用 Windows Forms 做 MVVM，结果却陷入自满，且。 NET 10 可以写出这样的故事——Qiita

https://qiita.com/inuta-one/items/4cb48340bdfe32b15592

在.NET 10应用中结合API版本管理与OpenAPI - .NET博客

https://devblogs.microsoft.com/dotnet/api-versioning-in-dotnet-10-applications/

你目前使用的GitHub Copilot CLI + .NET的自定义代理和技能

https://zenn.dev/microsoft/articles/github-copilot-dotnet-project

Entra 验证ID发行实现：含.NET样本的数字ID API

https://zenn.dev/kumaik/articles/entra-verified-id-dotnet-issuance

Windows 应用开发 CLI v0.3：新增运行命令和界面命令，以及对打包应用的 dotnet run 支持 - #ifdef 窗户

https://devblogs.microsoft.com/ifdef-windows/windows-app-development-cli-v0-3-new-run-and-ui-commands-plus-dotnet-run-support-for-packaged-apps/

首次使用Claude Design重新设计了Blazor应用的默认界面 - Qita

https://qiita.com/non-k/items/bcc3cf14e072b74ae730

[C#] 深入思考例外与日志：第一部分例外类的完整解剖——Qiita。

https://qiita.com/KM_20005/items/eab8ab1db5ab28d9164e

[C#] 关于C#开发工具包生成的.lscache文件

https://zenn.dev/nuskey/articles/csharp-lscache

使用 GitHub Copilot CLI 和 VS Code 代理模式供 C# 开发者使用

https://zenn.dev/tomokusaba/articles/838cdac8d71e52

使用 ReadOnlySpanT 移除 .NET Framework 中的字节[] 分配

https://andrewlock.net/removingbyte-array-allocations-in-dotnet-framework-using-readonlyspan-t/

如何在不继承 Microsoft 365 Agents SDK 的 AgentApplication 类的情况下编写

https://zenn.dev/karamem0/articles/2026_04_21_090000

mruby 在 C# 上：从虚拟机实现到游戏脚本(RubyKaigi 2026)

https://speakerdeck.com/hadashia/mruby-on-c-number-from-vm-implementation-to-game-scripting

库、仓库、工具等

r-dev95/OpRec

https://github.com/r-dev95/OpRec

• 开发了Windows屏幕录制应用OpRec^[118]

ulex/windows_defender_performance_tool：实时Windows Defender扫描性能监控器

https://github.com/ulex/windows_defender_performance_tool

akeit0/Enaga：用于直接渲染html/css(及浏览器)或ReactNative的实验性C#项目。

https://github.com/akeit0/Enaga

• 我用C#创建了自己的JavaScriptEngine + 浏览器^[119]

Windows Server 2025安装指南新手必看！

Fri, 10 Jul 2026 09:32:06 +0800

在工作中，我们可能涉及到部署Windows Server服务器环境。本篇文章，将为你详细讲解。

创建虚拟机

本文以VM为例，创建虚拟机。

选择镜像

引导方式为Bios

CPU和内存大小可以根据自己电脑的性能调整，完成后启动虚拟机。

系统安装

接下来，接入安装界面。和安装Windows系统一样，很丝滑！

至此，虚拟机安装Windows Server教程到此结束了。需要部署什么业务，可以自行部署了。

一文讲透 .NET 中的 AOP：什么是面向切面编程？原理是什么？

Fri, 10 Jul 2026 09:27:16 +0800

AOP

什么是AOP

AOP (Aspect-Oriented Programing ，面向切面编程)是一种编程模式(思想)，它的核心目的是将"横切关注点(Cross-Cutting Concerns)" 从核心业务逻辑中分离出来

什么是"横切关注点"
在软件开发中，有些逻辑与业务逻辑无关，但却分散在系统的各个角落。比如：日志记录、权限校验、事务管理、异常处理等。

传统的OOP(面向对象)的痛点：如果你要在10个业务方法中加上日志，你就得在这10个方法里都写一遍日志代码。这导致了严重的代码重复和高耦合。如果以后想改变日志格式，你需要修改19个地方
AOP 的解决思路：将这些散落的、重复的逻辑抽取出来，封装成一个独立的模块(称为**“切面Aspect”**)。然后在运行时，由框架自动将这些逻辑"织入(Weave)"到目标方法中。

AOP的核心术语

Before(前置)：目标方法执行前
After(后置)：目标方法执行后(无论是否成功)
AfterReturning(返回后)：目标方法执行成功返回后
AfterThrowing(异常后)：目标方法执行异常返回后
Around(环绕)：最强大的通知，包裹目标方法，可以控制是否执行目标方法，修改参数和返回值。

切面(Aspect)：横切关注点的模块化封装(例如一个日志处理类)
连接点(Join Point)：程序执行过程中的某个特定位置，通常是方法的调用或者异常的抛出
切入点(Pointcut)：定义切面到底要“织入”到哪些连接点上(例如：匹配所有以service结尾的类的方法)
通知(Advice)：切面在特定连接点上执行具体动作，分为：

AOP 实现原理

AOP的本质是动态代理。它在不修改源码的情况下，在内存中为目标方法生成一个“代理对象"。当调用该方法时，实际上是调用了代理对象的方法，代理对象会在调用真实的方法前后插入切面逻辑。

在.NET生态中，AOP 的实现原理主要分为以下几种流派：

运行时动态代理(runtime dynamic Proxy)
这是.NET中最主流的AOP 实现方法如(Castle.Core、AspnetCore、ABP等框架都基于此)

开发者在DI(依赖注入)容器中注册服务，指定需要AOP拦截
DI容器在解析服务时，不直接实例化真实类，而是调用Castle等库生成代理类
外部调用方法时，触发代理类的Intercept(IInvcation invcation)方法
在Intercept中执行前置逻辑->调用invcation.Proceed()执行真实的方法->执行后置逻辑。

基于接口代理(Interface-based)：如果目标类实现了接口，代理类会继承该接口，并在内部持有一个真实对象的引用。在调用接口方法时，代理类先执行拦截器(Interceptor)，再调用真实的对象方法
基于类继承代理(Class-based)：如果目标类没有接口，代理类会继承目标类。注意，这种方式要求目标类必须是virtual(虚方法)，因为代理类是通过override 虚方法来插入逻辑的。

原理：利用.NET的反射和System.Reflection.Emit命名空间，在程序运行时动态生成一个新的类(代理类)
两种代理模式：
工作流程：

编译时/构建时织入(Compile-time/Build-time Weaving)
这种方式在代码编译阶段就修改了IL(中间语言)代码。

原理：利用Mono.Cecil或Roslyn等工具，在编译后读取DLL，直接在IL代码中注入切面逻辑，然后重新保存DLL
代表工具：Fody (如 PropertyChanged.Fody, MethodTimer.Fody)。
特点：没有运行时动态生成代理类的开销，性能极高；但调试相对困难，因为生成的代码在源码中看不到

.NET官方原生方案：Source Generators（源码生成器）
随着C# 9.0引入了source Generators,这是目前.NET社区最推崇的现代AOP 实现方式(如Razor、Blazor底层都在用。)

原理：在编译阶段，编译器将源码解析成语法树(Syntax Tree)，Source Generator 分析语法树，动态生成额外的C#代码文件，并将他们一起编译
代表工具：AspectInjector、Meziantou.Framework。
特点：性能等同于手写代码(因为在编译期生成了真实代码)，完全支持IDE智能提示和调试，且不需要依赖第三方动态代理库

声明式/框架级AOP(如：Asp.NET Core Filters)
在ASP.NET Core 中Fliters 也是一种AOP，但它不是通过代理来实现的，而是通过管道模式来实现的。

原理：MVC框架在内部维护了一个过滤器列表，当HTTP请求进入时，框架按照顺序执行过滤器链，最后才执行Controller中的Action。它只作用于Web层的特定生命周期。

总结

AOP是思想：把重复、非业务的逻辑抽离出来，统一处理
动态代理是手段，在.NET中，绝大多数AOP框架(如Castle)都是通过运行时设工程子类或者接口实现类来拦截方法调用的
现代趋势：.NET开发者正逐渐从传统的运行时动态代理(castle)向编译时源码生成(Source Generators)迁移，以获取更好的性能和开发体验。

[开源]一套开源企业级在线文档编辑与免费协作解决方案，永久开源 · 可私有部署 · 可二次开发

Thu, 09 Jul 2026 22:10:52 +0800

一、开源项目简介

VerveDocs - 玉衡云文档

一套基于 Vue 3 + TypeScript 的企业级在线文档编辑解决方案，支持 Word、Excel、PPT 等多种文档格式的在线编辑与协作。

二、开源协议

使用MIT开源协议

三、界面展示

四、功能概述

在线文档编辑与免费协作产品

永久开源 · 可私有部署 · 可二次开发

VerveDocs 是一套开源在线文档编辑与协作解决方案；提供开箱即用的在线文档编辑器（兼容 Word）、轻量版文档编辑器、在线电子表格编辑器（兼容 Excel）和在线演示文稿编辑器（兼容 PowerPoint）。

在线文档

在线文档编辑器(兼容Microsoft Word格式)

轻量版 Lite

轻量级在线文档编辑器(兼容Microsoft Word格式)

在线表格

在线电子表格编辑器，(兼容Microsoft Excel格式)

在线演示

在线演示文稿编辑器(兼容Microsoft PowerPoint格式)

特性

多格式支持：Word 文档、Excel 表格、PPT 演示文稿
富文本编辑：文本格式化、表格、图片、列表、页眉页脚、水印等
实时协作：多人在线协同编辑
插件系统：可扩展的功能插件机制
TypeScript 支持：完整的类型定义
响应式设计：适配多种屏幕尺寸

核心引擎能力

分页模式

分页渲染与纸张设置,支持缩放、边距、页眉页脚与页码。

文本编辑

字体、字号、加粗/斜体/下划线、颜色、高亮、标题与列表。

表格与图片

插入/删除行列、合并拆分单元格,图片浮动/环绕与导出。

控件与表单

文本框、选择、日期、复选/单选等控件,支持取值与批量赋值。

事件与监听

通过 eventBus 订阅内容变化、选区样式、鼠标事件、保存等事件。

插件扩展

提供 use(plugin) 扩展能力,可注入图表渲染器等高级功能。

为什么选择开源?

自主可控

核心能力完全开源,支持内网部署,便于安全审计与深度定制。

工程化 API

面向二次开发的 API 文档与类型定义,便于在复杂业务中落地。

五、技术选型

技术栈

Vue 3 - 渐进式 JavaScript 框架
TypeScript - JavaScript 的超集
Element Plus - Vue 3 UI 组件库
ECharts - 数据可视化图表库
Vite - 下一代前端构建工具
docx - Word 文档生成库
exceljs - Excel 文件处理库
pptxgenjs - PPT 生成库

项目结构

模块介绍

@vervedoc/core

核心编辑器库，提供基础的富文本编辑功能。

npm install @vervedoc/core

主要功能：

富文本编辑（加粗、斜体、下划线、删除线、高亮等）
表格操作（插入、合并、拆分、边框设置）
图片处理（插入、缩放、拖拽）
列表功能（有序、无序、多级列表）
页面布局（页眉、页脚、页码、水印、页边距）
控件系统（文本控件、日期控件、下拉选择）
历史记录（撤销/重做）
搜索替换

@vervedoc/docx

Word 文档编辑器完整版，提供完整的 UI 界面和交互。

npm install @vervedoc/docx

@vervedoc/excel

Excel 表格编辑器，支持电子表格的在线编辑。

npm install @vervedoc/excel

@vervedoc/ppt

PPT 演示文稿编辑器，支持幻灯片的在线制作。

npm install @vervedoc/ppt

快速开始

安装依赖

开发指南

环境要求

Node.js >= 16.0.0
npm >= 7.0.0

本地开发

构建所有模块

浏览器兼容性

Chrome 80+
Firefox 75+
Safari 13.1+
Edge 80+

六、源码地址

开源项目地址：

https://gitee.com/wanghe520/vervedocs

访问一飞开源：https://code.exmay.com/

TypeScript 7.0 发布：用 Go 重写的原生编译器，快 10 倍

Thu, 09 Jul 2026 09:41:57 +0800

TypeScript 7.0 正式发布了，这是一个用 Go 重写的原生版本。官方给出的数字是：完整构建普遍快 8 到 12 倍。这不是又一个加几个类型特性的小版本，而是把整个工具链从 TypeScript 自举实现换成原生编译代码的一次大改造，团队为此投入了一年多。

如果你在大型代码库上被 tsc 或编辑器的卡顿折磨过，这个版本值得认真看一下。这篇讲清楚它到底快在哪、怎么装、和现有 6.0 怎么并存、有哪些会咬人的默认变更，以及哪些场景现在还不能用。

快是怎么来的

去年 TypeScript 团队公布过原生移植计划：用 Go 重写一个能吃满现代硬件的原生编译器。移植做得尽量忠实——在保持原代码库结构和逻辑的前提下写新代码，好让两个编译器结果一致、行为兼容。区别在于新代码库带来了原生代码速度、共享内存多线程，以及一批新优化，在完整构建上通常能拿到 8-12 倍的提速。

安装方式和往常一样，通过 npm：

npm install -D typescript

这会给你工作区里新的 tsc 可执行文件（用 npx tsc 运行）。编辑器支持也一起跟上了，新基础建立在语言服务器协议（LSP）之上，VS Code、Visual Studio、WebStorm 等现代编辑器都能用。VS Code 有一个专门的 TypeScript 7 扩展现在就能装，Visual Studio 会根据工作区自动启用。

快了之后实际是什么体验

纸面上快听着好，落到日常是什么感觉？想想 TypeScript 在开发每个环节里出现的地方：打开编辑器、打开一个 TS 文件、跨项目跑一次 find-all-references；开始改代码时期待自动补全弹出、改错了实时看到红波浪线；准备构建时跑 tsc 看有没有报错，再运行生成的代码。

TypeScript 变快意味着上面每一步都被理顺。等编辑器加载完整个项目会感觉近乎瞬时；find-all-references、自动补全、诊断的延迟只剩过去的零头；跑 tsc（尤其是 --watch 模式）时反馈循环收得更紧，迭代比以前快得多。

在真实项目上能直接看到这个差距。下面是几个较大的开源代码库在 TypeScript 6 和 7 上的构建时间：

代码库	TypeScript 6	TypeScript 7	提速
vscode	125.7s	10.6s	11.9x
sentry	139.8s	15.7s	8.9x
bluesky	24.3s	2.8s	8.7x
playwright	12.8s	1.47s	8.7x
tldraw	11.2s	1.46s	7.7x

内存占用同样更省，同一批项目在整个构建过程里的聚合内存下降了 6% 到 26%：

代码库	TypeScript 6	TypeScript 7	内存变化
vscode	5.2GB	4.2GB	-18%
sentry	4.9GB	4.6GB	-6%
bluesky	1.8GB	1.3GB	-26%
playwright	1.0GB	0.9GB	-11%
tldraw	0.6GB	0.5GB	-15%

编辑器里的体验不止完整构建这一项。同一台机器上，在 VS Code 代码库里打开一个有错的文件，从打开编辑器到看到第一个错误，以前要约 17.5 秒，TypeScript 7 下不到 1.3 秒，快了 13 倍以上。

已经在生产里验证过

TypeScript 项目十多年积累了数万个测试，每次 main 分支提交都跑。但 7.0 不是普通版本，团队在测试套件之外还动用了很多资源确认它能上生产。

过去一年，团队和许多内部及外部大团队一起在真实代码库上测 TypeScript 7，反馈压倒性地正面。微软的 Loop、Office、PowerBI、Teams、Xbox 等团队参与了超大代码库的验证；Bloomberg、Canva、Figma、Google、Linear、Miro、Notion、Sentry、Slack、Vercel 等公司也在自己代码库上测过并给了反馈。

数据上也能看出质量变化：TypeScript 7.0 的新语言服务器把失败的语言服务命令减少了 80% 以上，服务器崩溃减少了 60% 以上（相较 6.0）。一些规模化团队的反馈很直接：

• Slack 工程师说 TypeScript 7 砍掉了他们 40% 的合并队列时间，CI 里的类型检查从约 7.5 分钟降到 1.25 分钟。本地编辑器体验以前因为语言服务器加载慢几乎"不可用"，现在几秒就能加载同一个代码库，本地类型检查重新变得可行。

• Vanta 的构建在他们最大的项目之一上提速最高 9 倍。

• 微软 News Services 团队说采用 TypeScript 7 每月省下 400 小时的 CI 构建等待。

• Canva 说语言服务从约 58 秒看到第一个错误降到约 4.8 秒。

和 TypeScript 6.0 并存运行

TypeScript 7.0 目前不带 API。7.1 预计会带一个新的（且不同的）API，但在那之前，团队优先保证 7.0 能和 6.0 并存，供那些仍需要编程式访问编译器的工具使用（比如 typescript-eslint）。

为此他们发布了兼容包 @typescript/typescript6，它提供一个叫 tsc6 的可执行文件，让你能在没有命名冲突的情况下并存安装。这个包还重新导出了 6.0 的 API，于是你可以让 tsc 用 7.0，其他工具继续依赖 6.0。

因为像 typescript-eslint 这类工具期望直接从 typescript 导入，推荐用 npm 别名实现。可以跑：

npm install -D typescript@npm:@typescript/typescript6

或者改 package.json：

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.2",
  }
}

注意这样做只会给你 tsc6 可执行文件。想同时拿到 7.0 的 tsc，再加一个 TypeScript 7 的别名，npx tsc 就会走 7.0：

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

另外，此前大多数人是通过 @typescript/native-preview 装 TypeScript 7 的（每周下载超 850 万次）。之后每日构建会回归标准 typescript 包的 next 标签，用 npm install -D typescript@next 即可。

并行控制：checkers 和 builders

TypeScript 7.0 现在把很多步骤并行执行，包括解析、类型检查和输出。解析和输出这类步骤在文件间基本独立，所以并行能随代码库变大自动扩展，开销很小。但不是每一步都好并行。

TypeScript 7 引入了实验性的 --checkers 和 --builders 两个标志，用来微调类型检查、项目引用构建这类不那么好并行的步骤。还有一个 --singleThreaded 标志可以完全关闭并行，用于调试或资源受限的环境。

类型检查并行

类型检查在文件间的依赖更复杂：多数文件依赖同一批来自依赖项和全局作用域的类型信息，完全独立地跑检查器会浪费计算和内存。另一方面类型检查偶尔依赖程序内信息的相对顺序，所以从头检查必须每次以相同顺序检查相同文件，才能保证结果一致。

为了兼顾并行和一致性，7.0 创建固定数量、各自持有一份世界视图的类型检查 worker。它们可能重复一些公共工作，但对同样的输入文件，永远以相同方式划分并产出相同结果。

默认 4 个 worker，可用 --checkers 调。在核数更多的机器上加大这个数能进一步提速，但通常以更高内存为代价。前面表格用的是默认 --checkers 4；换成 --checkers 8 同一机器上：

代码库	TypeScript 6	TypeScript 7 (`--checkers 8`)	提速
vscode	125.7s	7.51s	16.7x
sentry	139.8s	12.08s	11.6x
bluesky	24.3s	2.01s	12.1x
playwright	12.8s	1.16s	11x
tldraw	11.2s	1.06s	10.6x

反过来，在核少内存小的机器（比如 CI runner）上，你可能想调低以避免额外开销，最低可设 --checkers 1，等于把类型检查变单线程、消除重复工作。少数情况下改 checkers 数量会暴露顺序相关的结果差异，跨环境固定一个数值能保证大家结果一致。

项目引用构建并行

7.0 不仅能在单个项目内并行，还能同时构建多个项目，用 --builders 标志控制 --build 下同时运行的并行项目引用构建器数量，对多项目 monorepo 特别有用。

和 --checkers 一样，加大 builders 能提速但更耗内存，而且它和 --checkers 是乘积关系——--checkers 4 --builders 4 允许最多 16 个类型检查器同时跑，可能过头。不同于 checkers，改 builders 数量不会产生不同结果，但项目引用构建本质上受项目依赖图瓶颈限制。

单线程模式

某些情况下强制整个编译器单线程会有用：调试、对比 6 和 7 的性能、外部编排并行构建，或在资源极受限的环境跑。--singleThreaded 标志不仅把类型检查 worker 限为 1，还确保解析和输出也在单线程里完成。

重建的 --watch 模式

TypeScript 7 带了一个彻底重建的 --watch 模式，底层基于 Parcel 打包器的文件监听器，提供高效稳定的跨平台文件监听。

团队移植监听逻辑时遇到过几个坑：Go 标准库没有内置文件监听 API，试过的第三方库在稳定性、性能、跨平台或构建工具集成上各有问题。纯轮询方案能广泛跑起来但计算太贵，尤其是 node_modules 依赖多的大项目。而 Parcel 的监听器虽然好用，却是 C++ 写的、需要完整 C++ 工具链。他们最后把它移植成 Go（加了几个最小的汇编垫片），从直译逐步打磨成能通过移植测试套件的地道 Go 代码，跨平台的资源占用显著改善。

从 5.x 到 6.0 再到 7.0 的行为变更

TypeScript 7.0 在类型检查和命令行行为上兼容 6.0。基本上任何在 6.0 下（开着 stableTypeOrdering、没设 ignoreDeprecations）能干净编译的代码，在 7.0 下应该编译结果一致。

但 7.0 采用了 6.0 的新默认值，并对 6.0 里废弃的标志和写法直接报硬错误。由于 6.0 还比较新，很多项目需要适配这些新行为。建议先采用 6.0 来平滑过渡。默认配置的显著变化有：

• strict 默认 true

• module 默认 esnext

• target 默认为紧邻 esnext 之前的当前稳定 ECMAScript 版本

• noUncheckedSideEffectImports 默认 true

• libReplacement 默认 false

• stableTypeOrdering 默认 true 且不能关

• rootDir 现在默认 ./，内层源目录必须显式设置

• types 现在默认 []，想恢复旧行为设成 ["*"]

rootDir 和 types 的变化最可能让人意外，但都好处理。tsconfig.json 在 src 之类目录外的项目，加上 rootDir 就能保持原目录结构：

  {
      "compilerOptions": {
          // ...
+         "rootDir": "./src"
      },
      "include": ["./src"]
  }

依赖特定全局声明的项目要显式列出它们：

  {
      "compilerOptions": {
          // 显式列出你需要的 @types 包（如 bun、mocha、jasmine 等）
+         "types": ["node", "jest"]
      }
  }

变成硬错误、行为置空的废弃项包括：不再支持 target: es5、downlevelIteration、moduleResolution: node/node10（改用 nodenext 或 bundler）、module: amd/umd/systemjs/none、baseUrl、moduleResolution: classic；esModuleInterop 和 allowSyntheticDefaultImports 不能设为 false；alwaysStrict 视为 true 不能关；namespace 声明里不能用 module 关键字；import 上不能用 asserts，要改用 with 关键字。

模板字面量类型现在保留 Unicode 码点

7.0 在从模板字面量类型推断时更自然地处理 Unicode 码点：

type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;

type Result = HeadTail<"😀abc">;
//   ^
// 7.0 里：["😀", "abc"]
// 以前：["\ud83d", "\ude00abc"]

以前 TypeScript 跟随 JavaScript 的 UTF-16 索引行为，把 "😀" 拆成代理对的两半。技术上和 JS 索引一致，但通常不是人们想要的，还会产生含不成对代理项、语义无意义的字符串字面量类型。对那些刻意建模 UTF-16 码元的类型级字符串工具（比如某些 Length 工具），这是破坏性变更。新行为更接近用 for...of 遍历或 [...str] 展开时的直觉——"😀" 被当成一个单位。

JavaScript 支持的差异

移植时团队顺带重做了 JavaScript 支持，让它和 .ts 文件的分析方式更一致。一些差异：值不能用在期望类型的地方，改写 typeof someValue；@enum 不再被特殊识别；单独的 ? 不再能当类型用，改用 any；@class 不再让函数变构造器，改用 class 声明；不支持后缀 !；类型名必须定义在 @typedef 标签里；不再支持 Closure 风格函数语法。更详细的 6.0 到 7.0 差异记录在项目的 CHANGES.md 里。

暂时还不能用的场景

有一点要特别说清楚：用 Vue、MDX、Astro、Svelte 的工作流，以及 Angular 里模板内的专门类型检查，暂时还不能用 TypeScript 7。原因是 7.0 还没暴露稳定的编程式 API，那些把 TypeScript 嵌进自己编译器和语言服务的工具（比如 Volar）目前只能依赖 6.0。团队说这是一个阶段性问题，会主动和这些项目的维护者合作解决。

在那之前的建议：Angular 项目可以用 TypeScript 7 通过 tsc 在命令行做快速的全项目错误检测，编辑器仍用 6.0；用 Vue、MDX、Astro、Svelte 的项目暂时继续用 6.0。VS Code 里跑一下"Disable TypeScript 7 Language Server"命令就能回到 6.0。

往后怎么走

7.0 是 TypeScript 项目的一个大里程碑。这次移植是团队一年多的主要工作，7.0 出了之后，团队会回到新功能、易用性改进、更多性能优化，以及为整个生态实现新 API。发布节奏预计和 7.0 之前类似，每 3-4 个月一个有新特性的版本。7.1 已经在路上，会补上生态里的空缺。

如果你手上有被类型检查拖慢的大型 TS 项目，这个版本值得尽早在非嵌入式语言的场景里试。先把 6.0 的默认变更适配好，迁移到 7.0 会顺很多。

码栈工坊_源代码分享,技术文章,精品素材,网站模板,网站源码,建站源码,模板下载

委托的五个基本使用步骤

委托的五个基本使用步骤

1. 委托使用流程

2. 第一步：声明委托类型

3. 第二步：编写匹配方法

4. 第三步：创建委托变量

5. 第四步：关联委托方法

使用 = 赋值

使用 += 添加

使用 -= 移除

6. 第五步：调用委托

7. 完整工控示例

8. 关联实例方法

9. 多播委托注意事项

10. WinForms 事件中的委托

11. 常见错误

12. 小结

写给 .NET Core 开发者的 AI Prompt 工程：把需求说成可生成的代码

差的 Prompt 为什么差

好的 Prompt 要先给上下文

把架构规则写进 Prompt

让 AI 输出可编译的 C# 代码

明确错误处理策略

验收条件要可执行

Prompt 也是团队工程资产

Windows .NET生产环境高可用：NLB的工程价值与边界

NLB 是什么

怎么引入

PowerShell脚本接入方式（适合批量自动化部署）

快速上手

示例1：最小可用接入——两台IIS服务器构成NLB集群

示例2：典型业务场景——ASP.NET Core应用+NLB + Redis共享Session

示例3：典型业务场景——HTTPS站点（NLB四层透传）

示例4：进阶能力——通过PowerShell脚本实现自动化节点上下线

实战常见报错

适用场景

实战建议

高频坑位1：单播模式导致交换机洪泛

高频坑位2：应用挂了但节点还在集群里

高频坑位3：跨Windows Server版本的节点混用

其他建议

选型建议

总结收尾

前端又一个 “全家桶” 出现了！

文件预览最难的地方，是失控

一套 Core，支持四种技术栈

插件系统才是核心

doc / xls 支持，才是真正进入业务系统

四种技术栈，接入方式保持一致

原生 JavaScript

Vue

React

Svelte

真正难做的，还有失败状态

Office 高保真预览，必须保留服务端路线

官网已经可以在线体验

完全免费开源，求个 Star

一套覆盖8大业务场景的 .NET 企业级快速开发框架

01 项目背景与定位

02 已落地产品矩阵

03 核心特性全景

🔐 认证与安全

⚙️ 系统与框架

💼 业务能力

🌐 平台兼容

04 技术栈深度解析

后端核心依赖

前端技术栈（Scm.Vue）

05 架构设计与项目结构

模块化拆分策略

动态 API 机制

三层分离

06 四大设计原则

07 五分钟快速启动

Step 1：获取代码

Step 2：配置数据库

Step 3：启动后端

Step 4：启动前端

演示账号

使用 `=` 赋值

使用 `+=` 添加

使用 `-=` 移除

记一次 .NET 某智慧工厂视觉程序崩溃分析

Microsoft代理框架 - AI构建模块第三部分 - .NET博客

现金策略深度比较专注于懒惰现金 - Qiita