08 2023 档案
@ComponentScan注解详细介绍和使用示例
摘要：`@ComponentScan` 注解是 Spring 框架中的一个注解，用于指定要扫描的包路径，从而自动注册和管理 Spring 组件。 具体来说，`@ComponentScan` 注解的作用主要有以下几个方面： 1. 扫描组件：`@ComponentScan` 注解会自动扫描指定包路径下的类，并
@RefreshScope 注解和 @NacosValue 注解使用方式和适用场景
摘要：相同点： - 都用于实现属性或 bean 的动态刷新。 - 都需要配合 Spring Cloud Config 或 Alibaba Nacos 使用。 不同点： - 来源：`@RefreshScope` 注解是 Spring Cloud 提供的注解，可以与 Spring Cloud Config 配
@Value 注解和 @NacosValue 注解使用方式和适用场景
摘要：> 这两个注解都可以用于获取配置属性的值，但在使用方式和适用场景上有一些异同之处。 > 相同点： - 两者都可以将配置属性的值注入到类的字段或方法参数中。 - 都支持 Spring 表达式语言（SpEL）来引用其他属性或进行运算。 不同点： - 来源：`@Value` 注解是 Spring 框架提供
Java中面向切面编程@Around注解
摘要：一、@Around注解 在Java中，@Around注解是AspectJ框架中的一个切面注解，用于定义环绕通知（around advice）。 具体来说，@Around注解可以应用在切面类的方法上，用于包围目标方法的执行。当被@Around注解修饰的方法被调用时，它会在目标方法执行前和执行后拦截处理
外星人笔记本功能键关闭FN/Windows功能键
摘要：现象 比如f1-f12 等之类按键必须结合FN 使用，但是我们通常使用只想单按f1-f12功能键，而不使用 f1-f12 下面的win功能键 解决方案： FN+ESC 按键关闭，再按一次就是启动
Redis 数据库 keys 命令的模糊查询
摘要：
### 1、支持的通配符 - 第一种：* - 第二种：？ - 第三种：[] ### 2、* 通配符 #### 1、单个 * 模式 ```redis // 查询所有的key keys * ``` #### 2、双 * 模式，匹配任意多个字符 ```redis // key中含有keyword 的key
### 1、支持的通配符 - 第一种：* - 第二种：？ - 第三种：[] ### 2、* 通配符 #### 1、单个 * 模式 ```redis // 查询所有的key keys * ``` #### 2、双 * 模式，匹配任意多个字符 ```redis // key中含有keyword 的key
spring 中 @Validated/@Valid 注解的使用
摘要：
## 一、背景 日常开发过程中，经常遇到大量的参数进行校验, 在业务中还要抛出异常等校验信息, 在代码中相当冗长, 充满了 if-else 这种校验代码, 代码不够优雅，使用 spring 的 javax.validation 注解式参数校验，可以免去繁琐的校验。 ## 二、@Validated 注
## 一、背景 日常开发过程中，经常遇到大量的参数进行校验, 在业务中还要抛出异常等校验信息, 在代码中相当冗长, 充满了 if-else 这种校验代码, 代码不够优雅，使用 spring 的 javax.validation 注解式参数校验，可以免去繁琐的校验。 ## 二、@Validated 注
@Validated 注解和 @Valid 注解区别
摘要：
> Spring validation 验证框架对入参实体进行嵌套验证必须在相应属性（字段）加上 @Valid 而不是 @Validated_validated Spring Validation 验证框架对参数的验证机制提供了 @Validated（Spring's JSR-303 规范，是标准
> Spring validation 验证框架对入参实体进行嵌套验证必须在相应属性（字段）加上 @Valid 而不是 @Validated_validated Spring Validation 验证框架对参数的验证机制提供了 @Validated（Spring's JSR-303 规范，是标准
项目开发中，真的有必要定义VO，BO，PO，DO，DTO这些吗？
摘要：
存在即是合理的，业务复杂，人员协同要求高的场景下，这些规范性的东西不按着来虽然不会出错，程序照样跑，但是遵守规范会让程序更具扩展性和可读性，都是前辈血淋淋的宝贵经验，为什么不用？ 随着现在后端编程标准化程度越来越高，各种编程模型层出不穷。作为Java开发人员，大部分人不免要接触VO，BO，PO，DO
存在即是合理的，业务复杂，人员协同要求高的场景下，这些规范性的东西不按着来虽然不会出错，程序照样跑，但是遵守规范会让程序更具扩展性和可读性，都是前辈血淋淋的宝贵经验，为什么不用？ 随着现在后端编程标准化程度越来越高，各种编程模型层出不穷。作为Java开发人员，大部分人不免要接触VO，BO，PO，DO
