2401_86968005的博客

依赖管理：预先定义了特定场景下所需要的全部依赖。以为例，它就包含了Tomcat、SpringMVC等相关依赖，让开发者无需逐个查找和添加。自动配置：借助AutoConfigure模块来实现Bean的自动注册以及属性绑定等重要功能。比如，在Web开发场景中，它会自动配置，极大地简化了开发流程。简单概括来说，Starter的目标就是：开发者只需引入一个依赖，就能轻松搞定所有相关配置，实现快速开发。减少重复劳动。

引入组件依赖后，该组件才生效。允许开发者自定义生成器，以覆盖默认实现。可以通过配置开关来控制该组件是否启用。及其衍生注解通过“条件判断”这一机制，实现了Bean的“按需注册”，无疑是Spring Boot自动配置的核心所在。依赖引入时自动生效注解使得在引入特定依赖时，相关Bean能够自动生效，实现了与第三方库的无缝集成。允许自定义Bean覆盖默认实现注解赋予了开发者自定义Bean以覆盖默认实现的能力，避免了Bean的重复注册，增强了配置的灵活性。通过配置控制组件开关。

A：在实际项目中自定义自动配置类时，可以参考以下几点：首先，借鉴的方式，将自定义配置类声明为配置类，例如使用注解。其次，对于组件扫描，如果自定义类所在包不在默认扫描范围内，可以使用来指定扫描路径。最重要的是关于自动配置的核心部分，我们可以参考和的机制。自定义配置类可以通过类似@Import的方式引入相关类，并在类中使用@Bean来声明需要注册的Bean。同时，结合系列注解来控制Bean的注册条件，比如根据项目是否引入特定依赖（使用）或者容器中是否缺少特定Bean（使用）等条件来精准配置。

自动配置，简单来讲，就是当你在项目里引入某个依赖时，Spring Boot会敏锐地自动检测到这个依赖，然后悄无声息地将与之相关的Bean注册到IOC容器中，完全不需要开发者手动去进行声明。可以用一个简洁的流程来概括：“引入依赖 → 直接使用Bean”，这中间所有繁琐的配置步骤都被Spring Boot巧妙地省略了。自动配置的核心要义在于，Spring Boot凭借约定和规则，自动完成Bean的注册过程，让开发者能够彻底摆脱配置细节的束缚。

起步依赖，比如，它本身并不包含实际的代码，更像是一份精心编写的 “购物清单”，也就是预定义的依赖描述符。这份清单详细地列出了某个特定场景（如 Web 开发）所需的所有依赖及其对应的版本。可以想象，当我们要进行 Web 开发时，这个 starter 就像一位经验丰富的购物向导，为我们列出了做这道菜（开发 Web 应用）所需要的所有食材（依赖），而 Maven 则会按照这份清单，自动为我们采购（下载）所需的食材，让我们能够轻松地开始烹饪（开发）。

第三方Bean就像是来自远方的客人，它们是来自各种依赖库的类，比如OSSClient、RedisTemplate等。由于这些类的源代码并不在我们的掌控范围内，无法直接对其进行修改，所以不能像对待自己编写的类那样，直接添加@Component等注解来让Spring管理它们。例如，当我们使用阿里云OSS服务时，OSSClient就是一个典型的第三方类。那么，如何才能让Spring顺利地管理它呢？答案就是@Bean注解。场景类型推荐作用域声明方式典型案例无状态组件（如Controller）

优先级配置形式示例适用场景1命令行参数部署时临时调整配置，方便快捷，适用于临时改变某个配置值2Java系统属性用于设置全局JVM级别的配置，对整个JVM进程生效，适合一些通用的全局参数设置3作为项目内的默认配置，适合放置一些相对固定的默认参数4推荐用于项目内的默认配置，语法简洁，可读性强，适合复杂配置结构5与yml功能一致，但使用相对较少核心原则就是：外部配置（命令行参数、Java系统属性）的优先级始终高于内部配置文件。

为了让操作更加便捷，我们封装一个名为// 声明ThreadLocal，泛型指定存储Integer类型（员工ID）// 存值：将员工ID存入当前线程的ThreadLocal// 取值：从当前线程的ThreadLocal中获取员工ID// 删值：清空当前线程的ThreadLocal，必须调用无疑是解决 “同一请求内跨组件数据传递” 问题的得力工具，在操作日志、权限校验等众多场景中都有着不可或缺的作用。

要将上述美好的设想转化为实际可运行的代码，我们需要巧妙解决两个关键问题：一是选择何种通知类型最为合适，二是怎样精准地匹配目标方法。接下来，我们创建一个独特的 “标签”，即用于标记需要记录日志的方法的注解。@Target(ElementType.METHOD) // 仅作用于方法@Retention(RetentionPolicy.RUNTIME) // 运行时生效// 纯标记注解，无需定义属性。

连接点（JoinPoint）指的是那些可以被AOP控制的方法。Spring把这些连接点抽象成了JoinPoint对象，通过这个对象，我们能够获取到目标方法执行时的各种关键信息。这就好比给我们提供了一个“透视镜”，让我们可以清晰地看到方法执行时的上下文情况。连接点（JoinPoint）是Spring AOP对“可被增强的方法”的一种抽象表述。它不仅仅代表方法本身，更囊括了方法执行时的全部动态信息，比如参数、目标类等。

execution(访问修饰符?返回值 包名.类名.?方法名(方法参数) throws 异常?。其中，访问修饰符（如publicprotected等）、包名和类名、throws异常声明这几部分是可以省略的。但强烈建议包名和类名部分不要省略，以保持表达式的明确性，避免不必要的全项目扫描，提高匹配效率。。用于匹配标识有特定注解的方法。它就像是给方法贴上了一个特殊的“标签”，只要方法上带有这个“标签”（特定注解），就会被匹配到。创建注解类：使用@interface来定义注解类。命名规范：建议使用功能名 +

默认顺序：按照切面类名字母排序，前置通知按字母正序执行，后置通知按字母倒序执行。手动控制：使用@Order(数字)来指定优先级，数字越小，前置通知越早执行，后置通知越晚执行。

如果需要控制方法执行流程，例如进行权限校验，优先使用@Around通知。仅需在方法执行前进行预处理，如记录参数日志，选择@Before通知。若要记录方法的返回值，使用通知。处理异常情况则使用通知。对于必须执行的收尾工作，如资源清理，采用@After通知。

辨范围：连接点是“全量”的潜在可增强方法，切入点则是经过筛选后的“子集”，是实际被增强的方法。明关系：切面构建起通知与切入点的绑定关系，而代理对象是在目标对象的基础上融入通知逻辑所形成的。懂流程：AOP依靠动态代理实现增强功能，其调用链路为“代理对象→通知→目标对象→通知→结果”。

AOP并非一种具体技术，而是一种编程思想，专门用于解决“横切关注点”问题。AOP，即Aspect Oriented Programming（面向切面编程），它是一种通过“横切”而非“纵向继承”来达成代码复用的思想。它能在不改变原始业务方法的前提下，为一批方法统一增添通用逻辑，像日志记录、耗时统计、事务控制等功能都能轻松实现。切面类是AOP的关键，用于封装通用逻辑，比如耗时统计。// 1. @Component：将类交给Spring管理// 2. @Aspect：标识这是一个AOP切面类。

不妨设想一下，我们需要一种能够跨平台使用、防止信息篡改且能直接携带用户信息的身份凭证，JWT正是这样一种存在。JWT（JSON Web Token）是一种基于JSON的轻量级令牌格式，主要用于在通信双方之间安全地传递身份信息。它通常呈现为一段由两个点（.）分隔的字符串，例如。这一字符串中蕴含了用户身份识别所需的关键信息以及安全验证所依赖的全部内容。

令牌是服务器在用户成功登录后生成的一段加密字符串，这段字符串中蕴含着用户的身份信息。它就像是用户在数字系统中的“入场券”，证明用户已经通过身份验证。客户端在后续与服务器的交互过程中，需要携带这张“入场券”，而服务器则通过验证“入场券”的有效性，来决定是否允许用户访问相应的资源。在现代Web开发中，特别是在前后端分离、多端适配以及分布式部署的场景下，令牌方案凭借其独特的优势，已成为替代Cookie和Session的最优选择。手动实现令牌机制不仅成本高，而且容易出现安全漏洞，因此建议直接采用JWT等标准化技术。

Session作为“服务器端存储”的早期方案，成功解决了Cookie存在的安全性问题，为Web应用的安全发展起到了重要的推动作用。它开创了一种新的思路，将关键数据存储在服务器端，有效降低了数据被篡改的风险。对于小型单体项目而言，Session的实现简单易懂，能够快速搭建起会话跟踪机制，满足项目的基本需求。同时，它也是开发者理解会话跟踪原理的基础，为进一步学习和掌握更复杂的技术提供了铺垫。

核心机制：Cookie会话跟踪的核心机制是通过HTTP协议的“Set - Cookie”响应头和“Cookie”请求头来实现的。服务器通过“Set - Cookie”响应头向浏览器发送Cookie信息，浏览器存储Cookie后，在后续请求中通过“Cookie”请求头自动携带Cookie信息给服务器，服务器再对Cookie进行验证，以此来跟踪用户会话。数据流向。

登录校验，简单来说，就是验证用户是否已经成功登录，以此来判断是否给予用户访问系统各项功能的权限。它就像是系统的一道“安全门”，只有通过身份验证的用户才能顺利进入系统，访问其所需的资源。会话（Session）指的是用户从打开浏览器访问服务器，到关闭浏览器的整个过程。例如，用户打开浏览器，登录系统，查看员工列表，最后关闭浏览器，这一系列操作构成“一次会话”。在此期间的“登录请求”“查看列表请求”等，都属于该会话内的请求。可以把会话想象成用户与系统之间的一场“交流之旅”，从开始到结束的整个过程就是一次会话。

若系统缺失登录功能，员工薪资、客户信息等敏感数据将毫无屏障，任何人都能随意访问，这无疑严重违背了系统安全的基本准则。登录功能宛如用户踏入系统的首道关卡，其核心使命在于核实用户身份的合法性，只有输入准确的用户名与密码，方可顺利进入系统。接下来，本文将全面阐释登录功能的开发全过程，从核心逻辑解读、接口设计，到依托三层架构实现以及最后的测试联调，助力你熟练掌握构建安全、可靠登录功能的方法。

为了实现接口功能，我们采用“Controller→Service→Mapper”三层架构，每个层次都承担着独特且重要的职责。Controller 层的主要职责是接收前端发送的请求，调用 Service 层获取数据，并以标准格式返回给前端。@RequestMapping("/report") // 统计接口统一前缀@Slf4j@Autowired// 性别统计接口：返回ECharts饼图所需数据。

在 MyBatis 框架中，我们需要定义一个 Mapper 接口来执行上述 SQL 查询。@Mapper// 查询职位统计数据，返回List<Map>（每条记录为{pos:名称, number:人数}）@Mapper注解表明这个接口是 MyBatis 的 Mapper 接口，Spring 会自动扫描并管理它。方法负责执行查询操作，并返回一个，其中每个Map对象代表一条统计记录，pos作为职位名称的键，number作为人数的键。

当我们着手将数据可视化时，百度 ECharts 无疑是众多开发者的首选工具之一，特别是在处理员工职位统计这类场景时，它展现出了独特的优势。

/ 建议放在com.itheima.exception包下@RestControllerAdvice // 标识为全局异常处理器，自动拦截Controller层异常@Slf4j // 用于记录异常日志// 异常处理方法将在这里定义：这是一个组合注解，它融合了和的功能。其中，负责定义全局异常处理逻辑，而则确保异常响应能够以JSON格式返回，方便前端接收和处理。@Slf4j：这是Lombok提供的注解，通过它可以方便地使用log对象记录异常日志，简化了日志记录的代码。全局异常处理器借助和。

在开发员工信息更新功能的过程中，你可能遭遇过这样令人困惑的情况：明明只想修改员工的用户名，然而数据库里的性别、薪资等字段却莫名其妙地变成了null。这种情况的根源往往在于使用了“静态SQL”。静态SQL不管前端是否传递某个字段，都会强制更新所有预先设定的字段，对于前端未传递的字段，就会将其置为null。这显然不符合我们的业务需求。如何借助MyBatis的动态SQL来实现“按需更新”，也就是只更新前端实际传递的字段，从而让员工信息更新功能变得更加灵活和安全。

接口设计：采用PUT方法进行全量更新，以JSON格式传递参数，这种设计符合RESTful规范，使得接口语义清晰，易于前后端理解和交互。三层架构：控制器层负责接收参数，将前端请求转化为后端可处理的对象；服务层承担核心业务逻辑处理，包括协调数据库操作并通过事务管理确保数据一致性；映射层专注于执行具体的SQL语句，实现对数据库的增删改操作。三层之间分工明确，协同工作，构建了一个稳健的系统架构。关键策略。

Slf4j@Autowired// 根据ID查询员工信息（用于修改回显）@GetMapping("/{id}") // 路径参数{id}public Result<Emp> getEmpById(@PathVariable Integer id) { // @PathVariable绑定路径参数log.info("查询员工信息，ID：{}", id);在这段代码中，类负责处理与员工相关的HTTP请求。通过注解，将该控制器映射到“/emps”路径下。

控制器：采用结合接收参数，并通过实现符合RESTful风格的接口设计。这种方式能够灵活接收前端传递的多个ID，并清晰地定义接口的功能和请求方式。服务层：借助注解保证删除操作的原子性，严格按照先删从表（工作经历表）再删主表（员工表）的顺序执行，有效避免外键约束错误，确保数据的一致性和完整性。映射器层：运用MyBatis的foreach标签动态生成in (ids)条件，灵活处理不定数量的ID，实现高效的批量删除SQL语句构建。

接口设计：认识到单条删除是批量删除的特殊情况，共用一个接口可以有效减少代码冗余，提高开发效率和代码的可维护性。在设计接口时，充分考虑业务需求之间的共性，能够使系统架构更加简洁和优化。参数接收：推荐使用配合的方式接收参数，这种方式不仅能够方便地对参数进行各种操作，还与MyBatis等持久层框架的交互更加友好，便于后续对数据进行处理和持久化操作。关联删除：在删除主表（如emp表）数据之前，必须先删除与之关联的从表（如emp_expr表）数据，以避免因外键约束而导致的错误。

首先，定义一个配置实体类，用于封装OSS的相关参数，并通过@ConfigurationProperties注解绑定配置前缀。// 绑定配置前缀"aliyun.oss"@Component // 交给Spring容器管理@Data // Lombok自动生成getter/setter// 属性名与配置文件中"aliyun.oss"下的key一致// 可添加更多参数，如超时时间、最大文件大小等// 默认值在这个配置实体类中，通过@ConfigurationProperties注解的。

解决本地存储痛点：阿里云OSS支持分布式部署，这意味着在分布式系统中，所有服务器都能轻松访问OSS上存储的头像，不会出现本地存储时图片无法共享的问题。而且不用担心服务器磁盘容量的限制，因为OSS提供了海量的存储空间。简化开发：通过工具类的封装，接口开发变得非常简单，只需要几行代码就可以实现文件上传到OSS的功能，开发者无需关心底层复杂的存储细节，提高了开发效率。高可用性。

Bucket：可以将其理解为存储文件的“容器”，类似于本地的“文件夹”，但它在全球范围内具有唯一性，例如“myproject - oss”。每个Bucket的名称必须是独一无二的，只能包含小写字母、数字以及短横线。它是组织和管理文件的基本单元，所有的Object都存储在Bucket中。Object：即具体存储的文件，等同于本地的“文件”。每个Object除了包含文件内容本身，还拥有文件名以及元数据等信息。例如，我们上传的一张图片、一份文档都可以看作是一个Object。AccessKey。

如果默认的文件大小限制无法满足实际需求，我们可以通过在文件中进行配置来自定义限制。spring:servlet:multipart:max-file-size: 10MB # 单个文件最大大小max-request-size: 100MB # 单次请求总大小（含所有文件和表单数据）这里的单位支持MB、KB等，例如1024KB就等于1MB。通过调整和的值，我们可以根据实际业务需求灵活设置文件上传的大小限制。小型应用或内部系统。

前端三要素：确保前端表单的以及包含的输入框，这是实现文件正确上传的基础。后端接收：在后端使用类型参数接收文件，并且要特别注意参数名与前端表单name属性值的匹配，保证文件能够正确接收。存储关键：及时将临时文件保存到永久目录，同时要注意避免文件名冲突。可以采用生成唯一文件名、目录分离等方式，确保文件存储的正确性和可管理性。

属性为我们提供了一种自定义事务回滚规则的途径，能够突破Spring默认的回滚限制。通过该属性，我们可以明确指定哪些异常类型需要触发事务回滚。其语法形式为@Transactional(rollbackFor = 异常类型.class)，并且可以同时指定多个异常类型。// 配置rollbackFor = Exception.class，所有异常都回滚throw new Exception("姓名不能为空");// 此时会触发回滚在这种配置下，无论是还是Exception。

在开发“新增员工”这类看似常规的功能时，却常常隐藏着令人头疼的数据一致性问题。想象一下，你满心欢喜地看到员工基本信息成功保存到数据库中，然而，工作经历却因为代码异常（比如SQL语句出现错误）未能保存。这就导致员工表中存在记录，而工作经历表却空空如也，数据变得残缺不全。这种“部分成功”的情况，严重违背了业务规则，给系统的数据完整性带来了极大的挑战。不过，别担心，Spring的事务管理机制，能轻松化解这个难题。只需要一个简单的。

事务（Transaction）是一组不可分割的操作集合。这就好比把多个紧密相关的操作打包在一起，它们在执行过程中，就像一个紧密协作的团队，要么所有操作都成功完成并提交到数据库，要么只要有一个操作出现问题，就全部失败并从数据库中撤销，绝对不会出现“部分成功”的中间状态。

在后端开发的实际场景中，我们常常会面临复杂的数据操作需求。例如，当新增一名员工后，紧接着需要使用该员工的ID去批量插入其工作经历；或者要一次性删除多个特定ID对应的部门数据。这些场景引出了两个关键技术点：如何在数据库插入记录后获取自动生成的主键，以及怎样通过遍历集合动态生成适用于批量操作的SQL语句。MyBatis作为一款流行的持久层框架，其提供的主键返回机制以及foreach标签，为解决这些问题提供了便捷而高效的方案。

在程序开发的旅程中，成功实现功能仅仅是迈出了第一步。真正的挑战在于如何让代码不仅“能用”，更要“好用”，达到优雅与高效的完美结合。当面对需要接收多个参数（如员工条件分页查询中的6个分页与条件参数），以及需要根据用户输入灵活调整查询条件（用户输入什么就查什么，不输入则不限制）的场景时，传统的开发方式往往显得力不从心，既笨拙又容易出错。本文将重点关注两个关键的优化方向：一是请求参数的对象化封装，旨在解决参数零散的问题；二是动态SQL的运用，以实现查询条件的灵活拼接。