个人技术分享

spring mvc实现自定义验证器Validator

Validator框架凭借其遵循的JSR-303规范，不仅强化了后端数据入口的防御机制，还通过减少重复劳动，优化了开发流程，是提升软件质量和开发速度不可或缺的工具。在现代应用开发中，其重要性不言而喻，是确保应用健壮性和数据准确性的有力保障。JSR-303，作为Java参数验证的标准，旨在通过预定义的注解来规范数据校验，如@NotNull、@Email、@Size等，极大地减轻了开发者的工作负担。

WebMvcConfigurer配置不当导致鉴权失败

这样导致springboot中springmvc的自动配置全部失效，这方面所有的配置都得自己手动配置，而我们项目中的公用基础依赖的鉴权是又要依赖spring mvc的自动配置，线程上下文中无法注入session信息，导致接口调用时鉴权失败。公司是公用同一套基础依赖，所以我也为自己的项目配置了一个拦截器，我在启动项目后我请求了项目中的一个接口，session鉴权通过，没有出现他那种情况。这个注解，我一般都不加Enable注解，springboot中一般不需要。开头的注解，我推测应该是这个注解有问题。

SpringMVC

过滤器的设计初衷是为了处理 Servlet 请求和响应，它们并不属于 Spring 容器的管理范围，因此在过滤器中无法直接通过 Spring 上下文来访问 Spring 托管的 Bean。控制器：一个或多个 Servlet 对象，根据视图提交的请求进行控制，即将请求转发给处理业务逻辑的 JavaBean，并将处理结果存放到实体模型 JavaBean 中，输出给视图显示。图为SpringMVC的一个较完整的流程图，实线表示SpringMVC框架提供的技术，不需要开发者实现，虚线表示需要开发者实现。

数据库中锁的机制和MVCC协议以及隔离级别

数据库中为什么需要「锁」，顾名思义，锁就是为了解决并发问题的，就像是一个柜子加了一把锁，那么其他没有钥匙的人都打不开这个柜子（无法写入数据）。在 MySQL 的 InnoDB 引擎里面，锁和索引、隔离级别都是有密切关系的，锁是依赖于索引来实现的。如果一个查询用了索引，那么会用行锁；如果没用到任何索引，那么就会用表锁。此外，在 MySQL 里面，间隙锁和临键锁是只工作在可重复读这个隔离级别下的。

MySQL事务与MVCC

事务是数据库管理系统（DBMS）执行过程中的一个逻辑单位（不可再进行分割），由一个有限的数据库操作序列构成（多个DML语句，select语句不包含事务），要不全部成功，要不全部不成功。A 给B 要划钱，A 的账户-1000元， B 的账户就要+1000元，这两个update 语句必须作为一个整体来执行，不然A 扣钱了，B 没有加钱这种情况就是错误的。那么事务就可以保证A 、B 账户的变动要么全部一起发生，要么全部一起不发生。

MySQL事务与MVCC

事务是数据库管理系统（DBMS）执行过程中的一个逻辑单位（不可再进行分割），由一个有限的数据库操作序列构成（多个DML语句，select语句不包含事务），要不全部成功，要不全部不成功。A 给B 要划钱，A 的账户-1000元， B 的账户就要+1000元，这两个update 语句必须作为一个整体来执行，不然A 扣钱了，B 没有加钱这种情况就是错误的。那么事务就可以保证A 、B 账户的变动要么全部一起发生，要么全部一起不发生。

Spring MVC 源码分析之 DispatcherServlet#getHandler 方法

本文简单分析了 Spring MVC 工作流程中获取 Handler 的实现，整个过程先通过 Request 请求的一些属性，从整个 HandlerMapping 中获取到具体的 Handler，然后和当前请求应该使用的拦截器一起，通过责任链模式构造出一个拦截器链，看似是从 HandlerMapping 中获取处理当前请求的 Handler，实则最后返回的是一个拦截器链，希望本篇的细节剖析可以帮助大家建立更深的映像。欢迎提出建议及对错误的地方指出纠正。

MVC和MVVM

也就是在Controller里面把Model的数据赋值给View来显示（或者是View接收用户输入的数据然后由Controller把这些数据传给Model来保存到本地或者上传到服务器）将Model转化成View，即将后端传递的数据转化成所看到的页面。将View转化成Model，即将所看到的页面转化成后端的数据。MVVM模式的核心，它是连接view和model的桥梁。View层代表的是视图、模版，负责将数据模型转化为UI展现出来。：用于处理应用程序数据逻辑的部分，通常负责在数据库中存取数据。

【SpringMVC】_设置响应状态码与Header

按照状态码的含义而言，401状态码应属于请求错误，但后端设计的响应页面仍然在前端成功显示，这应是状态码为200的结果。设置响应的Header在开发中并不常见，大多数数据都可以通过其他方式如body部分进行传递。另一方面，完全可以修改接口类型来实现这种目的，比如使用对象或Map，无需生硬地使用这种方式。通过这种方式实现Content-Type的类型很少使用，注意状态码与页面的显示无关，此处是指HTTP状态码。一方面，当返回的值与设置的属性值不匹配时会设置失败；HTTP响应首行显示：状态码确实为401。