C#开发工程师-面经

1.SQLSugar和Entity FrameWork Core框架的区别和适用场景

SQLSugar 和 Entity Framework Core (EF Core) 是 .NET 生态中两款主流的 ORM（对象关系映射）框架，它们在设计理念、功能特性及适用场景方面存在显著差异。

一、开发背景与定位

‌Entity Framework Core‌ 是由微软官方开发的全功能 ORM 框架，强调领域驱动设计（DDD）和对象关系映射的完整性，适用于大型复杂业务系统。
‌SqlSugar‌ 则是由国内开发者开发的轻量级高性能 ORM，注重简洁易用、高性能和灵活控制，适合中小型项目和快速开发。

二、核心设计理念

‌EF Core‌ 以"领域模型"为核心，鼓励开发者面向对象编程而非直接编写 SQL，通过 LINQ 表达式描述查询逻辑，屏蔽 SQL 细节，适用于需要严格实体关系管理和数据库迁移的场景。
‌SqlSugar‌ 更加贴近 SQL 编程，支持原生 SQL 执行并映射到实体，提供灵活的查询语法和高性能操作，尤其在批量操作和复杂查询上有优势。

三、适用场景对比

表格

场景	Entity Framework Core	SqlSugar
大型复杂业务系统（如电商、ERP）	✅ 适合，支持 DDD 架构和数据库迁移	❌ 不太适合，性能较低
快速原型开发	❌ 配置繁琐，迁移较复杂	✅ 适合，易于上手
对性能要求极高的场景	❌ ORM 层抽象较多，生成 SQL 可能不够优化	✅ 优势明显，性能优于 EF Core
需要灵活 SQL 控制	❌ LINQ 限制较多	✅ 支持原生 SQL 和复杂查询
多数据库支持	✅ 支持主流数据库	✅ 支持多种数据库（包括国产数据库）
批量操作	❌ 性能较差（需 AddRange + SaveChanges）	✅ 性能优秀，支持真实批量插入

四、功能与性能对比

‌性能方面‌：SqlSugar 在单条插入、批量插入和复杂查询等场景下通常优于 EF Core，尤其在处理大量数据时表现更佳。
‌功能方面‌：EF Core 功能更为全面，具备强大的迁移机制、导航属性、事务管理等功能；而 SqlSugar 在简单到中等复杂度的操作中表现出色，同时支持分表分库、全局过滤器等高级特性。

五、总结

‌Entity Framework Core‌ 更适合大型企业级应用，尤其是那些依赖 DDD 架构、需要强类型支持和复杂实体关系管理的项目。
‌SqlSugar‌ 更适合中小型项目、后台管理系统或 API 开发，特别是对性能有较高要求且希望保留 SQL 控制权的场景。

2.List<int > a = (1,2,3...,100);C#语法使用原生拉姆达表达式写法，筛选出包含9的，并且结果拼接上a，输出结果为List<string> b = (a9,a19,a29,...a99)

cs 复制代码

using System;
using System.Collections.Generic;
using System.Linq;

class Program
{
    static void Main()
    {
        // 创建List<int> a = (1,2,3,...,100)
        List<int> a = Enumerable.Range(1, 100).ToList();

        // 使用拉姆达表达式筛选出包含9的数字，并拼接成字符串列表
        List<string> b = a
            .Where(x => x.ToString().Contains('9'))  // 筛选包含9的数字
            .Select(x => $"a{x}")                    // 拼接为 "a9", "a19", ...
            .ToList();

        // 输出结果
        Console.WriteLine(string.Join(",", b));
    }
}

3.C# 跨域怎么写，写到哪里，原理是什么？

在 C# 中处理跨域（CORS）问题的核心在于后端配置响应头，特别是 Access-Control-Allow-Origin。以下是详细的实现方法和原理说明：

一、CORS 原理

跨域问题源于浏览器的‌同源策略‌，该策略限制了不同源（协议、域名、端口）之间的资源访问。CORS（跨域资源共享）通过在 HTTP 响应头中添加特定字段来告知浏览器哪些源可以访问资源。关键响应头包括：

Access-Control-Allow-Origin：指定允许访问资源的源。
Access-Control-Allow-Methods：允许的 HTTP 方法。
Access-Control-Allow-Headers：允许的请求头。

二、C# 中实现 CORS 的方式

1. ASP.NET Core 中配置 CORS

在 ASP.NET Core 项目中，通常在 Program.cs 或 Startup.cs 中进行配置。以下是 Program.cs 的写法：

cs 复制代码

var builder = WebApplication.CreateBuilder(args);

// 添加 CORS 服务
builder.Services.AddCors(options =>
{
    options.AddPolicy("AllowSpecificOrigins", policy =>
    {
        policy.WithOrigins("http://localhost:3000", "https://yourdomain.com")
              .AllowAnyHeader()
              .AllowAnyMethod()
              .AllowCredentials(); // 若需携带 cookie 或认证信息
    });
});

var app = builder.Build();

// 启用 CORS 中间件（必须在 UseAuthorization 之前）
app.UseCors("AllowSpecificOrigins");

app.UseAuthorization();
app.MapControllers();

app.Run();

2. ASP.NET Web API（非 Core）中的配置

在传统的 ASP.NET Web API 中，可以通过以下方式配置：

在 WebApiConfig.cs 中添加 CORS 策略：

cs 复制代码

public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        // 启用 CORS
        config.EnableCors(new EnableCorsAttribute(
            origins: "http://localhost:3000",
            headers: "*",
            methods: "*"
        ));
    }
}

或者在控制器级别添加 [EnableCors] 特性：

cs 复制代码

[EnableCors(origins: "http://localhost:3000", headers: "*", methods: "*")]
public class ValuesController : ApiController
{
    // 控制器方法
}

三、配置位置说明

‌ASP.NET Core ‌：配置在 Program.cs 中的 ConfigureServices 方法中注册服务，并在 Configure 方法中使用 UseCors 中间件。
‌ASP.NET Web API ‌：配置在 WebApiConfig.cs 文件中，或在控制器上使用特性。

四、注意事项

在 ASP.NET Core 中，UseCors 必须放在 UseAuthorization 之前。
如果需要支持带凭证（如 cookie）的请求，不能使用 AllowAnyOrigin()，必须明确指定源。
配置的源应根据实际需求设置，避免使用 * 带来安全隐患。

通过以上配置，C# 后端即可允许指定源的跨域请求，解决前端调用时的跨域问题。

4.C# middleware 和filter的区别以及作用

在 C# 的 ASP.NET Core 应用程序中，Middleware（中间件）和 Filter（过滤器）都是用于处理请求和响应的组件，但它们在作用范围、执行阶段和使用场景上存在显著区别。

一、作用范围

‌Middleware‌ 是全局性的，作用于整个应用程序的请求处理管道。它会影响所有传入的 HTTP 请求。
‌Filter‌ 是局部性的，仅作用于 MVC 控制器或动作方法级别。

二、执行阶段

‌Middleware‌ 在请求处理管道的早期阶段执行，可以在请求到达控制器之前或之后处理逻辑。
‌Filter‌ 在 MVC 执行生命周期内部执行，具体来说，它可以在动作执行前后、结果执行前后等特定阶段插入逻辑。

三、适用场景

‌Middleware‌ 适用于需要对所有请求进行统一处理的场景，例如：
- 身份验证和授权
- 日志记录
- 异常处理
- CORS 设置
- 静态文件服务
- 请求和响应的压缩处理等。
‌Filter‌ 适用于需要针对特定控制器或动作方法进行处理的场景，例如：
- 授权验证
- 数据验证
- 日志记录
- 结果格式化
- 缓存控制等。

四、执行顺序

‌Middleware‌ 按照在请求处理管道中添加的顺序执行。
‌Filter‌ 不同类型的过滤器按照特定顺序执行，例如授权过滤器、动作过滤器、结果过滤器等。

五、访问上下文

‌Middleware ‌ 直接访问 HttpContext，可以处理整个 HTTP 请求和响应。
‌Filter ‌ 访问的是 MVC 特定的上下文，如 ActionContext，更贴近于控制器和动作的执行。

六、灵活性

‌Middleware‌ 更加灵活，可以处理所有类型的请求，包括非 MVC 请求。
‌Filter‌ 更加贴合业务逻辑，因为它直接与 MVC 控制器和动作交互。

七、实现方式

‌Middleware ‌ 通过 app.UseMiddleware<T>() 方法添加到应用程序启动时的请求处理管道中。
‌Filter ‌ 通过特性 [Authorize] 或通过注册服务来实现，例如 [ServiceFilter(typeof(CustomActionFilter))]。

总的来说，Middleware 更像是一个全局的"守门员"，负责处理所有请求的通用逻辑；而 Filter 则更像是一个"局部管理员"，专门处理特定控制器或动作的业务逻辑。

5.为什么日志要在中间件去记录，而不是在filter里面

在 ASP.NET Core 中，日志记录可以在中间件（Middleware）或过滤器（Filter）中实现，但选择中间件通常更为合适，特别是在需要记录全局请求日志时。以下是关键原因：

1. ‌中间件是 HTTP 请求管道的核心组件‌

中间件是 ASP.NET Core 请求处理管道中的基础组件，它在请求进入应用程序时就会被调用，适用于所有请求，无论请求是否被路由到特定的控制器或动作方法。这使得中间件成为记录全局访问日志的理想选择，因为它能捕获从请求进入系统到响应返回的完整过程。

2. ‌中间件更接近底层，具有全局性‌

中间件作用于整个应用程序的请求管道，能够处理所有请求，包括静态文件请求、错误页面等。而过滤器（Filter）通常只应用于特定的控制器或动作方法，因此在需要记录所有请求（如访问日志）时，中间件更具全局性。

3. ‌性能和适用场景‌

中间件在处理请求时性能更高，因为它不依赖于 MVC 框架的特定组件，而过滤器（Filter）则需要在 MVC 框架的上下文中运行，可能会引入额外的开销。对于简单的访问日志记录，中间件通常更高效且更直接。

4. ‌灵活性与控制‌

中间件可以灵活地处理请求和响应，甚至可以终止请求管道。这种灵活性使得中间件在处理日志记录时，能够更精细地控制日志的输出和处理方式，例如在请求到达特定控制器之前或响应返回后插入日志记录逻辑。

5. ‌避免重复记录‌

在某些复杂的请求处理场景中，过滤器可能会因为请求分发（如错误分发、转发等）被多次触发，导致日志重复记录。而中间件可以通过更精确的逻辑来避免这种情况，确保每条请求只被记录一次。

总结

虽然过滤器（Filter）也可以用于日志记录，特别是在需要访问 MVC 特定上下文（如 ActionExecutingContext）时，但中间件更适合用于记录全局的请求日志，因为它更接近底层、更具有全局性，并且性能更高。选择中间件可以确保日志记录的准确性和效率，特别是在需要捕获所有请求的情况下。

6.C# 依赖注入怎么使用，有哪几个生命周期，如果一个静态类想使用容器的类，怎么通过依赖注入的方式使用？依赖注入使用全流程

C# 依赖注入详解

依赖注入基本概念

依赖注入（Dependency Injection, DI）是一种设计模式，用于实现控制反转（Inversion of Control, IoC）。它将对象的创建和管理交给容器，而不是在类内部直接创建依赖对象。这样可以降低耦合度，提高代码的可测试性和可维护性。

依赖注入的三种生命周期

‌**Transient（瞬态）**‌:
- 每次请求都会创建新实例
- 生命周期最短，适合轻量级、无状态的服务
- 注册方式: services.AddTransient<IMyService, MyService>();
‌**Scoped（作用域）**‌:
- 在同一个HTTP请求范围内共享实例
- 每个HTTP请求创建一次实例
- 注册方式: services.AddScoped<IMyService, MyService>();
‌**Singleton（单例）**‌:
- 整个应用程序生命周期只创建一个实例
- 第一次请求时创建，后续都复用该实例
- 注册方式: services.AddSingleton<IMyService, MyService>();

依赖注入使用全流程

1. 定义接口和服务

首先定义服务接口和实现类:

cs 复制代码

public interface IEmailService
{
    void SendEmail(string to, string subject, string body);
}

public class EmailService : IEmailService
{
    public void SendEmail(string to, string subject, string body)
    {
        Console.WriteLine($"发送邮件到 {to}: {subject}");
    }
}

2. 在Program.cs中注册服务

在ASP.NET Core应用中注册服务:

cs 复制代码

var builder = WebApplication.CreateBuilder(args);

// 注册服务
builder.Services.AddTransient<IEmailService, EmailService>();

var app = builder.Build();

3. 在控制器中使用构造函数注入

通过构造函数参数自动注入依赖:

cs 复制代码

[ApiController]
[Route("[controller]")]
public class HomeController : ControllerBase
{
    private readonly IEmailService _emailService;

    public HomeController(IEmailService emailService)
    {
        _emailService = emailService;
    }

    [HttpPost("send")]
    public IActionResult SendEmail([FromBody] EmailRequest request)
    {
        _emailService.SendEmail(request.To, request.Subject, request.Body);
        return Ok("邮件已发送");
    }
}

4. 静态类使用容器服务的方法

静态类无法直接通过构造函数注入，可通过以下方式解决:

方案一: 使用IServiceProvider获取服务

cs 复制代码

public static class StaticHelper
{
    private static IServiceProvider _serviceProvider;

    public static void Configure(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public static void DoSomething()
    {
        using var scope = _serviceProvider.CreateScope();
        var emailService = scope.ServiceProvider.GetRequiredService<IEmailService>();
        emailService.SendEmail("test@example.com", "测试", "这是一封测试邮件");
    }
}

// 在Program.cs中配置
var app = builder.Build();
StaticHelper.Configure(app.Services);

方案二: 将静态类改为实例类并注册为单例

cs 复制代码

public interface IStaticHelper
{
    void DoSomething();
}

public class StaticHelper : IStaticHelper
{
    private readonly IEmailService _emailService;

    public StaticHelper(IEmailService emailService)
    {
        _emailService = emailService;
    }

    public void DoSomething()
    {
        _emailService.SendEmail("test@example.com", "测试", "这是一封测试邮件");
    }
}

// 注册为单例
builder.Services.AddSingleton<IStaticHelper, StaticHelper>();

完整示例代码

以下是完整的依赖注入使用示例代码：

cs 复制代码

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using System;

// 服务接口定义
public interface IMessageService
{
    void SendMessage(string message);
}

// 服务实现
public class EmailMessageService : IMessageService
{
    public void SendMessage(string message)
    {
        Console.WriteLine($"通过邮箱发送消息: {message}");
    }
}

public class SmsMessageService : IMessageService
{
    public void SendMessage(string message)
    {
        Console.WriteLine($"通过短信发送消息: {message}");
    }
}

// 需要依赖注入的业务类
public class BusinessService
{
    private readonly IMessageService _messageService;

    public BusinessService(IMessageService messageService)
    {
        _messageService = messageService;
    }

    public void ProcessBusinessLogic()
    {
        _messageService.SendMessage("处理完成通知");
    }
}

// 解决静态类使用DI的方案
public static class StaticUtility
{
    private static IServiceProvider _serviceProvider;

    public static void Configure(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public static void ExecuteTask()
    {
        if (_serviceProvider == null)
            throw new InvalidOperationException("未配置服务提供者");

        using var scope = _serviceProvider.CreateScope();
        var messageService = scope.ServiceProvider.GetRequiredService<IMessageService>();
        messageService.SendMessage("来自静态工具类的消息");
    }
}

class Program
{
    static void Main(string[] args)
    {
        // 创建宿主构建器
        var hostBuilder = Host.CreateDefaultBuilder(args)
            .ConfigureServices((context, services) =>
            {
                // 注册不同生命周期的服务
                services.AddTransient<IMessageService, EmailMessageService>(); // 瞬态
                services.AddScoped<BusinessService>(); // 作用域
                services.AddSingleton<SmsMessageService>(); // 单例
            });

        // 构建宿主
        var host = hostBuilder.Build();

        // 配置静态类使用DI容器
        StaticUtility.Configure(host.Services);

        // 获取服务并使用
        using var scope = host.Services.CreateScope();
        var businessService = scope.ServiceProvider.GetRequiredService<BusinessService>();
        businessService.ProcessBusinessLogic();

        // 使用静态类
        StaticUtility.ExecuteTask();

        Console.WriteLine("依赖注入示例执行完毕");
    }
}

代码说明：

示例包含了三种生命周期服务的注册和使用方式
展示了构造函数注入的标准实践
提供了解决静态类使用DI容器的两种方案
项目可在控制台环境中完整运行，无需Web服务器
使用了Microsoft.Extensions.Hosting包来提供DI容器功能
包含了完整的项目配置文件和说明文档

7.C# 依赖注入有哪几种方式？

C# 中的依赖注入主要有以下三种方式：

1. 构造函数注入（Constructor Injection）

这是最常用和推荐的依赖注入方式。通过类的构造函数参数传递依赖项，确保在对象创建时依赖项就已准备好。

cs 复制代码

public class UserService
{
    private readonly IUserRepository _userRepository;
    private readonly IEmailSender _emailSender;

    public UserService(IUserRepository userRepository, IEmailSender emailSender)
    {
        _userRepository = userRepository;
        _emailSender = emailSender;
    }
}

2. 属性注入（Property Injection）

通过公共属性设置依赖项，通常用于可选依赖或需要在对象创建后动态更改依赖的情况。

cs 复制代码

public class UserService
{
    public IUserRepository UserRepository { get; set; }
    public IEmailSender EmailSender { get; set; }
}

3. 方法注入（Method Injection）

依赖项作为方法参数传递，适用于仅在特定方法中需要依赖的场景。

cs 复制代码

public class UserService
{
    public void ProcessUser(IUserRepository userRepository, IEmailSender emailSender)
    {
        // 在方法内部使用依赖项
        userRepository.SaveUser();
        emailSender.SendEmail();
    }
}

其中，构造函数注入是最推荐的方式，因为它确保了依赖项在对象生命周期内不可变且完整初始化。属性注入和方法注入则适用于特定场景，如可选依赖或临时依赖的情况。

8.C# sqlsugar和entityframeworkcore 区别以及特点适用场景

C# 中的 SqlSugar 和 Entity Framework Core 是两个流行的 ORM（对象关系映射）框架，它们在设计理念、功能特点和适用场景上存在显著差异。

设计理念与定位

‌**Entity Framework Core (EF Core)**‌ 是微软官方开发的重量级 ORM 框架，强调领域驱动设计（DDD）和对象关系映射的完整性，适合复杂业务场景。它以"领域模型"为核心，让开发者面向对象编程而非面向 SQL 编程。

‌SqlSugar‌ 是一款轻量级、高性能的 ORM 框架，注重简洁易用和高性能，专注于快速开发和 SQL 可控性。它提供了类 LINQ 的查询语法，让数据库操作更直观。

核心功能对比

Entity Framework Core 特点

‌强 LINQ 支持‌：通过 C# 表达式描述查询逻辑，提供类型安全的编译时检查
‌代码优先‌：允许开发者使用 C# 代码定义数据库模型，EF Core 自动生成数据库表结构
‌数据库迁移‌：支持数据库版本控制，轻松更新数据库结构
‌跨平台支持‌：可在 Windows、macOS 和 Linux 上运行
‌变更跟踪‌：自动跟踪实体状态变化

SqlSugar 特点

‌高性能‌：优化底层 SQL 执行效率，性能优于 EF Core
‌灵活的查询语法‌：支持链式调用和类似 LINQ 的查询语法
‌多数据库支持‌：兼容 SQL Server、MySQL、PostgreSQL、Oracle 等多种数据库
‌原生 SQL 支持‌：支持直接执行原生 SQL 并映射到实体
‌丰富的功能‌：支持事务管理、动态表名、分页、多表联查等高级特性

适用场景

Entity Framework Core 适用场景

企业级应用和复杂业务模型项目
需要强类型支持和复杂 CRUD 操作的项目
微服务架构中的数据访问层
需要与 ASP.NET Core 深度集成的项目
对数据库迁移和版本控制有要求的项目

SqlSugar 适用场景

中小型项目和快速开发场景
需要灵活且易于使用的 ORM 的项目
对性能有一定要求但不想完全放弃 ORM 便利性的项目
需要动态表结构管理的场景
需要高性能数据库操作的项目

性能表现

在性能方面，SqlSugar 通常表现优于 EF Core，特别是在简单和中等复杂度的操作中。Dapper 虽然性能更优，但需要更多的 SQL 编写经验。EF Core 在复杂查询时性能相对较低，需要手动优化生成的 SQL。

总结

选择 SqlSugar 还是 EF Core 主要取决于项目需求。如果项目需要复杂的业务逻辑、强类型支持和完整的 ORM 功能，EF Core 是更好的选择。如果项目注重快速开发、性能优化和 SQL 控制，SqlSugar 则更为合适。

9.C# 项目中多线程的安全怎么保证，通常怎么设计，异步编程async await模型可以保证多线程安全么？并发线程安全怎么保证

在 C# 项目中，保证多线程安全是并发编程中的核心问题。以下是一些常见的方法和设计模式：

1. 线程安全的实现方式

使用锁机制（Lock）

这是最基础也是最常用的线程安全手段。通过 lock 关键字可以确保同一时间只有一个线程能够执行特定代码块。

cs 复制代码

private static readonly object _lockObject = new object();
private static int _sharedCounter = 0;

public static void IncrementCounter()
{
    lock (_lockObject)
    {
        _sharedCounter++;
    }
}

使用 Monitor 类

Monitor 是 lock 关键字的底层实现，提供了更灵活的锁定机制。

cs 复制代码

private static readonly object _monitorLock = new object();
private static int _monitorCounter = 0;

public static void IncrementWithMonitor()
{
    Monitor.Enter(_monitorLock);
    try
    {
        _monitorCounter++;
    }
    finally
    {
        Monitor.Exit(_monitorLock);
    }
}

使用 Interlocked 类

对于简单的原子操作（如递增、递减），Interlocked 类提供了高效的无锁操作。

cs 复制代码

private static int _atomicCounter = 0;

public static void IncrementAtomic()
{
    Interlocked.Increment(ref _atomicCounter);
}

使用线程安全集合

C# 提供了 System.Collections.Concurrent 命名空间下的线程安全集合类，如 ConcurrentDictionary、ConcurrentQueue 等。

cs 复制代码

private static readonly ConcurrentDictionary<string, int> _concurrentDict = new ConcurrentDictionary<string, int>();

public static void AddValue(string key, int value)
{
    _concurrentDict.TryAdd(key, value);
}

使用信号量（Semaphore）

当需要限制同时访问某个资源的线程数量时，可以使用 Semaphore 或 SemaphoreSlim。

cs 复制代码

private static readonly SemaphoreSlim _semaphore = new SemaphoreSlim(2, 2); // 最多允许2个线程同时访问

public async Task AccessResourceAsync()
{
    await _semaphore.WaitAsync();
    try
    {
        // 访问共享资源
    }
    finally
    {
        _semaphore.Release();
    }
}

2. 异步编程模型（async/await）与线程安全

异步编程模型（async/await）本身‌不直接保证线程安全 ‌，它主要解决的是‌避免阻塞线程 ‌和‌提高程序响应性‌的问题。然而，async/await 可以通过以下方式间接帮助线程安全：

‌避免阻塞线程‌：异步操作不会阻塞线程，从而避免了线程池中的线程被长时间占用，提高整体并发性能。
‌简化并发控制‌：在某些场景下，异步编程可以减少对锁的需求，因为异步操作通常不会长时间持有锁。

cs 复制代码

public async Task<string> GetDataAsync()
{
    // 异步等待 I/O 操作
    var result = await httpClient.GetStringAsync("https://api.example.com");
    return result.ToUpper();
}

3. 设计模式与最佳实践

无锁设计（Lock-Free）

对于一些特定场景，可以使用无锁的数据结构或算法来避免锁带来的性能开销。

不可变对象

创建不可变对象可以从根本上避免线程安全问题，因为对象一旦创建就不能修改

cs 复制代码

public class ImmutableUser
{
    public int Id { get; }
    public string Name { get; }
    public int Age { get; }

    public ImmutableUser(int id, string name, int age)
    {
        Id = id;
        Name = name;
        Age = age;
    }

    public ImmutableUser WithAge(int newAge)
    {
        return new ImmutableUser(Id, Name, newAge);
    }
}

线程局部存储（ThreadLocal）

当每个线程需要独立的数据副本时，可以使用 ThreadLocal<T>。

cs 复制代码

private static readonly ThreadLocal<int> _threadLocalCounter = new ThreadLocal<int>(() => 0);

public static void IncrementThreadLocal()
{
    _threadLocalCounter.Value++;
}

4. 避免常见陷阱

避免嵌套锁

嵌套锁是死锁的常见原因，应尽量避免。

避免长时间持有锁

减少锁的持有时间，提高并发性能。

正确处理异常

在使用锁时，确保异常处理不会导致锁无法释放。

cs 复制代码

lock (_lockObject)
{
    try
    {
        // 执行业务逻辑
    }
    catch (Exception ex)
    {
        // 处理异常
        throw;
    }
}

总结

在 C# 中保证多线程安全需要根据具体场景选择合适的方法。对于简单的共享变量访问，可以使用 lock、Monitor 或 Interlocked；对于复杂的并发场景，可以考虑使用线程安全集合或信号量；对于高性能要求的场景，可以探索无锁设计。异步编程模型（async/await）虽然不直接保证线程安全，但可以与这些技术结合使用，构建更加高效和安全的并发程序。

10.C# 项目中使用到微信支付，接口以及设计以及代码开发方面，需要注意哪些问题，开发流程是怎么样的

在 C# 项目中集成微信支付是一个典型的支付网关对接任务，涉及到安全性、事务一致性等多个方面。下面我会详细说明注意事项和开发流程。

注意事项

1. 安全性保障

‌签名验签‌：严格按照微信官方文档进行参数签名计算，防止篡改攻击。
‌HTTPS通信‌：所有 API 接口必须走 HTTPS 协议加密传输。
‌敏感信息保护‌：APIv3密钥、商户私钥等不得硬编码在代码里，建议存放在环境变量或专用配置中心。
‌回调地址校验‌：收到异步通知后，先验证签名再处理业务逻辑。

2. 数据一致性

‌幂等性处理‌：由于网络波动可能造成重复下单，服务端需具备防重机制。
‌状态同步‌：主动查询订单状态并与本地数据库保持一致。
‌异常补偿‌：若支付成功但更新 DB 失败，要有定时任务兜底修复。

3. 日志监控

‌交易流水记录‌：保留完整的原始报文及关键节点日志便于排查问题。
‌告警策略‌：对高频失败、超时等情况建立预警机制。

微信支付接入流程概览

注册并认证微信支付商户平台账号
获取必要凭证（mch_id、serial_no、apiclient_key.pem、APIv3Key）
下载微信提供的证书并定期刷新
构建统一支付下单接口 /v3/pay/transactions/native （扫码付为例）
实现支付结果异步通知接收 /notify_url
封装退款申请 /v3/refund/domestic/refunds
设置白名单 IP 地址范围

接下来提供一个基于 .NET 6 + WeChatPay SDK 的最小可行示例工程结构：

cs 复制代码

//Programs类：
using Microsoft.AspNetCore.Mvc;
using System.Security.Cryptography.X509Certificates;
using System.Text.Json.Serialization;

var builder = WebApplication.CreateBuilder(args);

// 注入微信支付客户端和服务
builder.Services.AddHttpClient();
builder.Services.AddSingleton<IWeChatPayClient, WeChatPayClient>();
builder.Services.Configure<WeChatPayOptions>(builder.Configuration.GetSection("WeChatPay"));

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
}

app.MapPost("/pay", async ([FromBody] CreateOrderRequest request, [FromServices] IWeChatPayClient client) =>
{
    var response = await client.CreateNativeOrderAsync(request.OutTradeNo, request.Description, request.TotalFee);
    return Results.Ok(new { CodeUrl = response.CodeUrl });
});

app.MapPost("/notify", async (HttpContext context, [FromServices] IWeChatPayClient client) =>
{
    using var reader = new StreamReader(context.Request.Body);
    var body = await reader.ReadToEndAsync();
    
    if (client.VerifySignature(body, context.Request.Headers["Wechatpay-Signature"], 
                               context.Request.Headers["Wechatpay-Timestamp"],
                               context.Request.Headers["Wechatpay-Nonce"]))
    {
        // TODO: 更新订单状态至DB
        Console.WriteLine($"Received payment notification for order.");
        await context.Response.WriteAsync("SUCCESS");
    }
    else
    {
        await context.Response.WriteAsync("FAIL");
    }
});

app.Run();


public record CreateOrderRequest(string OutTradeNo, string Description, int TotalFee);

[JsonSerializable(typeof(CreateOrderRequest))]
internal partial class CreateOrderRequestJsonSerializerContext : JsonSerializerContext { }


//IWeChatPayClient.cs类

namespace PaymentDemo.Services
{
    public interface IWeChatPayClient
    {
        Task<CreateOrderResponse> CreateNativeOrderAsync(string outTradeNo, string description, int totalFee);
        
        bool VerifySignature(string body, string signatureHeader, string timestamp, string nonce);
    }

    public record CreateOrderResponse(string CodeUrl);
}


//WeChatPayClient.cs类

using System.Net.Http.Json;
using System.Security.Cryptography;
using System.Text;
using System.Text.Json;

namespace PaymentDemo.Services
{
    public class WeChatPayClient : IWeChatPayClient
    {
        private readonly HttpClient _httpClient;
        private readonly ILogger<WeChatPayClient> _logger;
        private readonly X509Certificate2 _merchantCert;
        private readonly string _mchId;
        private readonly string _apiKey;

        public WeChatPayClient(HttpClient httpClient, IConfiguration configuration, ILogger<WeChatPayClient> logger)
        {
            _httpClient = httpClient;
            _logger = logger;
            
            // Load config from environment or secrets manager
            _mchId = configuration["WeChatPay:MchId"];
            _apiKey = configuration["WeChatPay:ApiKey"];
            var certPath = configuration["WeChatPay:MerchantCertPath"];
            _merchantCert = new X509Certificate2(certPath, "", X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet);
        }

        public async Task<CreateOrderResponse> CreateNativeOrderAsync(string outTradeNo, string description, int totalFee)
        {
            var url = "https://api.mch.weixin.qq.com/v3/pay/transactions/native";
            var payload = new
            {
                appid = "YOUR_APP_ID",
                mchid = _mchId,
                description,
                out_trade_no = outTradeNo,
                notify_url = "https://yourdomain.com/api/notify",
                amount = new { total = totalFee },
                time_expire = DateTime.UtcNow.AddMinutes(10).ToString("yyyy-MM-ddTHH:mm:ssZ")
            };

            var jsonPayload = JsonSerializer.Serialize(payload);
            var authHeader = GenerateAuthorizationHeader(url, "POST", jsonPayload);

            _httpClient.DefaultRequestHeaders.Clear();
            _httpClient.DefaultRequestHeaders.Add("Authorization", authHeader);
            _httpClient.DefaultRequestHeaders.Add("Accept", "application/json");

            var content = new StringContent(jsonPayload, Encoding.UTF8, "application/json");
            var response = await _httpClient.PostAsync(url, content);

            if (!response.IsSuccessStatusCode)
            {
                var errorBody = await response.Content.ReadAsStringAsync();
                _logger.LogError("Failed to create native order: {Error}", errorBody);
                throw new HttpRequestException(errorBody);
            }

            var responseBody = await response.Content.ReadFromJsonAsync<JsonElement>();
            return new CreateOrderResponse(responseBody.GetProperty("code_url").GetString());
        }

        public bool VerifySignature(string body, string signatureHeader, string timestamp, string nonce)
        {
            try
            {
                var messageToSign = $"{timestamp}\n{nonce}\n{body}\n";
                var hashBytes = SHA256.HashData(Encoding.UTF8.GetBytes(messageToSign));
                
                using var rsa = _merchantCert.GetRSAPublicKey();
                return rsa.VerifyHash(hashBytes, Convert.FromBase64String(signatureHeader), HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1);
            }
            catch (Exception ex)
            {
                _logger.LogWarning(ex, "Signature verification failed");
                return false;
            }
        }

        private string GenerateAuthorizationHeader(string uri, string method, string body)
        {
            var timestamp = DateTimeOffset.UtcNow.ToUnixTimeSeconds().ToString();
            var nonceStr = Guid.NewGuid().ToString("N")[..32];
            var messageToSign = $"{method}\n{new Uri(uri).PathAndQuery}\n\n{timestamp}\n{nonceStr}\n{SHA256.HashData(Encoding.UTF8.GetBytes(body))}\n";

            using var rsa = _merchantCert.GetRSAPrivateKey();
            var signature = Convert.ToBase64String(rsa.SignData(Encoding.UTF8.GetBytes(messageToSign), HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1));

            return $"WECHATPAY2-SHA256-RSA2048 mchid=\"{_mchId}\",nonce_str=\"{nonceStr}\",timestamp=\"{timestamp}\",serial_no=\"{_merchantCert.SerialNumber}\",signature=\"{signature}\"";
        }
    }
}


//appsettings.Develop配置文件

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*",
  "WeChatPay": {
    "MchId": "190000xxxx",
    "ApiKey": "YOUR_API_V3_KEY_HERE",
    "MerchantCertPath": "./cert/apiclient_cert.p12"
  }
}

以上代码展示了如何在 .NET 6 中搭建基本的微信 Native 支付能力，涵盖了下单、签名生成与验证等核心环节。实际部署生产环境还需补充：

商户证书自动轮换逻辑；
更完善的异常熔断降级措施；
分布式缓存加速频繁读取的操作（比如 access_token）；
整合 EFCore 存储订单信息；
加强单元测试覆盖各类边界条件。

11.sqlserver数据库优化，从哪些方面考虑设计，如果要你设计数据库优化，你要从哪些方面考虑，说说你的看法

SQL Server数据库优化是一个系统性的工程，需要从多个维度综合考虑。以下：

数据库设计层面优化

‌范式与反范式平衡‌

遵循第三范式减少数据冗余，但在OLAP场景适当反范式化提升查询性能
合理使用分区表处理大数据量，按时间或业务维度水平分割

‌索引策略设计‌

主键约束自动创建聚集索引，选择合适的候选键作为聚簇键
针对WHERE、JOIN、ORDER BY子句常用字段建立覆盖索引
利用索引视图物化复杂聚合计算结果，降低实时运算压力

SQL语句编写优化

‌查询重构技巧‌

EXISTS替代IN谓词提高子查询效率
使用INNER JOIN代替隐式连接语法增强可读性
应用WITH(NOLOCK)提示读未提交隔离级别加快报表查询速度（谨慎使用）

‌执行计划解读‌

分析Actual Execution Plan识别高成本算子
关注Key Lookup、Sort Warning等潜在瓶颈步骤
启用SET STATISTICS IO ON监控逻辑读取次数评估改进效果

系统资源配置调优

‌内存分配管理‌

max server memory设置防止缓冲池过度消耗OS资源
优先升级RAM容量而非CPU核心数应对缓存命中率不足
监控Buffer Cache Hit Ratio指标维持在95%以上理想区间

‌磁盘I/O调度‌

TempDB文件组分散到独立物理卷缓解PFS/GAM争抢
表和索引分离存放不同LUN通道均衡负载分布
开启即时文件初始化缩短大型操作预分配延迟

运维监控体系构建

‌自动化健康检查‌

定期收集dm_db_index_physical_stats检测碎片程度
跟踪sys.dm_exec_query_stats找出资源耗费Top SQL清单
实施作业警报机制捕获阻塞链路及时干预恢复

综上所述，数据库性能优化应当贯穿整个软件生命周期，从业务建模阶段就纳入考量范畴，并辅以持续观测反馈闭环才能达成稳定可靠的服务质量目标。

12.sqlserver数据库 sql优化，通常有什么方法优化sql性能

在 SQL Server 数据库优化中，优化 SQL 性能的方法可以从多个维度入手，主要包括以下几个方面：

1. ‌索引优化‌

‌创建合适的索引‌：在经常用于 WHERE、JOIN、ORDER BY 子句的列上建立索引。
‌联合索引设计‌：遵循最左前缀原则，将高区分度的列放在前面。
‌覆盖索引‌：通过 INCLUDE 子句包含 SELECT 字段，避免回表操作。
‌定期维护索引‌：删除冗余索引，重建或重组碎片索引。

2. ‌查询语句优化‌

‌避免全表扫描‌：通过合理使用索引避免扫描整个表。
‌优化子查询‌：将子查询改写为 JOIN 操作，减少 I/O。
‌使用 EXISTS 替代 IN‌：在某些场景下可以提高性能。
‌避免隐式转换‌：确保字段类型匹配，防止索引失效。

3. ‌执行计划分析‌

‌分析执行计划‌：使用 SQL Server Management Studio 查看实际执行计划，识别瓶颈。
‌关注关键指标‌：如 type 字段（const > eq_ref > ref > range > index > ALL）、rows 预估扫描行数等。
‌识别高开销运算符‌：如聚集索引扫描、哈希匹配等。

4. ‌参数嗅探与计划重用‌

‌处理参数嗅探问题‌：使用局部变量或 OPTION (OPTIMIZE FOR UNKNOWN) 解决。
‌计划缓存管理‌：监控计划缓存，必要时清除不合适的缓存计划。

5. ‌表结构与分区优化‌

‌表分区‌：对大表按时间或业务维度进行分区。
‌垂直分表与水平分片‌：分离高频字段和低频字段，分散热点数据。

6. ‌统计信息维护‌

‌更新统计信息‌：定期更新表和索引的统计信息，确保查询优化器能生成最优计划。

7. ‌硬件与配置优化‌

‌内存配置‌：合理设置 max server memory，确保缓冲池充足。
‌磁盘 I/O 优化‌：使用 SSD 存储，将数据文件、日志文件分离。

8. ‌使用高级特性‌

‌内存优化表‌：适用于对性能要求极高的场景。
‌列存储索引‌：适合 OLAP 场景，提供高压缩率和查询性能。
‌并行查询控制‌：根据 CPU 核心数和查询开销合理启用并行处理。

通过综合运用这些方法，可以显著提升 SQL Server 数据库的查询性能。

13.前端页面数据展示加载速度怎么优化

前端页面数据展示加载速度优化是一个综合性的问题，主要可以从以下几个方面着手：

1. ‌数据获取优化‌

‌分页加载‌：避免一次性加载大量数据，采用分页或无限滚动方式逐步加载
‌懒加载‌：对于非首屏数据或图片等内容，采用懒加载策略延后加载
‌数据压缩‌：服务端启用Gzip/Brotli压缩，减少传输体积
‌缓存策略‌：合理使用HTTP缓存头(Etag、Cache-Control)和浏览器本地缓存

2. ‌渲染性能优化‌

‌虚拟滚动‌：对于长列表展示，只渲染可视区域内的元素
‌骨架屏‌：在数据加载过程中显示占位符，提升用户体验
‌防抖节流‌：对频繁触发的操作(如搜索输入)进行防抖处理
‌组件懒加载‌：使用动态import()按需加载非关键组件

3. ‌资源加载优化‌

‌代码分割‌：通过Webpack等工具进行代码分割，减少初始bundle大小
‌图片优化‌：使用WebP格式、响应式图片(srcset)、适当的尺寸和质量
‌字体加载‌：使用font-display: swap避免文字闪烁，预加载关键字体
‌预加载策略‌：合理使用<link rel="preload">提前加载关键资源

4. ‌DOM操作优化‌

‌减少重排重绘‌：批量修改样式，使用transform替代改变布局属性
‌事件委托‌：对于大量相似元素，使用事件委托减少监听器数量
‌DocumentFragment‌：批量DOM操作时使用文档片段减少回流

5. ‌网络请求优化‌

‌请求合并‌：合并多个小请求为一个批量请求
‌优先级控制‌：使用fetchPriority等属性控制资源加载优先级
‌预请求‌：对用户可能需要的数据进行预测性加载

6. ‌框架特定优化‌

‌React‌: 使用useMemo、useCallback、React.memo减少不必要的重新渲染
‌Vue‌: 合理使用computed、watch、keep-alive等优化手段
‌Angular‌: 使用OnPush变更检测策略，trackBy优化列表渲染

通过综合运用这些优化策略，可以显著提升前端数据展示页面的加载速度和用户体验。具体的实施方案需要根据项目实际情况和技术栈来确定。

14.sqlserver数据库 group by 和聚合函数 over(partition by 字段) 都是分组，他们有什么区别，适用于什么场景

在 SQL Server 数据库优化中，GROUP BY 和 OVER(PARTITION BY 字段) 都涉及分组操作，但它们在功能、执行方式和适用场景上有显著区别。

主要区别

1. ‌数据行数影响‌

‌GROUP BY ‌：会对数据进行聚合，每组只返回一行结果。例如，如果一个分组包含10条记录，GROUP BY 会将这10条记录合并为一行（通过聚合函数计算），最终结果集的行数会减少。
‌OVER(PARTITION BY 字段) ‌：不会减少数据行数，而是保留原始行数据，同时在每个分区内独立计算窗口函数。例如，如果一个分组包含10条记录，使用 OVER(PARTITION BY 字段) 后，结果集中仍然有10行记录，只是每行都包含了该分组内的聚合信息。

2. ‌SELECT 子句限制‌

‌GROUP BY ‌：SELECT 子句中只能包含分组列和聚合函数的结果，不能直接选择非聚合列。
‌OVER(PARTITION BY 字段) ‌：SELECT 子句可以包含任意列，包括原始数据列和窗口函数计算结果。

3. ‌执行顺序和逻辑‌

‌GROUP BY ‌：执行顺序为 WHERE → GROUP BY → HAVING，先对数据进行过滤和分组，再进行聚合计算。
‌OVER(PARTITION BY 字段) ‌：执行顺序为 FROM/WHERE → WINDOW → SELECT，窗口函数在 WHERE 和 GROUP BY 之后执行，对已经过滤和分组的数据进行窗口计算。

4. ‌性能开销‌

‌GROUP BY‌：需要进行哈希或排序操作来完成分组和聚合，性能开销相对较大。
‌OVER(PARTITION BY 字段) ‌：在优化器支持的情况下，如果存在合适的索引，可以避免排序，性能通常优于 GROUP BY。

适用场景

GROUP BY 适用场景

‌统计分析‌：当你需要对数据进行分类汇总，例如按地区统计销售额、按产品分类计算总销量等。
‌生成报表‌：需要生成按维度分组的汇总报表，如销售日报、月报等。
‌数据聚合‌：当只需要每组的聚合结果，而不需要原始明细数据时。

OVER(PARTITION BY 字段) 适用场景

‌排名和排序‌：需要在每个分组内进行排名，如按班级排名、按部门排名等。
‌累计计算‌：需要计算每个分组内的累计值，如累计销售额、累计增长率等。
‌窗口分析‌：需要在保留原始数据的基础上进行分组分析，如计算每个产品每月销售量与上月的差异。
‌对比分析‌：需要将每个记录与同组内的其他记录进行对比，如计算每个员工与部门平均工资的差异。

实际应用示例

GROUP BY 示例

cs 复制代码

SELECT region, SUM(amount) AS total_amount
FROM Sales
GROUP BY region;

此查询会返回每个地区的销售总额，结果集中的行数等于不同地区的数量。

OVER(PARTITION BY 字段) 示例

bash 复制代码

SELECT region, amount, 
       SUM(amount) OVER(PARTITION BY region) AS total_amount
FROM Sales;

此查询会保留所有销售记录，同时为每条记录添加该地区销售总额的列。

总结

选择使用 GROUP BY 还是 OVER(PARTITION BY 字段) 主要取决于是否需要保留原始数据行以及具体的分析需求。如果只需要汇总结果，GROUP BY 是更合适的选择；如果需要保留明细数据并进行分组内的计算，则应选择 OVER(PARTITION BY 字段)。

C#开发工程师-面经

1.SQLSugar和Entity FrameWork Core框架的区别和适用场景

一、开发背景与定位

二、核心设计理念

三、适用场景对比

四、功能与性能对比

五、总结

2.List<int > a = (1,2,3...,100);C#语法 使用原生拉姆达表达式写法，筛选出包含9的，并且结果拼接上a，输出结果为List<string> b = (a9,a19,a29,...a99)

3.C# 跨域 怎么写，写到哪里，原理是什么？

一、CORS 原理

二、C# 中实现 CORS 的方式

1. ASP.NET Core 中配置 CORS

2. ASP.NET Web API（非 Core）中的配置

三、配置位置说明

四、注意事项

4.C# middleware 和filter的区别 以及作用

一、作用范围

二、执行阶段

三、适用场景

四、执行顺序

五、访问上下文

六、灵活性

七、实现方式

5.为什么日志要在中间件去记录，而不是在filter里面

1. ‌中间件是 HTTP 请求管道的核心组件‌

2. ‌中间件更接近底层，具有全局性‌

3. ‌性能和适用场景‌

4. ‌灵活性与控制‌

5. ‌避免重复记录‌

总结

6.C# 依赖注入 怎么使用，有哪几个生命周期，如果一个静态类想使用容器的类，怎么通过依赖注入的方式使用？依赖注入使用全流程

C# 依赖注入详解

依赖注入基本概念

依赖注入的三种生命周期

依赖注入使用全流程

1. 定义接口和服务

2. 在Program.cs中注册服务

3. 在控制器中使用构造函数注入

4. 静态类使用容器服务的方法

方案一: 使用IServiceProvider获取服务

方案二: 将静态类改为实例类并注册为单例

完整示例代码

7.C# 依赖注入 有哪几种方式？

1. 构造函数注入（Constructor Injection）

2. 属性注入（Property Injection）

3. 方法注入（Method Injection）

8.C# sqlsugar和entityframeworkcore 区别以及特点适用场景

设计理念与定位

核心功能对比

Entity Framework Core 特点

SqlSugar 特点

适用场景

Entity Framework Core 适用场景

SqlSugar 适用场景

性能表现

总结

9.C# 项目中多线程的安全怎么保证，通常怎么设计，异步编程async await模型可以保证多线程安全么？并发线程安全怎么保证

1. 线程安全的实现方式

使用锁机制（Lock）

使用 Monitor 类

使用 Interlocked 类

使用线程安全集合

使用信号量（Semaphore）

2. 异步编程模型（async/await）与线程安全

3. 设计模式与最佳实践

无锁设计（Lock-Free）

不可变对象

线程局部存储（ThreadLocal）

4. 避免常见陷阱

避免嵌套锁

避免长时间持有锁

正确处理异常

总结

10.C# 项目中使用到微信支付，接口以及设计以及代码开发方面，需要注意哪些问题，开发流程是怎么样的

注意事项

1. 安全性保障

2. 数据一致性

3. 日志监控

微信支付接入流程概览

11.sqlserver数据库优化，从哪些方面考虑设计，如果要你设计数据库优化，你要从哪些方面考虑，说说你的看法

2.List<int > a = (1,2,3...,100);C#语法使用原生拉姆达表达式写法，筛选出包含9的，并且结果拼接上a，输出结果为List<string> b = (a9,a19,a29,...a99)

3.C# 跨域怎么写，写到哪里，原理是什么？

4.C# middleware 和filter的区别以及作用

6.C# 依赖注入怎么使用，有哪几个生命周期，如果一个静态类想使用容器的类，怎么通过依赖注入的方式使用？依赖注入使用全流程

7.C# 依赖注入有哪几种方式？