后端开发 文章

后端开发

2025-11-07 • 0k

数据防篡改实用方案：从原理到落地实现 - 数字签名与HMAC详解

数据防篡改实用方案：从原理到落地实现 在后端服务、文件传输、接口通信等场景中，数据完整性是不可忽视的安全底线 —— 无论是网络传输中的字节丢失，还是恶意攻击者篡改核心业务数据（如转账金额、订单信息），都可能引发严重的业务风险。 很多开发者知道用散列算法（如 SHA256）做数据校验，但容易陷入一个误区：如果篡改者同时修改数据和对应的散列值，接收方该如何识别？本文将从底层原理出发，拆解单纯散列校验的漏洞，通过简洁的代码示意，演示 “数字签名” 和 “HMAC” 两种防篡改方案，帮你快速落地数据完整性防护。 一、数据校验的核心逻辑：给数据加 “唯一指纹” 1. 基础原理 数据校验的本质是通过数学算法，将任意长度的原始数据转换为固定长度、独一无二的特征值（类似人类指纹），这个特征值被称为 “校验值”（散列值、校验位等）。 核心流程： 发送方：原始数据 → 校验算法（如 SHA256）→ 校验值 → 发送 “数据 + 校验值” 接收方：接收数据 → 相同校验算法 → 新校验值 → 对比 “新校验值” 与 “接收的校验值” 结论：一致则数据未篡改，不一致则数据异常 2. 散列算法的关键特性 散列算法是防篡改的基础，其安全性依赖两个核心特性： 抗碰撞性：不同数据几乎不可能生成相同散列值，哪怕修改 1 个字符（如 “123” 改为 “124”），散列值也会完全不同； 不可逆性：只能通过原始数据计算散列值，无法通过散列值反推原始数据。 3. 单纯散列校验的致命漏洞 单纯的 “数据 + 散列值” 方案存在明显缺陷：如果篡改者修改原始数据后，对篡改数据重新计算散列值，再将 “篡改数据 + 新散列值” 一起发送，接收方会误以为数据合法 —— 因为散列值本身没有 “身份标识”，无法证明是合法发送方生成的。

RSA HMAC 数字签名

阅读更多

后端开发

2024-12-03 • 0k

赋能企业级开发：ABP vNext 高级实践与核心功能深入解析

赋能企业级开发：ABP vNext 高级实践与核心功能深入解析 如果你认为 ABP vNext 只是一个帮你做 CRUD 的框架，那你就太小看它了。它是一个完整的、基于最佳实践的应用开发平台。本文将带你超越 Hello World，探索其如何在真实企业级项目中大放异彩。 在上一篇入门文章后，我们了解了 ABP 的基础。现在，让我们深入其更强大的功能，看看它如何解决实际开发中的复杂场景。 一、 模块化架构：构建复杂系统的基石 ABP 的模块化不仅是代码组织方式，更是架构设计哲学。 1. 定义与依赖 每个模块都是一个独立的单元。创建一个模块非常简单： [DependsOn( // 显式声明依赖 typeof(AbpAccountApplicationModule), typeof(AbpIdentityApplicationModule), typeof(YourModuleProjectDomainModule) // 依赖自己的领域层 )] public class YourModuleApplicationModule : AbpModule { public override void ConfigureServices(ServiceConfigurationContext context) { // 配置本模块的服务 Configure<AbpVirtualFileSystemOptions>(options => { options.FileSets.AddEmbedded<YourModuleApplicationModule>("YourCompany.YourModule"); }); } public override void OnApplicationInitialization(ApplicationInitializationContext context) { // 应用启动时的逻辑 var app = context.GetApplicationBuilder(); // ... 中间件配置 } } 2.

ABP vNext 企业级开发 模块化架构

阅读更多

后端开发

2024-06-27 • 0k

.NET Core Web API 过滤器完全指南：类型、用途与实战

在 .NET Core Web API 开发中，过滤器（Filter）是实现横切关注点解耦的核心组件。它能在请求处理的不同阶段拦截逻辑，统一处理权限验证、日志记录、异常捕获等通用需求，避免重复代码。本文将详细拆解 .NET Core Web API 内置的 5 类过滤器，分析其执行机制、核心用途，并提供可直接复用的实战示例。 一、过滤器核心概念：什么是过滤器？ 过滤器是 .NET Core 提供的请求拦截机制，本质是一套 “钩子（Hook）” 系统，能嵌入请求处理生命周期的关键节点。其核心价值在于： 解耦横切关注点：将日志、权限、异常处理等通用逻辑与业务逻辑分离； 统一管控：对所有接口或指定接口批量应用通用规则； 可扩展性：支持自定义过滤器，满足复杂业务场景。 所有过滤器遵循固定的执行顺序，从请求进入到响应返回，完整流程如下： 授权过滤器 → 资源过滤器 → 模型绑定 → Action 过滤器 → 执行 Action → Action 过滤器 → 结果过滤器 → 执行结果 → 结果过滤器 → 资源过滤器 → 响应返回 若任意阶段抛出异常，将直接触发异常过滤器处理。 二、5 类内置过滤器详解：用途 + 执行时机 1. 授权过滤器（AuthorizationFilter）：请求的 “第一道关卡” 核心作用 验证请求是否有权限访问接口，是所有过滤器中执行最早的组件。若验证失败，直接终止请求并返回 401（未授权）或 403（禁止访问），不执行后续逻辑。 内置实现 [Authorize]：标记需要授权的 Action/Controller，依赖 IAuthorizationService 校验身份（配合 JWT、Cookie 等认证方案）。支持角色、策略等精细化授权，示例： // 仅 Admin 角色可访问 [Authorize(Roles = "Admin")] [HttpGet("admin/data")] public IActionResult GetAdminData() => Ok("管理员数据"); [AllowAnonymous]：允许匿名访问，用于公开接口（如登录、注册），会跳过授权校验： [AllowAnonymous] [HttpPost("login")] public IActionResult Login(string username, string password) => Ok("登录成功"); 关键特点 仅关注 “是否允许访问”，不处理业务逻辑；

dotnet webapi filter

阅读更多

后端开发

2024-06-27 • 0k

string 类型深度解析：是值类型还是引用类型？

在 .NET 开发中，string 类型是我们日常使用最频繁的类型之一。但一个常见的疑问始终困扰着不少开发者：string 到底是值类型还是引用类型？其实答案很明确 ——string 本质是引用类型，但它兼具部分值类型的特性，这种特殊性也让它成为了 .NET 类型系统中极具代表性的存在。本文将从本质定义、特殊特性到实际验证，全面解析 string 类型的本质。 一、核心结论：string 是引用类型 从 .NET 类型系统的底层设计来看，string 完全满足引用类型的所有定义，这是不可动摇的核心事实。 1. 引用类型的核心判定依据 继承关系：string 直接继承自 System.Object（引用类型的基类），而非值类型专属的 System.ValueType； 存储位置：string 对象的实际内容存储在 托管堆 中，变量仅持有指向堆内存的 “引用地址”（类似指针）； 可空性：string 变量默认支持赋值为 null（表示不指向任何堆内存对象），而值类型（如 int、DateTime）默认非空，需通过 Nullable<T>（如 int?）才能支持 null； 引用传递特性：当把一个 string 变量赋值给另一个变量时，传递的是 “引用地址”，而非字符串内容的拷贝。 2. 代码验证：引用类型的本质 // 1. 变量 a 指向堆内存中的 "hello" 对象 string a = "hello"; // 2. 变量 b 拷贝的是 a 的引用地址，而非 "hello" 内容 string b = a; // 验证：a 和 b 指向同一个堆内存对象 Console.

string 值类型 引用类型

阅读更多

后端开发

2023-12-25 • 0k

天气查询API实现 | 后端开发最佳实践

1. 天气查询功能介绍 天气查询API在现代Web和移动应用中扮演着重要角色，它可以为用户提供实时天气数据、未来天气预报以及生活指数等关键信息。本文将详细介绍如何实现一个高效、稳定的天气查询服务，涵盖从API选择、异步编程实现到缓存优化的完整开发流程。 2. 天气API服务选择指南 在开发天气查询应用时，选择合适的API服务提供商至关重要。以下是几个主流的天气API服务对比： 和风天气API：国内数据覆盖全面，API文档完善，适合后端开发使用 OpenWeatherMap：全球天气数据服务，国际化支持好 高德地图天气API：国内覆盖较全面，适合本地化应用 百度地图天气API：与百度地图集成良好，适合地图应用场景 本文以和风天气API为例，详细讲解调用天气API的完整实现方案，包括API密钥获取、请求构建、响应解析和错误处理等关键环节。 3. 天气查询API代码实现 3.1 获取和风天气API密钥 在开始天气查询开发前，首先需要在和风天气开发者平台注册账号并获取API密钥。注册流程简单，完成后即可获得免费额度的API访问权限。 3.2 天气查询类实现 using System; using System.Collections.Generic; using System.Net.Http; using System.Threading.Tasks; using Newtonsoft.Json; public class WeatherAPI { private readonly string _apiKey; private readonly string _baseUrl; private readonly HttpClient _httpClient; public WeatherAPI(string apiKey) { _apiKey = apiKey; _baseUrl = "https://devapi.qweather.com/v7"; _httpClient = new HttpClient(); _httpClient.Timeout = TimeSpan.FromSeconds(10); } /// <summary> /// 实现获取指定位置的实时天气数据 /// 支持城市ID或经纬度查询 /// </summary> public async Task<Dictionary<string, object>> GetCurrentWeatherAsync(string location) { string url = $"{_baseUrl}/weather/now"; var parameters = new Dictionary<string, string> { { "key", _apiKey }, { "location", location } // 可以是城市ID或经纬度 }; try { using (var response = await _httpClient.

C#天气查询 ASP.NET Core开发 和风天气API调用

阅读更多

后端开发

2023-01-28 • 0k

过滤器、拦截器与 AOP：Java 开发中的三角关系解析

在Java开发中，过滤器和拦截器常被提及，它们与AOP（面向切面编程）的关系容易让开发者困惑。本文将深入解析三者之间的关系、核心区别与适用场景，并回答关键问题： “AOP能否替代过滤器和拦截器？” 通过技术拆解与实战案例，带你理清三者协作的正确姿势。 一、核心结论：三角协作，各司其职 过滤器和拦截器是AOP思想的实践工具，用于解决Web层的横切关注点，但仅覆盖请求处理流程的特定阶段。 AOP是更通用的编程范式，可作用于任意Java方法（如Service层逻辑），与HTTP请求无关。 三者执行顺序（从外到内）：Filter → Interceptor → AOP，层级递进，协同工作。 二、关键区别：技术层级、能力与边界 维度 过滤器（Filter） 拦截器（Interceptor） AOP 技术层级 Servlet容器（如Tomcat） Spring MVC框架 Spring框架或AspectJ 作用范围 所有HTTP请求（含静态资源） 仅Spring MVC的Controller请求 任意Spring管理的Bean方法 核心能力 操作原始HTTP流（请求/响应） 访问Web上下文（如HttpServletRequest） 方法级增强（如事务、日志） 典型场景 字符编码、跨域处理、安全头注入 登录认证、权限校验、接口日志 事务管理、缓存控制、性能监控 能否访问Spring Bean ❌（需特殊配置） ✅ ✅ 能否拦截静态资源 ✅ ❌ ❌ 三、误区澄清：AOP无法替代过滤器和拦截器 为什么AOP不能完全替代？ 技术层级不兼容： 过滤器：处理容器级协议问题（如修改原始请求体、设置字符编码），AOP无法触及HTTP原始流。 拦截器：处理Web层业务规则（如重定向、Session校验），AOP若在Service层实现，会导致逻辑与Web层耦合（例如定时任务触发不必要的权限校验）。 关键功能缺失： 静态资源处理、协议级配置（如CORS）必须由过滤器完成，AOP无法覆盖。 性能与可靠性风险： 用AOP替代过滤器处理高频静态资源，会造成不必要的动态代理开销，降低性能。 在AOP中通过RequestContextHolder获取请求对象，易在异步场景引发线程安全问题。 四、最佳实践：分层协作，各取所长

Java Spring AOP

阅读更多

后端开发

2022-12-06 • 0k

Spring 依赖注入：为什么构造器注入优于 @Autowired 字段注入？

在 Spring 开发中，依赖注入（DI）是我们每天都在使用的核心功能。很多开发者习惯直接在字段上加 @Autowired，因为这样写起来最快、最简洁。但你可能不知道，Spring 官方和社区早已将构造器注入（Constructor Injection）列为首选方式。 那么，@Autowired 字段注入和构造器注入到底有什么区别？为什么说后者更优秀？本文将从强制性、不变性、测试友好性、循环依赖、代码耦合等多个维度进行深度对比，并给出明确的最佳实践建议。 一、两种注入方式快速回顾 1. 字段注入（Field Injection） @Service public class UserService { @Autowired private UserRepository userRepository; // 直接写在字段上 public void doSomething() { userRepository.save(); } } 2. 构造器注入（Constructor Injection） @Service public class UserService { private final UserRepository userRepository; // Spring 4.3+ 如果只有一个构造器，可以省略 @Autowired public UserService(UserRepository userRepository) { this.userRepository = userRepository; } // 业务方法... } 配合 Lombok 可以更简洁： @Service @RequiredArgsConstructor public class UserService { private final UserRepository userRepository; } 二、核心区别一览表 维度 字段注入 (@Autowired on field) 构造器注入 依赖是否可为 null 可以（除非设置 required=true） 不可以，对象创建时必须提供所有依赖 依赖是否可变 可变（字段可被后续修改） 不可变（可声明为 final，线程安全） 测试友好性 差，必须启动 Spring 容器或使用反射 极好，直接 new 对象并传入 Mock 依赖 循环依赖检测 支持（三级缓存解决，但可能掩盖设计问题） 不支持，Spring 启动即失败，强制重构 与 Spring 耦合度 高，类明确依赖 Spring 注解 低，类是纯净的 POJO 代码可读性 隐式依赖，看构造器不知道需要什么 显式依赖，所有必需项一目了然 三、深入剖析：为什么构造器注入更优秀？ 1.

Java Spring 依赖注入

阅读更多

后端开发

2022-10-15 • 0k

.NET 版 StringJoiner：比 string.Join 更会「打扮」的字符串拼接器

告别 string.Join 的局限——用扩展方法轻松添加前缀和后缀 在日常开发中，字符串拼接恐怕是最常见的操作之一。.NET 自带的 string.Join 方法已经非常强大：性能好、支持泛型、能正确处理 null，用它来连接集合中的元素简直不要太方便。 但是，如果你写过 Java，可能会怀念 StringJoiner 类——它除了分隔符，还允许你指定前缀和后缀。例如 new StringJoiner(", ", "[", "]").add("A").add("B") 可以得到 "[A, B]"。这种写法在生成日志、SQL 片段、JSON 数组字符串等场景下非常实用。 那么，在 .NET 中能否也拥有这样的能力？当然可以。今天我们就来自己动手，为 IEnumerable<T> 写一个扩展方法，让它支持前缀和后缀，并且保持 string.Join 的高效和简洁。 一、原生 string.Join 的局限性 假设我们有一个水果列表： var fruits = new List<string> { "苹果", "香蕉", "橙子" }; 想要输出 "[苹果, 香蕉, 橙子]"，用 string.Join 只能做到中间部分： string middle = string.Join(", ", fruits); // "苹果, 香蕉, 橙子" string result = "[" + middle + "]"; // "[苹果, 香蕉, 橙子]" 虽然也不麻烦，但当拼接逻辑多次出现时，重复写前缀后缀会显得啰嗦，也容易出错。更好的方式是一次性声明“分隔符、前缀、后缀”。

C# .NET 扩展方法

阅读更多

后端开发

2022-08-24 • 0k

上传文件路径怎么写最稳？详解 ASP.NET 三种路径写法的区别

在 ASP.NET 项目里，文件上传、导出、日志落盘都离不开“路径”。很多人常见三种写法： Server.MapPath("~/Uploads/...") Server.MapPath("/Uploads/...") Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Uploads", ...) 看起来都能用，但它们的“参照点”不同，部署后表现也可能完全不一样。 1. Server.MapPath("~/Uploads/...")：基于应用根目录 ~ 表示当前 Web 应用根目录（virtual app root）。 var path = Server.MapPath("~/Uploads/2026/04/16"); 特点： 最符合 Web 应用语义 项目部署到虚拟目录（如 /MyApp）时仍然稳定 在 Controller/Page 中最推荐 适用场景： 上传文件 站内资源落盘 需要明确“当前应用目录”的所有场景 2. Server.MapPath("/Uploads/...")：基于站点根目录 / 表示IIS 站点根，不一定是你的应用根。（.net core /.net 6+ 已废弃） var path = Server.MapPath("/Uploads/2026/04/16"); 特点： 参照的是站点，不是应用 当应用是虚拟目录时，容易映射到“应用外”路径 多应用共站点时风险更高 适用场景： 你明确要访问站点级共享目录 对 IIS 站点结构有完全掌控 3. AppDomain.CurrentDomain.BaseDirectory：基于进程物理基目录 这是纯 .NET 物理路径方式，不经过虚拟路径解析。

ASP.NET C# 路径

阅读更多

后端开发

2021-08-24 • 0k

dotnet core 使用gRPC服务

什么是gRPC？ 在聊聊什么是gRPC前，我们先来聊聊什么是RPC。 RPC，全称Remote Procedure Call，中文译为远程过程调用。通俗地讲，使用RPC进行通信，调用远程函数就像调用本地函数一样，RPC底层会做好数据的序列化与传输，从而能使我们更轻松地创建分布式应用和服务。 请求信息使用 Protobuf 进行对象序列化压缩（IDL） 而gRPC，则是RPC的一种，它是免费且开源的，由谷歌出品。使用gRPC，我们只需要定义好每个API的Request和Response，剩下的gRPC这个框架会帮我们自动搞定。 使用gRPC 一、gRPC服务端 引用NuGet包 Grpc.AspNetCore Startup.cs 中 ConfigureServices 函数配置gRPC public void ConfigureServices(IServiceCollection services) { services.AddRazorPages(); //配置grpc services.AddGrpc(); } Configure 函数映射服务grpc类 public void Configure(IApplicationBuilder app, IWebHostEnvironment env) { if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } else { app.UseExceptionHandler("/Error"); app.UseHsts(); } app.UseHttpsRedirection(); app.UseStaticFiles(); app.UseRouting(); app.UseAuthorization(); //映射grpc服务类 app.UseEndpoints(endpoints => { endpoints.MapRazorPages(); endpoints.MapGrpcService<GreeterService>(); endpoints.MapGrpcService<LuCatService>(); }); } Program.cs 添加证书、设置监听端口 public static IHostBuilder CreateHostBuilder(string[] args) => Host.

dotnet grpc .NET Core

阅读更多