我的学习小铺

到底什么问题该问同事

Sat, 01 Aug 2026 00:00:00 GMT

哪些问题该问同事

刚入职新公司，很多新人会陷入两个极端：要么胆战心惊什么都不敢问，导致进度卡壳；要么事无巨细当个“伸手党”，惹人厌烦。

到底掌握怎样的提问尺度，才能既快速融入团队，又展现专业素养？请熟记以下三大准则。

一、大胆开口：哪些问题该问同事？#

当遇到公司特有的、缺乏文档说明的、或者涉及业务逻辑的问题时，不要自己瞎琢磨，一定要及时向同事请教。

1. 缺乏文档支持的“开发流程”问题#

如果公司没有提供清晰的文档，以下流程必须问清楚，避免做无用功：

代码规范： 团队的开发规范和 Git 协同开发流程是怎样的？
开发前置要求： 动手写代码前，是否需要先出接口文档？是否强制要求编写单元测试？
部署与联调： 公司的项目部署流程是怎样的？前后端联调是选择本地直连，还是将后端服务部署到对应测试环境进行联调？

2. 缺乏文档支持的“环境配置”问题#

环境搭不好，代码跑不起来。遇到卡壳及时问：

环境区分： 公司目前有哪些环境？是否提供专属的开发环境？
中间件要求： 本地搭建开发环境时，必须安装哪些中间件？具体需要哪个版本？
服务器权限： 登录公司服务器是使用 xshell 直接连接，还是必须通过堡垒机？如果是堡垒机，具体该如何使用？
配置文件与依赖： 项目有多个配置文件时，本地启动该激活哪个环境？公司是否使用 Maven 私服？如果是，找同事索要包含私服配置信息的 settings.xml。

3. 公司专属的“业务与需求”问题#

涉及到公司赚钱的核心业务和内部工具，网上的教程是搜不到的：

需求存疑： 需求文档描述不明确，或者在开发过程中发现需求有不合理、逻辑不通的地方，立刻找产品或老员工对齐。
业务黑话： 遇到不懂的业务简称、专有词汇或理不清的业务主流程，大胆问，这是快速懂业务的必经之路。
内部平台使用： 公司自研的 Bug 管理平台或小众项目管理工具不知道怎么用时，可以请教。（注意提问方式： 明确告诉同事你要做什么具体操作卡住了，而不是丢一句“这系统怎么用”）。

二、职场红线：哪些问题绝对不要问？#

职场不是学校，同事没有义务手把手教你基础知识。以下三类问题，问了就会被打上“不专业”的标签。

1. 随手可查的“懒人问题”#

不要把同事当成你的免费搜索引擎。

百度/谷歌能解决的基础问题： 例如“Swagger 怎么使用？”、“@Param 注解是什么意思？”、“SpringBoot 多配置文件怎么选择生效？”。这些纯技术基础，请自行解决。
公司文档里明文写着的： 例如“公司代码仓库地址在哪？”、“Maven 私仓地址是多少？”、“项目怎么启动？”。提问前，先翻遍新人文档！
代码里写得清清楚楚的： 例如“数据库连接信息是什么？”、“启动的服务端口是多少？”、“Redis 连接密码是什么？”。自己去项目的 application.yml 或 properties 文件里看！

2. 宽泛、空洞的“情绪化问题”#

❌ 错误示范： “我这个功能做不出来，怎么办？”
❌ 错误示范： “这个系统怎么这么复杂，我完全看不懂，你能给我讲讲吗？”
点评： 这类问题暴露了你没有经过任何思考。要把问题具体化，说清楚你梳理到了哪一步、哪里看不懂，让别人看到你是在思考的。

3. 同一个问题多次问#

好记性不如烂笔头。别人解答过的问题、给过的配置项，立刻拿小本本或文档记下来。同一个坑掉进去两次，是非常消耗同事耐心的行为。

三、提问的艺术：如何高效向同事请教？#

总结来说，一个高质量的职场提问应该包含这三个要素：背景 + 你的尝试 + 具体的卡点。

你可以套用这个黄金提问句式：

“（称呼），关于**【具体某个任务/功能】，我在尝试【你做的操作】时遇到了问题。我已经查阅了【某某文档/看了某段代码】，但我对【具体某个细节点】**还是不太理解。请问你有空帮我指点一下这个具体的地方吗？”

这样提问，既展示了你的独立解决问题能力，又极大地降低了同事解答的成本。

定时任务Quartz框架的使用

Sat, 01 Aug 2026 00:00:00 GMT

一、基础概述#

分布式定时任务鼻祖Quartz架构图

1、什么是Quartz？#

简单说：Quartz是一个强大的企业级定时任务框架，用来在指定时间、按照复杂规则自动执行代码。

生活中的例子：

每天凌晨2点备份数据库
每小时同步一次上游系统数据
每月最后一天晚上23点生成对账报表

2、为什么学Quartz？#

你可能会问：Spring的@Scheduled不是也能做定时任务吗？

对比项	@Scheduled	Quartz
使用难度	极简，加个注解即可	相对复杂，有体系概念
动态修改	不支持（改了要重启服务器）	完全支持动态增删改查
持久化	不支持（全在内存）	支持（任务信息存数据库，重启不丢）
集群支持	不支持（多台机器会重复跑）	支持（自带集群分布式锁机制）
任务管理	代码里写死，像个黑盒	可接入前端页面动态管理

结论：简单且固定的场景用 @Scheduled，需要动态管理、怕重启丢任务、有多台服务器集群的场景，必须用 Quartz（或 XXL-Job 等）。

3、Quartz三个核心概念#

概念	说明	类比
Job（任务）	具体要干的事	具体的工作内容
Trigger（触发器）	定义什么时候执行	工作时间表
Scheduler（调度器）	把Job和Trigger组合起来	老板，统筹安排工作

Plaintext

1
Job（做什么） + Trigger（什么时候做） = Scheduler（安排执行）

二、快速入门（最简内存版 Demo）#

这部分用于快速理解 Quartz 的骨架，任务信息保存在内存中，重启后重置。

第一步：引入依赖#

只要引入 Spring Boot 的官方 Starter，底层依赖全部帮你搞定。

XML

1
<dependency>
2
    <groupId>org.springframework.boot</groupId>
3
    <artifactId>spring-boot-starter-quartz</artifactId>
4
</dependency>

第二步：创建任务类（🔥 优雅写法）#

避坑： 很多老教程教你实现 Job 接口，然后告诉你无法使用 @Autowired。在 Spring Boot 中，强烈建议继承 QuartzJobBean，这样就可以直接快乐地注入任何 Service 了！

Java

1
import org.quartz.JobExecutionContext;
2
import org.quartz.JobExecutionException;
3
import org.springframework.beans.factory.annotation.Autowired;
4
import org.springframework.scheduling.quartz.QuartzJobBean;
5
import org.springframework.stereotype.Component;
6
import java.util.Date;
7

8
@Component
9
public class MyJob extends QuartzJobBean {
10

11
    // 继承 QuartzJobBean 后，直接使用 @Autowired 注入，非常优雅！
12
    @Autowired
13
    private OrderService orderService;
14

15
    @Override
16
    protected void executeInternal(JobExecutionContext context) throws JobExecutionException {
17
        System.out.println("定时任务执行了：" + new Date());
18
        // 直接调用你的业务逻辑
19
        orderService.doSomething();
20
    }
21
}

展开收起

第三步：创建配置类（老板分配工作）#

Java

1
@Configuration
2
public class QuartzConfig {
3

4
    @Bean
5
    public JobDetail myJobDetail() {
6
        // 创建JobDetail，指定任务类
7
        return JobBuilder.newJob(MyJob.class)
8
                .withIdentity("myJob", "group1")  // 任务名称和分组
9
                .storeDurably()                    // 即使没有Trigger也保留在调度器中
10
                .build();
11
    }
12

13
    @Bean
14
    public Trigger myJobTrigger() {
15
        // 创建触发器，每10秒执行一次
16
        return TriggerBuilder.newTrigger()
17
                .forJob(myJobDetail())             // 关联上面的 JobDetail
18
                .withIdentity("myTrigger", "group1")
19
                .withSchedule(SimpleScheduleBuilder.simpleSchedule()
20
                        .withIntervalInSeconds(10)  // 每10秒执行
21
                        .repeatForever())           // 无限重复
22
                .build();
23
    }
24
}

展开收起

启动项目后，任务就会自动每 10 秒执行一次了。

三、两种核心 Trigger（触发器）#

1、SimpleTrigger（简单触发器）#

适用场景： 简单的重复执行，比如“每隔 X 分钟执行一次”、“延迟 X 秒后执行 10 次”。

Java

1
// 延迟立即开始，每5秒执行一次，共执行10次
2
Trigger trigger = TriggerBuilder.newTrigger()
3
        .startNow()
4
        .withSchedule(SimpleScheduleBuilder.simpleSchedule()
5
                .withIntervalInSeconds(5)
6
                .withRepeatCount(10))
7
        .build();

2、CronTrigger（Cron触发器）#

适用场景： 复杂的时间表达式，比如“每天凌晨2点”、“每周五下午4点”。

Java

1
// 每天凌晨2点执行
2
Trigger trigger = TriggerBuilder.newTrigger()
3
        .withSchedule(CronScheduleBuilder.cronSchedule("0 0 2 * * ?"))
4
        .build();

🚨 注意：Quartz Cron 与 Linux Crontab 的区别

Quartz 的 Cron 支持秒级（有 6~7 位），而 Linux 通常只有 5 位（没有秒）。

Quartz 规定**“日”和“周”必须有一个用 ? 隔开**以防冲突，Linux 不支持 ?。

强烈建议使用在线工具生成并测试：https://cron.ciding.cc/

四、高阶必杀技：并发控制（极度重要）#

痛点： 假设你的任务是每 5 分钟同步一次大量数据。如果某次同步数据量极大，跑了 8 分钟才跑完，但第 5 分钟的时候，Quartz 又会启动一个新线程去跑同步，导致两个线程同时操作同一批数据，引发严重的死锁或脏数据！

解决方案：加一个 @DisallowConcurrentExecution 注解。

Java

1
import org.quartz.DisallowConcurrentExecution;
2

3
@Component
4
@DisallowConcurrentExecution // 🔥加上这个注解，Quartz就会等上一次任务彻底跑完，再跑下一次，绝不并发！
5
public class SafeDataSyncJob extends QuartzJobBean {
6
    @Override
7
    protected void executeInternal(JobExecutionContext context) {
8
        // 耗时的业务逻辑...
9
    }
10
}

五、动态管理任务（企业级真实场景）#

在真实的开发中，以下这些代码通常会被写在 Service 层，然后暴露成 Controller 接口。前端会画一个漂亮的后台管理页面，运营人员在页面上点击“新增”、“启动”、“暂停”按钮，本质上就是调用了这里的代码，从而实现不重启服务器就能掌控定时任务。

通过 SpringBoot 自动注入的 Scheduler 对象，我们可以为所欲为：

Java

1
@Service
2
public class QuartzManageService {
3

4
    @Autowired
5
    private Scheduler scheduler;
6

7
    // 1. 动态添加任务
8
    public void addJob(String jobName, String jobGroup, String cronExpression, Class<? extends Job> jobClass) throws Exception {
9
        JobDetail jobDetail = JobBuilder.newJob(jobClass).withIdentity(jobName, jobGroup).build();
10
        Trigger trigger = TriggerBuilder.newTrigger().withIdentity(jobName, jobGroup)
11
                .withSchedule(CronScheduleBuilder.cronSchedule(cronExpression)).build();
12
        scheduler.scheduleJob(jobDetail, trigger);
13
    }
14

15
    // 2. 暂停任务
16
    public void pauseJob(String jobName, String jobGroup) throws Exception {
17
        scheduler.pauseJob(JobKey.jobKey(jobName, jobGroup));
18
    }
19

20
    // 3. 恢复任务
21
    public void resumeJob(String jobName, String jobGroup) throws Exception {
22
        scheduler.resumeJob(JobKey.jobKey(jobName, jobGroup));
23
    }
24

25
    // 4. 立刻手动触发执行一次（不管时间到没到，常用于测试或数据紧急补偿）
26
    public void triggerJob(String jobName, String jobGroup) throws Exception {
27
        scheduler.triggerJob(JobKey.jobKey(jobName, jobGroup));
28
    }
29
}

展开收起

六、企业级生产实战（持久化配置）#

内存模式的致命弱点： 一旦服务器重启，所有动态添加的任务、修改的时间全部丢失！
企业级做法： 开启 JDBC 持久化，让 Quartz 把任务数据、执行状态全部存到 MySQL 里。

1、准备数据库表#

前往 Quartz 官网下载自带的 SQL 脚本（包含了 QRTZ_JOB_DETAILS、QRTZ_TRIGGERS 等十来张表），在你的 MySQL 数据库中执行建表。

2、修改 application.yml#

只要加这几行配置，Spring Boot 会自动接管一切，从内存模式切换为数据库模式：

YAML

1
spring:
2
  quartz:
3
    job-store-type: jdbc  # 🔥核心：告诉Spring使用数据库存储任务信息
4
    jdbc:
5
      initialize-schema: never  # 不让它每次启动建表，我们手动建好了
6
    properties:
7
      org:
8
        quartz:
9
          jobStore:
10
            class: org.quartz.impl.jdbcjobstore.JobStoreTX
11
            driverDelegateClass: org.quartz.impl.jdbcjobstore.StdJDBCDelegate
12
            isClustered: true  # 🔥核心：开启集群支持。部署多台机器时，它们会抢数据库锁，保证任务只执行一次！
13
            clusterCheckinInterval: 10000 # 集群心跳检测时间

有了这两步，你的项目就已经具备了分布式调度、防重跑、防宕机丢失的企业级能力！

七、新人避坑指南#

坑点	正确做法（避坑）
任务类无法注入 Bean，报空指针	不要实现 Job 接口，改为继承 QuartzJobBean，即可完美使用 @Autowired。
任务执行时间过长，导致互相踩踏	在任务类名上方加上 @DisallowConcurrentExecution 注解，禁止并发。
Linux 和代码的 Cron 语法冲突	Quartz 的 Cron 有秒位，且日和周必须有一个用 ?。拿不准时一定要用在线生成工具，不要盲猜。
发版重启后，之前加的任务全没了	生产环境务必配置 spring.quartz.job-store-type=jdbc，走数据库持久化。
业务出了 Bug，导致定时任务彻底停摆	在 executeInternal 方法里，业务逻辑一定要 try-catch 包裹，并打上 log.error。千万别把异常抛给 Quartz 调度器，否则容易导致后续调度卡死。

八、技术选型对比（我该用哪个？）#

维度	@Scheduled	Quartz	XXL-Job / Elastic-Job
上手难度	极低（1个注解）	中等（需懂底层概念）	中等（需额外部署调度中心）
动态启停/改时间	❌ 不支持	✅ 支持（需自己写接口和页面）	✅ 支持（自带漂亮的网页控制台）
集群防重跑	❌ 不支持	✅ 支持（基于数据库锁）	✅ 支持（支持分片广播等高级玩法）
适用场景	适合单体小项目，时间固定的简单任务	适合不希望引入外部系统，但要求高可用、动态改任务的项目	适合大中型企业、微服务架构，任务海量且需要完善的监控告警

💡 终极建议：

能简单就简单，小项目无脑用 @Scheduled。
如果项目不能引入重量级的外部框架，但又要防重启、集群防重跑，直接上 Quartz 持久化模式。
如果公司体量大、任务多，运维有现成的平台，不要自己造轮子，直接接入 XXL-Job。

定时任务Scheduled注解的使用

Sat, 01 Aug 2026 00:00:00 GMT

一、基础概述#

1、什么是定时任务？#

简单说：定时任务就是到点自动执行的代码。

生活中的例子：

每天凌晨2点备份数据库
每小时同步一次第三方数据
每月1号生成报表

工作中常见的定时任务场景：

场景	执行频率
数据同步	每小时/每天
报表生成	每天/每周/每月
数据清理	每天凌晨
消息推送	定时发送
订单超时取消	每分钟检查

2、Spring Scheduled是什么？#

Spring框架自带的定时任务功能，使用简单，只需要加注解就能实现。

优点：

不需要额外引入框架
使用简单，加注解就行
适合简单的定时任务

缺点：

默认单线程，任务会串行执行
不支持集群（每台机器都会执行）
没有可视化管理和监控

二、快速入门#

第一步：开启定时任务支持#

在启动类上加 @EnableScheduling 注解：

1
@SpringBootApplication
2
@EnableScheduling  // 开启定时任务支持
3
public class Application {
4
    public static void main(String[] args) {
5
        SpringApplication.run(Application.class, args);
6
    }
7
}

第二步：创建定时任务#

在方法上加 @Scheduled 注解：

1
@Component
2
public class MyScheduledTask {
3

4
    @Scheduled(cron = "0 0 2 * * ?")  // 每天凌晨2点执行
5
    public void executeTask() {
6
        System.out.println("定时任务执行了：" + new Date());
7
        // 这里写业务逻辑
8
    }
9
}

就这样，一个定时任务就完成了！

三、@Scheduled注解参数详解#

1、cron表达式（最常用）#

格式：

1
秒 分 时 日 月 周 [年]

位置	含义	允许值	特殊字符
1	秒	0-59	, - * /
2	分	0-59	, - * /
3	时	0-23	, - * /
4	日	1-31	, - * ? / L W
5	月	1-12	, - * /
6	周	0-7	, - * ? / L #

特殊字符说明：

字符	说明	例子
*	所有值	* * * * * ? 每秒执行
?	不指定值	日和周只能有一个用?
-	范围	0 0 9-17 * * ? 9点到17点每小时
,	列举	0 0 9,12,15 * * ? 9点、12点、15点
/	间隔	0 0/30 * * * ? 每30分钟
L	最后	0 0 0 L * ? 每月最后一天

常用cron表达式：

表达式	说明
0 0 12 * * ?	每天中午12点
0 0 0 * * ?	每天凌晨0点
0 0/30 * * * ?	每30分钟
0 0 2 * * ?	每天凌晨2点
0 0 0 1 * ?	每月1号凌晨
0 0 9-17 * * ?	每天9点到17点每小时
0 0 9 * * MON-FRI	周一到周五每天9点
0 0/5 * * * ?	每5分钟

在线生成工具： https://cron.ciding.cc/

新人技巧： 不用背cron表达式，用在线工具生成就行。

2、fixedDelay（固定延迟）#

特点： 上一次执行完成后，等待指定时间再执行。

1
@Scheduled(fixedDelay = 5000)  // 上次执行完5秒后再执行
2
public void task1() {
3
    System.out.println("执行任务：" + new Date());
4
    // 假设执行了3秒
5
    // 那么下次执行是：执行完成时间 + 5秒
6
}

适合场景： 任务执行时间不固定，需要等上次执行完再执行的情况。

3、fixedRate（固定频率）#

特点： 不管上次是否执行完，每隔固定时间执行一次。

1
@Scheduled(fixedRate = 5000)  // 每5秒执行一次
2
public void task2() {
3
    System.out.println("执行任务：" + new Date());
4
}

适合场景： 需要固定频率执行的任务，如心跳检测。

4、initialDelay（首次延迟）#

特点： 第一次延迟指定时间后再开始执行。

1
@Scheduled(initialDelay = 10000, fixedRate = 5000)
2
// 启动后10秒开始执行，之后每5秒执行一次
3
public void task3() {
4
    System.out.println("执行任务：" + new Date());
5
}

适合场景： 项目启动后需要延迟一段时间再执行的任务。

5、参数对比#

参数	说明	使用场景
cron	精确时间点	每天凌晨、每小时等
fixedDelay	上次执行完后再等	执行时间不固定的任务
fixedRate	固定频率执行	心跳、监控等
initialDelay	首次延迟	项目启动后延迟执行

四、实际工作中的示例#

示例1：每天凌晨同步数据#

1
@Component
2
@Slf4j
3
public class DataSyncTask {
4

5
    @Autowired
6
    private DataService dataService;
7

8
    @Scheduled(cron = "0 0 2 * * ?")  // 每天凌晨2点执行
9
    public void syncData() {
10
        log.info("开始同步数据");
11
        try {
12
            dataService.syncFromThirdParty();
13
            log.info("数据同步完成");
14
        } catch (Exception e) {
15
            log.error("数据同步失败", e);
16
        }
17
    }
18
}

展开收起

示例2：每5分钟检查超时订单#

1
@Component
2
@Slf4j
3
public class OrderTimeoutTask {
4

5
    @Autowired
6
    private OrderService orderService;
7

8
    @Scheduled(cron = "0 0/5 * * * ?")  // 每5分钟执行
9
    public void checkTimeout() {
10
        log.info("开始检查超时订单");
11
        int count = orderService.cancelTimeoutOrders();
12
        log.info("取消了{}个超时订单", count);
13
    }
14
}

示例3：定时清理临时文件#

1
@Component
2
@Slf4j
3
public class FileCleanTask {
4

5
    @Scheduled(cron = "0 0 3 * * ?")  // 每天凌晨3点执行
6
    public void cleanTempFiles() {
7
        log.info("开始清理临时文件");
8
        // 删除7天前的临时文件
9
        File tempDir = new File("/tmp");
10
        // 清理逻辑...
11
        log.info("临时文件清理完成");
12
    }
13
}

示例4：带有任务开关的定时任务（真实工作场景必备）#

业务痛点：

本地开发抢数据： 本地启动项目时，如果不小心触发了定时任务，会把测试环境的数据处理掉，影响测试同事。
线上紧急止血： 线上定时任务出现严重 Bug，如果代码里没有开关，只能紧急发版或者直接停机。

解决方案： 结合配置文件（配合 Nacos / Apollo 等动态配置中心使用效果最佳）实现任务的动态控制。

application.yml 配置：

YAML

1
# 定时任务开关配置
2
task:
3
  user-sync:
4
    enabled: true  # 生产环境设为 true，本地开发环境设为 false

Java 代码实现：

Java

1
@Component
2
@Slf4j
3
public class UserSyncTask {
4

5
    @Autowired
6
    private UserService userService;
7

8
    // 从配置文件中读取开关状态。冒号后面的 false 是默认值（防备没配报错）
9
    // 如果公司使用了 Nacos 或 Apollo，修改配置后这里的值会动态生效，无需重启服务
10
    @Value("${task.user-sync.enabled:false}")
11
    private boolean isTaskEnabled;
12

13
    @Scheduled(cron = "0 0/10 * * * ?")  // 每10分钟执行一次
14
    public void syncUser() {
15
        // 1. 任务开关判断（核心防御逻辑）
16
        if (!isTaskEnabled) {
17
            log.info("【用户同步定时任务】全局开关已关闭，本次跳过执行...");
18
            return;
19
        }
20

21
        log.info("【用户同步定时任务】开始执行...");
22
        try {
23
            // 2. 执行核心业务逻辑
24
            userService.syncUserData();
25
            log.info("【用户同步定时任务】执行成功");
26
        } catch (Exception e) {
27
            // 3. 异常捕获，防止单次报错导致后续不再调度
28
            log.error("【用户同步定时任务】执行发生异常", e);
29
        }
30
    }
31
}

展开收起

🔥 进阶写法（更优雅的 Spring 原生方式）： 如果你希望在本地环境彻底不加载这个定时任务（连 Bean 都不创建），可以使用 @ConditionalOnProperty 注解代替代码里的 if 判断：
Java
1
@Component
2
@Slf4j
3
// 只有当配置文件中 task.user-sync.enabled=true 时，这个定时任务才会生效
4
@ConditionalOnProperty(name = "task.user-sync.enabled", havingValue = "true")
5
public class UserSyncTask {
6

7
    @Scheduled(cron = "0 0/10 * * * ?")
8
    public void syncUser() {
9
        // 直接写业务逻辑，不需要再做 if 判断了
10
    }
11
}
注意：@ConditionalOnProperty的方式只能在项目启动时决定是否开启，不支持不重启服务动态切换。真实工作中可根据实际需求选择这两种开关方式。

五、多线程配置（进阶）#

问题：默认单线程#

1
@Scheduled(cron = "0/5 * * * * ?")
2
public void task1() throws InterruptedException {
3
    Thread.sleep(10000);  // 执行10秒
4
    System.out.println("任务1");
5
}
6

7
@Scheduled(cron = "0/5 * * * * ?")
8
public void task2() {
9
    System.out.println("任务2");
10
}
11
// task2要等task1执行完才能执行

解决方案：配置线程池#

1
@Configuration
2
@EnableScheduling
3
public class ScheduleConfig implements SchedulingConfigurer {
4

5
    @Override
6
    public void configureTasks(ScheduledTaskRegistrar taskRegistrar) {
7
        // 配置10个线程
8
        taskRegistrar.setScheduler(Executors.newScheduledThreadPool(10));
9
    }
10
}

配置后，多个定时任务可以并行执行。

六、常见问题#

1、定时任务不执行？#

检查：

启动类有没有加 @EnableScheduling
类有没有加 @Component
cron表达式是否正确
定时任务注解@Scheduled修饰的方法不能有入参

2、任务执行时间过长影响其他任务？#

解决：

配置线程池，让任务并行执行
或者优化任务执行效率

3、多台服务器都会执行怎么办？#

Scheduled不支持集群，每台服务器都会执行。

解决方案：

使用XXL-Job等分布式任务调度框架
或者用数据库锁让只有一台服务器执行

七、注意事项#

记得打日志：定时任务要记录执行情况
异常处理：加try-catch，避免异常导致任务停止
执行时间：避免任务执行时间超过间隔时间
集群问题：Scheduled不支持集群，每台机器都会执行
线程池：多个任务建议配置线程池
执行时间错开：系统中如果有大量定时任务，把执行时间错开，不要出现某一时刻大量定时任务同时执行的现象
方法签名的硬性要求：被@Scheduled修饰的方法必须且只能返回 void，且不能有任何入参。如果加了入参或者返回值，Spring 容器在初始化调度器时会直接报错或忽略。

该如何正确处理异常信息

Sat, 01 Aug 2026 00:00:00 GMT

异常处理是 Java 开发中非常重要的一个知识点。

很多新人在处理异常的时候，要么不知道什么时候该 try-catch、什么时候该抛出异常，要么 try-catch 里面什么都不做，直接把异常”吞掉”。

这两种做法都是不对的。

什么时候抛异常、什么时候 try-catch 处理异常，然后 try-catch 处理异常该怎么处理？

一、什么时候 try-catch#

当你不想让调用方察觉到异常时，就用 try-catch 悄悄接住：只把日志写足，别把异常抛出去。

同样，当你不想让一次异常中断整个流程、导致后续代码无法运行时，也用 try-catch 把它拦下来。

更进一步，把 try-catch 当成异常场景下的”降级开关”：一旦出事，立刻捕获，记录日志、返回默认值或缓存数据，让用户依旧能看到页面，让业务流程继续走下去。

1、隐藏异常，不让调用者感知异常，并做降级处理#

典型的场景是：一个页面有核心数据和推荐数据两部分，推荐数据来自一个不太稳定的外部服务。如果推荐服务挂了，不应该让整个页面都报错，而是返回空列表，确保核心功能正常。

1
@Service
2
@Slf4j
3
public class ProductService {
4
    @Autowired
5
    private RecommendService recommendService; // 可能不稳定的推荐服务
6

7
    public ProductDetail getProductDetail(Long productId) {
8
        ProductDetail detail = productDao.getById(productId);
9
        try {
10
            // 获取商品推荐列表（非核心功能）
11
            List<Product> recommendations = recommendService.getRecommendations(productId);
12
            detail.setRecommendations(recommendations);
13
        } catch (Exception e) {
14
            // 核心：捕获所有异常，确保详情页主功能不受影响
15
            log.warn("获取商品[{}]推荐列表失败，将返回空推荐列表", productId, e);
16
            detail.setRecommendations(Collections.emptyList()); // 降级：返回空列表
17
        }
18

19
        return detail; // 主商品信息一定正常返回
20
    }
21
}

展开收起

这种写法的关键是：日志要写足，降级逻辑要合理，不要什么都不做。

2、对原始异常进行包装#

当需要对原始异常信息进行包装的时候，也需要使用 try-catch。

这个时候在 try-catch 里面抛出的异常，应该是自定义异常。因为自定义异常返回的信息是清晰明了的，能告诉用户目前出现了什么情况，而不是直接把原始异常信息暴露给用户。

直接把原始异常信息暴露出去，有两个问题：

用户体验差：用户看到一堆技术栈信息，完全不知道发生了什么
安全隐患：原始异常可能包含数据库 IP、表名、SQL 语句等敏感信息

错误的示例：

1
public User login(String username, String password) throws SQLException {
2
    // 直接调用 DAO，可能抛出 SQLException
3
    return userDao.findByUsernameAndPassword(username, password);
4
}

如果数据库连接失败，前端可能收到包含数据库 IP、表名、SQL 语句片段的错误信息，体验极差且不安全。

正确的做法：

1
// 1. 首先，定义一个业务异常
2
public class AuthenticationException extends RuntimeException {
3
    public AuthenticationException(String message, Throwable cause) {
4
        super(message, cause);
5
    }
6
}
7

8
// 2. 在 Service 层进行包装
9
public User login(String username, String password) {
10
    try {
11
        User user = userDao.findByUsernameAndPassword(username, password);
12
        return user;
13
    } catch (Exception e) { // Spring 对 SQLException 等的包装
14
        // 1. 关键：记录原始异常，供后续排查
15
        log.error("用户[{}]登录时数据访问异常", username, e);
16
        // 2. 关键：抛出一个对上游和用户友好的业务异常
17
        throw new AuthenticationException("系统繁忙，请稍后再试！");
18
    }
19
}

展开收起

这种写法的关键是：原始异常记到日志里，给用户和上游抛出友好的业务异常。

二、什么时候抛出异常#

在程序执行过程中，遇到核心业务前提条件不满足或关键流程出现不可恢复的错误，导致后续所有操作变得无意义或不可能成功时，此时就应该抛出异常并终止当前执行流。

简单来说：条件不满足就别往下走了，直接抛异常。

1
public void payOrder(Order order, Payment payment) {
2

3
    // 条件1：订单状态检查
4
    if (!"PENDING".equals(order.getStatus())) {
5
        // 后续支付逻辑已无意义，立即抛出！
6
        throw new IllegalOrderStateException(
7
            "订单[id=" + order.getId() + "]当前状态为" + order.getStatus() + "，无法支付。"
8
        );
9
    }
10

11
    // 条件2：支付金额校验
12
    if (payment.getAmount().compareTo(order.getTotalAmount()) != 0) {
13
        // 金额不匹配，支付必然失败，立即抛出！
14
        throw new PaymentAmountMismatchException(
15
            "支付金额[" + payment.getAmount() + "]与订单总额[" + order.getTotalAmount() + "]不符。"
16
        );
17
    }
18

19
    // 条件3：执行核心支付（只有所有前提满足，才执行到这里）
20
    try {
21
        paymentGateway.execute(payment);
22
    } catch (BankGatewayException e) {
23
        // 支付本身失败，同样抛出业务异常
24
        throw new PaymentFailedException("银行支付处理失败，请重试");
25
    }
26

27
    // 更新状态（只有一切成功，才执行到这里）
28
    order.setStatus("PAID");
29
    orderRepository.update(order);
30
}

展开收起

抛异常的核心原则：后续代码已经没有意义执行了，就立刻抛出，不要继续往下走。

三、总结#

场景	处理方式	关键点
非核心功能异常	try-catch + 降级	日志写足，返回默认值
原始异常不友好	try-catch + 自定义异常	记录原始异常，抛出友好信息
核心前提不满足	直接抛出异常	后续无意义，立即终止
不可恢复的错误	直接抛出异常	配合业务异常类使用

该以什么心态面对工作中的困难

Sat, 01 Aug 2026 00:00:00 GMT

该以什么心态面对工作中的困难#

在工作中遇到困难是非常正常的事情。尤其是刚进入公司的新人，在面对项目代码、业务逻辑、系统架构时，很多内容都是第一次接触。

所以首先要明确一件事：

遇到困难是正常的，不遇到困难反而是不正常的。

遇到困难时，第一步不是慌，也不是急着否定自己，而是：

先让自己沉下心来，认真思考，不要浮躁。

如果刚进入公司就什么问题都没有，往往说明你接触的事情还不够复杂，或者你还没有真正开始承担核心任务。

关键不是“有没有困难”，而是：

遇到困难时，你是如何面对和处理的。

一、先接受困难是工作的一部分#

很多新人在刚进入公司时，会产生一种错觉：

别人好像什么都会
自己好像什么都不会
一遇到问题就觉得是自己太菜

但实际上，真实的工作环境中：

老员工也会遇到问题

老员工也会遇到问题
复杂问题也需要查资料、调试、沟通
很多问题都不是一下就能解决的

区别只是：

（1）老员工遇到问题时更冷静

（2）更知道从哪里入手解决

所以，当你遇到困难时，首先要做的是：

接受困难是工作的一部分，而不是能力不足的证明。

二、不要一遇到问题就自我否定#

新人在遇到困难时，最容易陷入的一种状态就是：

1、容易陷入自我否定的状态#

做不出来 → 觉得自己很菜
被指出问题 → 觉得自己不适合这个行业
卡住一会儿 → 开始怀疑人生

这种状态其实对解决问题是没有任何帮助的，只会让自己越来越焦虑。

2、很多问题的产生并不一定是因为你能力不够#

需要明白的是，很多问题的产生，可能来自：

（1）项目本身的问题

项目代码本身比较复杂
老代码存在历史问题
系统之间联动比较多

（2）沟通和理解的问题

需求描述不够清晰
业务逻辑比较绕

所以，当你遇到问题的时候，不要第一时间否定自己。

更合理的做法是：

先冷静下来
分析问题本身
找到解决问题的路径

三、学会拆解问题，而不是被问题压住#

面对困难时，一个非常重要的能力就是：

把一个看起来很大的问题拆解成多个小问题。

1、拆解问题的例子#

例如，你可能会遇到这样的情况：

“这个需求我完全不会做。”

但如果进一步拆解，你会发现问题可能是：

不清楚需求逻辑
不知道相关代码在哪里
不知道接口怎么调用
不知道数据库表结构

2、一步步解决小问题#

当你把问题拆解之后，就可以一步一步解决：

先理解需求
找相关代码
看接口逻辑
查数据库结构
再开始写代码

很多看起来很复杂的问题，其实都是由很多小问题组成的。

只要一步一步解决，小问题解决完，大问题自然也就解决了。

四、不要长时间自己硬扛#

新人还有一个非常常见的问题：

卡住很久，也不愿意问别人。

1、不愿意问别人的原因#

原因通常是：

怕问了显得自己很菜
怕打扰别人
怕别人觉得自己什么都不会

2、不会问问题比问问题更严重#

但实际上，在工作中：

不会问问题，比问问题更严重。

因为如果你一直卡住：

任务进度会被拖慢
可能影响整个需求的进度
最后问题还是要被发现

3、更好的处理方式#

更好的方式是：

先自己尝试解决
查资料、查代码、查日志
如果一段时间仍然没有进展，就及时沟通

在提问的时候，也尽量做到：

说明你已经尝试过什么
具体卡在哪里
哪些地方不理解

这样别人也更容易帮你。

五、把困难当成学习机会#

很多新人在工作中会有一种想法：

“怎么这么多问题，太难了。”

但从另一个角度来看：

困难越多，成长也越快。

1、真正让你成长的是困难#

因为真正让你成长的，往往不是那些简单的任务，而是那些：

一开始看不懂的代码
一开始不会处理的需求
一开始不知道怎么解决的问题

2、每解决一个问题就是一次成长#

每解决一个问题，你都会多掌握一部分知识。

慢慢地，你就会发现：

以前看不懂的代码，现在能看懂了
以前不会写的功能，现在能写出来了
以前很难的需求，现在觉得也没那么难

这就是成长的过程。

六、保持耐心，不要急于求成#

技术能力的提升，本身就是一个长期过程。

1、新人常见的心态#

很多新人在刚进入行业时，会希望：

很快就能变得很厉害
很快就能什么都会
很快就能独立解决所有问题

2、技术成长需要积累#

但现实是：

技术成长是一个积累的过程，不可能一蹴而就。

所以，在面对困难时，不要太着急，也不要因为短时间的挫折就否定自己。

只要你：

愿意学习
愿意思考
遇到问题愿意解决

随着时间的积累，你的能力一定会慢慢提升。

该以什么样的心态面对新公司

Sat, 01 Aug 2026 00:00:00 GMT

一、先认可自己#

首先，要先认可自己。

能够在现在这样的就业环境下，靠自己的学习拿到 offer，本身就说明你并不是完全不行。公司在招聘时，不可能只面试你一个人，而是会在多个候选人里做筛选。你能够最终拿到 offer，说明你在当时的面试过程中，至少有一些地方是被认可的。

所以，进入新公司之后，不要一上来就把自己放得特别低，觉得自己什么都不行。你可以承认自己经验不足、基础不够扎实，但也要承认：

既然能够通过面试进入公司，就说明自己具备一定的能力基础。

这种认可自己，不是盲目自信，而是建立一个比较正常的起点。如果一开始就完全否定自己，后面遇到一点问题，就会很容易陷入自我怀疑。

二、认清现实#

面对新公司，既不能盲目乐观，也不能过度自卑。更重要的是，要认清现实：既要看到有利的一面，也要看到自己真实存在的短板。

1、有利的一面#

（1）能拿到 offer，说明你已经通过了一轮筛选#

公司在招聘时，通常会面试不止一个人。你能够从这些候选人中脱颖而出，被最终录用，说明你在某些方面已经得到了面试官的认可。这是你应该自豪的，比较你是通过短短几个月的学习，就能够跟很多真实工作几年的人在一个起点了。

（2）把你招进来的人，也希望你能尽快进入状态#

一般来说，能够参与面试并拍板录用你的人，在团队里至少是有一定话语权的。既然他决定把你招进来，那他通常也希望你后面能尽快上手、稳定下来，而不是希望你一进来就表现很差。如果，你表现的不好，别人也会怀疑他的能力，他面子上也挂不住。所以，招你进来的人，包括HR，天然的是会希望你也表现好的。

（3）你是带薪学习，学习的过程，又有工资拿#

如果你目前不具备完整的真实开发经验，那么进入公司之后，其实就是一个“带着工作去学习”的过程。

你一边在赚工资，一边在积累真正的项目经验、沟通经验、推进经验。

所以，只要这个公司还能让你学到东西，就不要因为一时遇到困难，就立刻想着离职。因为很多时候，离开并不能解决问题，只是把当前的问题延后了。如果底层能力和方法没有建立起来，换到下一个公司，类似的问题大概率还会继续出现。

2、不利的一面#

（1）缺少真实工作经验，容易犯低级错误#

很多刚入职的新人，虽然已经通过学习进入了行业，但在真正写业务代码时，仍然容易出现一些低级问题，比如：

参数考虑不全
边界情况遗漏
业务流程理解不到位
容易写出 bug

这很正常，不要因为这些问题就否定了自己。要清楚的知道，这些都是正常的。当前最应该做的是，要知道自己该做什么，而不是陷入到内耗的情绪之中。

（2）知识储备还不够扎实#

能够进入这个行业，并不代表自己已经什么都会了。很多时候，我们只是通过一段时间的集中学习，具备了进入岗位的基本能力，但很多知识其实还是一知半解。

所以，拿到工作之后，不要产生“终于上岸了，以后不用学了”的错觉。真正开始工作以后，学习才刚刚开始。它是什么，它怎么用

（3）不熟悉职场沟通和推进方式，容易陷入内耗#

新人刚进公司时，很多问题并不是技术本身，而是：

不知道怎么问问题
不知道怎么汇报进度
不知道怎么和前端、测试、产品沟通
一卡住就只会自己焦虑

如果这些问题处理不好，就很容易陷入内耗，看起来每天很忙，实际上推进得很慢。

三、正确的心态应该是什么？#

面对新公司，最好的心态不是“我很牛，我肯定没问题”，也不是“我太菜了，我肯定不行”，而是：

先认可自己有进入这个岗位的基础，同时也承认自己目前还有很多不足，然后用一种愿意学习、愿意适应、愿意推进的态度去面对新环境。

也就是说：

不要妄自菲薄
也不要盲目乐观
先稳定心态
再一点点把工作能力补起来

工作中Dubbo的使用

Sat, 01 Aug 2026 00:00:00 GMT

一、什么是Dubbo？#

Dubbo是阿里巴巴开源的Java RPC框架，用于实现服务的远程调用和治理。在微服务架构中，不同的服务部署在不同的机器上，服务之间需要相互调用，Dubbo就是帮你完成这件事的。

简单说：Dubbo就是让一个服务能调用另一个服务的方法，就像调用本地方法一样简单。

1、为什么需要Dubbo？#

场景	不用Dubbo	用Dubbo
服务间调用	自己写HTTP请求，手动处理序列化	像调用本地方法一样调用远程服务
服务管理	不知道有哪些服务可用	自动注册和发现服务
负载均衡	自己实现	内置多种负载均衡策略
服务监控	手动统计	自带监控中心

2、Dubbo的核心角色#

角色	说明	类比
Provider（提供者）	暴露服务的应用，提供服务接口的实现	餐厅的厨师，负责做菜
Consumer（消费者）	调用远程服务的应用	顾客，点菜消费
Registry（注册中心）	服务注册与发现的地方	餐厅的菜单，告诉你有哪些菜
Monitor（监控中心）	统计服务的调用次数和耗时	餐厅的账本，记录每道菜被点了多少次

3、Dubbo的调用流程#

1
1. Provider启动 → 向Registry注册自己的服务地址
2
2. Consumer启动 → 向Registry订阅需要的服务
3
3. Registry → 把Provider的地址列表推送给Consumer
4
4. Consumer → 根据地址列表，直接调用Provider（不再经过Registry）
5
5. Monitor → 统计调用信息

dubbo调用关系

二、注册中心的选择#

Dubbo支持多种注册中心，不仅限于Zookeeper，你可以根据项目实际情况选择合适的注册中心：

注册中心	说明	适用场景
Zookeeper	Apache开源的分布式协调服务，Dubbo最经典的注册中心	传统项目，团队对ZK比较熟悉
Nacos	阿里开源的注册中心和配置中心，同时支持AP和CP模式	Spring Cloud Alibaba技术栈项目，需要同时做配置管理
Redis	基于Redis实现的注册中心	轻量级项目，已有Redis基础设施

工作中最常用的是Zookeeper和Nacos两种，下面以这两种为例进行整合演示。具体用哪个取决于你们公司的技术栈，入职后问一下同事即可。

三、SpringBoot整合Dubbo#

1、引入依赖#

父工程引入依赖：

1
<!-- Dubbo -->
2
<dependency>
3
    <groupId>org.apache.dubbo</groupId>
4
    <artifactId>dubbo-bom</artifactId>
5
    <version>${dubbo.version}</version>
6
    <type>pom</type>
7
    <scope>import</scope>
8
</dependency>

各个子模块引入依赖——根据注册中心选择对应的依赖：

使用Zookeeper作为注册中心：

1
<!-- dubbo -->
2
<dependency>
3
    <groupId>org.apache.dubbo</groupId>
4
    <artifactId>dubbo-spring-boot-starter</artifactId>
5
    <version>3.0.9</version>
6
</dependency>
7
<dependency>
8
    <groupId>org.apache.dubbo</groupId>
9
    <artifactId>dubbo-dependencies-zookeeper-curator5</artifactId>
10
    <type>pom</type>
11
    <exclusions>
12
        <exclusion>
13
            <artifactId>slf4j-reload4j</artifactId>
14
            <groupId>org.slf4j</groupId>
15
        </exclusion>
16
    </exclusions>
17
    <version>3.0.9</version>
18
</dependency>

展开收起

使用Nacos作为注册中心：

1
<!-- dubbo -->
2
<dependency>
3
    <groupId>org.apache.dubbo</groupId>
4
    <artifactId>dubbo-spring-boot-starter</artifactId>
5
    <version>3.0.9</version>
6
</dependency>
7
<!-- nacos作为注册中心 -->
8
<dependency>
9
    <groupId>org.apache.dubbo</groupId>
10
    <artifactId>dubbo-registry-nacos</artifactId>
11
    <version>3.0.9</version>
12
</dependency>
13
<dependency>
14
    <groupId>com.alibaba.nacos</groupId>
15
    <artifactId>nacos-client</artifactId>
16
    <version>2.2.3</version>
17
</dependency>

展开收起

2、定义公共接口#

Provider和Consumer之间需要一个公共的接口模块，双方都依赖这个模块。

1
public interface TestDubboService {
2
    String sayHello(String name);
3
    ZhuoYe getZuoYe();
4
}

3、服务提供者（Provider）#

3.1 配置文件#

使用Zookeeper作为注册中心：

1
dubbo:
2
  application:
3
    name: dubbo-springboot-demo-provider
4
  protocol:
5
    name: dubbo
6
    port: -1  # -1表示自动分配端口
7
  registry:
8
    address: zookeeper://192.168.190.129:2181
9
    timeout: 60000

使用Nacos作为注册中心：

1
dubbo:
2
  application:
3
    name: dubbo-springboot-demo-provider
4
  protocol:
5
    name: dubbo
6
    port: -1
7
  registry:
8
    address: nacos://127.0.0.1:8848
9
    timeout: 60000
10
    # 如果nacos配置了命名空间，需要指定namespace
11
    # parameters:
12
    #   namespace: your-namespace-id

区别就只是 registry.address 的协议头不同：Zookeeper是 zookeeper://，Nacos是 nacos://，其他配置完全一样。

3.2 启动类添加注解#

1
@SpringBootApplication
2
@EnableDubbo  // 开启Dubbo
3
public class ProviderApp {
4
    public static void main(String[] args) {
5
        SpringApplication.run(ProviderApp.class, args);
6
    }
7
}

3.3 实现服务接口#

1
@DubboService  // 标记为Dubbo服务，会自动注册到注册中心
2
public class TestDubboServiceImpl implements TestDubboService {
3

4
    @Override
5
    public String sayHello(String name) {
6
        return "hello," + name;
7
    }
8

9
    @Override
10
    public ZhuoYe getZuoYe() {
11
        ZhuoYe zuoYe = new ZhuoYe();
12
        zuoYe.setName("zhuoye-1")
13
                .setDescription("帅呆了！！！");
14
        return zuoYe;
15
    }
16
}

展开收起

4、服务消费者（Consumer）#

4.1 配置文件#

使用Zookeeper作为注册中心：

1
dubbo:
2
  application:
3
    name: dubbo-springboot-demo-consumer
4
  protocol:
5
    name: dubbo
6
    port: -1
7
  registry:
8
    address: zookeeper://192.168.190.129:2181
9
    timeout: 60000

使用Nacos作为注册中心：

1
dubbo:
2
  application:
3
    name: dubbo-springboot-demo-consumer
4
  protocol:
5
    name: dubbo
6
    port: -1
7
  registry:
8
    address: nacos://127.0.0.1:8848
9
    timeout: 60000

4.2 启动类添加注解#

1
@SpringBootApplication
2
@EnableDubbo  // 开启Dubbo
3
public class ConsumerApp {
4
    public static void main(String[] args) {
5
        SpringApplication.run(ConsumerApp.class, args);
6
    }
7
}

4.3 调用远程服务#

1
@RestController
2
@RequestMapping("dubbo")
3
public class TestDubboController {
4

5
    @DubboReference  // 注入远程服务
6
    private TestDubboService testDubboService;
7

8
    @GetMapping("hello")
9
    public String hello(String name) {
10
        return testDubboService.sayHello(name);
11
    }
12

13
    @GetMapping("getZhuoye")
14
    public ZhuoYe getZhuoye() {
15
        return testDubboService.getZuoYe();
16
    }
17
}

展开收起

四、核心注解说明#

注解	用在谁身上	说明
@EnableDubbo	启动类	开启Dubbo自动配置
@DubboService	Provider的服务实现类	标记为Dubbo服务，自动注册到注册中心
@DubboReference	Consumer的属性	注入远程服务的代理对象

版本说明： 在 Dubbo 2.7.x 及更早版本中，使用的是 @Service 和 @Reference 注解（来自 org.apache.dubbo.config.annotation.Service 或 com.alibaba.dubbo.config.annotation.Service）。从 Dubbo 2.7.7 开始，官方推荐使用 @DubboService 和 @DubboReference 替代，目的是避免与 Spring 的 @Service 注解产生冲突和混淆。如果你在公司的老项目中看到 @Service 注解标注的服务类，那就是早期版本的写法，功能上和 @DubboService 是一样的。

五、常用配置说明#

1、超时设置#

1
// 方式一：在注解上设置（推荐，精确控制）
2
@DubboService(timeout = 5000)
3
public class UserServiceImpl implements UserService { ... }
4

5
// 方式二：在消费端设置
6
@DubboReference(timeout = 3000)
7
private UserService userService;

2、重试设置#

1
@DubboReference(retries = 2)  // 重试2次，总共执行3次
2
private UserService userService;

注意： 涉及写操作（新增、修改、删除）的方法不要设置重试，避免重复执行。

3、负载均衡策略#

策略	说明
Random	随机（默认）
RoundRobin	轮询
LeastActive	最少活跃调用数
ConsistentHash	一致性Hash

1
@DubboReference(loadbalance = "roundrobin")
2
private UserService userService;

4、版本控制#

当服务接口有不兼容升级时，可以通过版本来区分：

1
// Provider：提供不同版本的服务
2
@DubboService(version = "1.0")
3
public class UserServiceImplV1 implements UserService { ... }
4

5
@DubboService(version = "2.0")
6
public class UserServiceImplV2 implements UserService { ... }
7

8
// Consumer：指定调用哪个版本
9
@DubboReference(version = "1.0")
10
private UserService userService;

六、项目中如何使用Dubbo#

1、项目中首次使用Dubbo#

按照上面”三、SpringBoot整合Dubbo”的步骤操作即可。

2、项目中非首次使用Dubbo#

直接使用 Ctrl + Shift + R 全局搜索 @DubboService、@DubboReference、@Service、@Reference（后两个是早期版本的注解，老项目中会用到），参考同事的代码，照葫芦画瓢即可。

七、常见使用场景#

1、跨服务调用#

1
用户服务 → 调用订单服务获取用户订单
2
订单服务 → 调用商品服务获取商品信息

2、公共服务抽取#

1
短信服务、邮件服务、文件上传服务 → 独立部署，其他服务通过Dubbo调用

八、常见问题排查#

1、服务调用失败：No provider available#

可能原因：

Provider未启动或未注册到注册中心
网络不通，Provider端口未开放
接口类路径不一致（Provider和Consumer的接口包名必须一致）

排查步骤：

Terminal window

1
# 1. 检查注册中心（Zookeeper）是否启动
2
# 2. 检查Provider日志，确认服务已注册
3
# 3. 检查Consumer和Provider的接口包名是否一致

2、服务调用超时#

可能原因：

Provider处理慢（数据库查询慢、业务逻辑复杂）
网络延迟高
并发量大，Provider处理不过来

解决方案：

1
// 增加超时时间
2
@DubboReference(timeout = 10000)
3
private UserService userService;

3、注册中心连不上#

可能原因：

注册中心未启动（Zookeeper或Nacos）
地址或端口配置错误
防火墙未放行端口

排查命令：

Terminal window

1
# 测试Zookeeper连通性
2
telnet 192.168.190.129 2181
3

4
# 测试Nacos连通性（默认8848端口）
5
curl http://127.0.0.1:8848/nacos/

4、本地改了代码但没有生效（新人高频问题）#

现象： 本地修改了Provider的代码并重启，但调用接口后发现行为没有变化，打的断点也不进。

原因： 注册中心里注册了多个同名的服务实例（线上环境 + 你本地的），Consumer通过负载均衡调用时，实际走的是线上的服务实例，而不是你本地的。

排查步骤：

打开注册中心的管理控制台（Zookeeper用PrettyZoo等客户端，Nacos用Web控制台）
查看该服务名下有几个实例，确认你的本地实例是否在里面
检查Consumer调用的到底是哪个实例

解决方案：

方案	操作	推荐度
直连本地	Consumer配置 @DubboReference(url = “dubbo://127.0.0.1<20880>”) 绕过注册中心直接连本地	推荐，最简单
版本区分	本地Provider注册一个独立的版本号，Consumer指定调用该版本	推荐，不影响其他实例
只启动本地Provider	把线上的Provider停掉，只保留本地的实例	可以但不影响线上
隔离环境	本地连接开发环境的注册中心，不连线上的	推荐，规范做法

关于直连端口： 20880 是Provider的Dubbo协议端口，对应配置文件中的 dubbo.protocol.port。如果配置的是固定端口（如 port: 20880），直接填即可；如果配置的是 -1（自动分配），实际端口会在Provider启动日志中打印出来，需要去日志里查找。

1
// 方式一：注解直连本地（调试时临时使用，用完记得去掉）
2
// 20880是Provider的dubbo协议端口，即配置文件中 dubbo.protocol.port 的值
3
@DubboReference(url = "dubbo://127.0.0.1:20880")
4
private UserService userService;
5

6
// 方式二：配置文件指定直连（不影响代码）
7
// application.yml
8
dubbo:
9
  consumer:
10
    url: dubbo://127.0.0.1:20880
11

12
// 方式三：通过版本区分（推荐）
13
// Provider端：本地启动时指定一个测试版本
14
@DubboService(version = "local-dev")
15
public class UserServiceImpl implements UserService { ... }
16

17
// Consumer端：指定调用本地测试版本
18
@DubboReference(version = "local-dev")
19
private UserService userService;

展开收起

注意： 直连方式会绕过注册中心，仅用于本地调试，上线前必须去掉。版本区分方式的好处是：你本地注册的服务和线上的服务通过版本号隔离开，Consumer明确指定调用 local-dev 版本，不会误打到线上实例。排查问题的思路就是：先确认你的请求到底打到了哪个实例上。确认方式可以在后端对应调用Provider的服务上打个断点，走到断点就说明请求走的是本地，也可以通过这种方式来验证走本地服务的时候，逻辑是否正确的。

九、注意事项#

接口包名必须一致：Provider和Consumer引用的接口类，包路径必须完全一致，否则找不到服务
实体类必须实现Serializable：Dubbo传输的对象必须实现序列化接口
谨慎设置重试：写操作不要设置重试，避免重复执行
合理设置超时：根据业务实际情况设置超时时间，不要太大也不要太小
检查注册中心状态：注册中心挂了，新的服务无法注册和发现

工作中ES的使用

Sat, 01 Aug 2026 00:00:00 GMT

一、ES到底是什么？#

1、什么是ES（Elasticsearch）？#

简单说：ES是一个搜索引擎，擅长在海量数据中快速搜索。

为什么需要ES？

你可能会问：MySQL也能查询啊，为什么还要ES？

对比项	MySQL	ES
模糊查询	LIKE ‘%xxx%‘，很慢	分词搜索，很快
百万级数据	查询变慢	依然很快
复杂搜索	写复杂SQL	简单API调用
全文检索	效率低	专门干这个的

结论：搜索功能、大量数据的查询，用ES。

2、ES和MySQL概念对比#

MySQL	ES	说明
数据库	索引（Index）	数据的集合
表	类型（Type）	7.x后已废弃，一个索引就是一个表
行	文档（Document）	一条数据
列	字段（Field）	一个属性
表结构	映射（Mapping）	字段定义

3、什么时候用ES？#

场景	是否用ES
商品搜索	是
日志分析	是
百万级数据查询	是
简单的增删改查	否，用MySQL
事务操作	否，用MySQL

二、核心概念#

1、索引（Index）#

就是数据库，存放数据的地方。

1
商品索引：product_index
2
用户索引：user_index
3
订单索引：order_index

2、文档（Document）#

就是一条数据，JSON格式。

1
{
2
    "id": 1,
3
    "name": "iPhone 15",
4
    "price": 5999,
5
    "category": "手机"
6
}

3、映射（Mapping）#

就是表结构，定义字段类型。

1
{
2
    "mappings": {
3
        "properties": {
4
            "id": { "type": "long" },
5
            "name": { "type": "text" },
6
            "price": { "type": "integer" },
7
            "category": { "type": "keyword" }
8
        }
9
    }
10
}

常用字段类型：

类型	说明	例子
text	可分词的文本	商品描述
keyword	精确匹配	品牌、状态
integer/long	整数	价格、数量
double	小数	金额
date	日期	创建时间
boolean	布尔	是否上架

4、倒排索引#

原理： 把内容分词，建立词→文档ID 的映射。

1
文档1：苹果手机很好用
2
文档2：华为手机性价比高
3

4
分词后：
5
苹果 → [文档1]
6
手机 → [文档1, 文档2]
7
很好用 → [文档1]
8
华为 → [文档2]
9
性价比高 → [文档2]
10

11
搜索"手机"，直接找到文档1和文档2

三、SpringBoot整合ES#

方案选择#

方案	说明	推荐度
Spring Data Elasticsearch	像用JPA一样用ES	推荐，简单
RestHighLevelClient	官方客户端（7.x）	推荐，灵活
Elasticsearch Java Client	官方新客户端（8.x）	ES 8.x用这个

新人建议：先学Spring Data Elasticsearch，最简单。

四、Spring Data Elasticsearch（推荐）#

第一步：引入依赖#

1
<dependency>
2
    <groupId>org.springframework.boot</groupId>
3
    <artifactId>spring-boot-starter-data-elasticsearch</artifactId>
4
</dependency>

第二步：配置连接#

1
spring:
2
  elasticsearch:
3
    uris: http://127.0.0.1:9200
4
    username: elastic
5
    password: 123456

第三步：定义实体类#

1
@Document(indexName = "product")  // 索引名称
2
@Data
3
public class Product {
4

5
    @Id
6
    private Long id;
7

8
    @Field(type = FieldType.Text, analyzer = "ik_max_word")
9
    private String name;  // 商品名称，支持分词
10

11
    @Field(type = FieldType.Keyword)
12
    private String category;  // 分类，精确匹配
13

14
    @Field(type = FieldType.Double)
15
    private Double price;  // 价格
16

17
    @Field(type = FieldType.Integer)
18
    private Integer stock;  // 库存
19
}

展开收起

第四步：定义Repository#

1
@Repository
2
public interface ProductRepository extends ElasticsearchRepository<Product, Long> {
3

4
    // 按名称模糊查询
5
    List<Product> findByName(String name);
6

7
    // 按分类查询
8
    List<Product> findByCategory(String category);
9

10
    // 价格区间查询
11
    List<Product> findByPriceBetween(Double min, Double max);
12

13
    // 自定义查询：名称包含关键字
14
    @Query("{\"match\": {\"name\": \"?0\"}}")
15
    List<Product> searchByName(String keyword);
16
}

展开收起

第五步：使用#

1
@Service
2
@Slf4j
3
public class ProductService {
4

5
    @Autowired
6
    private ProductRepository productRepository;
7

8
    // 1. 新增/更新文档
9
    public void save(Product product) {
10
        productRepository.save(product);
11
        log.info("保存成功");
12
    }
13

14
    // 2. 批量新增
15
    public void saveAll(List<Product> products) {
16
        productRepository.saveAll(products);
17
    }
18

19
    // 3. 根据ID查询
20
    public Product getById(Long id) {
21
        return productRepository.findById(id).orElse(null);
22
    }
23

24
    // 4. 查询所有
25
    public List<Product> getAll() {
26
        Iterable<Product> all = productRepository.findAll();
27
        List<Product> list = new ArrayList<>();
28
        all.forEach(list::add);
29
        return list;
30
    }
31

32
    // 5. 删除
33
    public void delete(Long id) {
34
        productRepository.deleteById(id);
35
    }
36

37
    // 6. 按名称搜索
38
    public List<Product> searchByName(String name) {
39
        return productRepository.findByName(name);
40
    }
41

42
    // 7. 价格区间查询
43
    public List<Product> searchByPriceRange(Double min, Double max) {
44
        return productRepository.findByPriceBetween(min, max);
45
    }
46
}

展开收起

五、复杂查询#

使用ElasticsearchRestTemplate#

1
@Service
2
@Slf4j
3
public class ProductSearchService {
4

5
    @Autowired
6
    private ElasticsearchRestTemplate esTemplate;
7

8
    /**
9
     * 多条件搜索
10
     * 支持关键字搜索 + 分类筛选 + 价格区间
11
     */
12
    public List<Product> search(String keyword, String category, Double minPrice, Double maxPrice) {
13
        // 1. 构建查询条件
14
        NativeSearchQueryBuilder queryBuilder = new NativeSearchQueryBuilder();
15

16
        // bool查询（组合查询）
17
        BoolQueryBuilder boolQuery = QueryBuilders.boolQuery();
18

19
        // 关键字搜索（must：必须满足）
20
        if (StringUtils.isNotBlank(keyword)) {
21
            boolQuery.must(QueryBuilders.matchQuery("name", keyword));
22
        }
23

24
        // 分类筛选（filter：过滤，不参与评分）
25
        if (StringUtils.isNotBlank(category)) {
26
            boolQuery.filter(QueryBuilders.termQuery("category", category));
27
        }
28

29
        // 价格区间
30
        if (minPrice != null && maxPrice != null) {
31
            boolQuery.filter(QueryBuilders.rangeQuery("price")
32
                    .gte(minPrice)
33
                    .lte(maxPrice));
34
        }
35

36
        queryBuilder.withQuery(boolQuery);
37

38
        // 2. 执行查询
39
        SearchHits<Product> hits = esTemplate.search(queryBuilder.build(), Product.class);
40

41
        // 3. 处理结果
42
        return hits.getSearchHits().stream()
43
                .map(SearchHit::getContent)
44
                .collect(Collectors.toList());
45
    }
46

47
    /**
48
     * 分页查询
49
     */
50
    public Page<Product> searchPage(String keyword, int page, int size) {
51
        NativeSearchQueryBuilder queryBuilder = new NativeSearchQueryBuilder();
52

53
        // 关键字搜索
54
        if (StringUtils.isNotBlank(keyword)) {
55
            queryBuilder.withQuery(QueryBuilders.matchQuery("name", keyword));
56
        }
57

58
        // 分页
59
        queryBuilder.withPageable(PageRequest.of(page, size));
60

61
        // 排序（按价格升序）
62
        queryBuilder.withSort(SortBuilders.fieldSort("price").order(SortOrder.ASC));
63

64
        SearchHits<Product> hits = esTemplate.search(queryBuilder.build(), Product.class);
65

66
        // 转换结果
67
        List<Product> list = hits.getSearchHits().stream()
68
                .map(SearchHit::getContent)
69
                .collect(Collectors.toList());
70

71
        return new PageImpl<>(list, PageRequest.of(page, size), hits.getTotalHits());
72
    }
73
}

展开收起

六、常用查询类型#

查询类型	说明	示例
match	分词匹配	搜索”苹果手机”会分词
term	精确匹配	搜索”iPhone15”必须完全一致
range	范围查询	价格100-500
bool	组合查询	多条件组合
wildcard	通配符	”apple*“

1
// match查询（分词）
2
QueryBuilders.matchQuery("name", "苹果手机");
3

4
// term查询（精确）
5
QueryBuilders.termQuery("category", "手机");
6

7
// range查询（范围）
8
QueryBuilders.rangeQuery("price").gte(100).lte(500);
9

10
// bool查询（组合）
11
BoolQueryBuilder boolQuery = QueryBuilders.boolQuery();
12
boolQuery.must(QueryBuilders.matchQuery("name", "手机"));
13
boolQuery.filter(QueryBuilders.termQuery("category", "手机"));

七、ES和MySQL数据同步#

实际工作中，数据存MySQL，搜索用ES，需要保持同步。

常见方案#

方案	说明	优缺点
同步双写	写MySQL同时写ES	简单，但可能不一致
异步消息	写MySQL发MQ，消费写ES	解耦，推荐
Canal监听	监听MySQL binlog	无侵入，复杂

简单示例：同步双写#

1
@Service
2
@Transactional
3
public class ProductServiceImpl implements ProductService {
4

5
    @Autowired
6
    private ProductMapper productMapper;  // MySQL
7

8
    @Autowired
9
    private ProductRepository productRepository;  // ES
10

11
    /**
12
     * 新增商品
13
     */
14
    public void addProduct(Product product) {
15
        // 1. 存MySQL
16
        productMapper.insert(product);
17

18
        // 2. 存ES
19
        productRepository.save(product);
20
    }
21

22
    /**
23
     * 更新商品
24
     */
25
    public void updateProduct(Product product) {
26
        // 1. 更新MySQL
27
        productMapper.updateById(product);
28

29
        // 2. 更新ES
30
        productRepository.save(product);  // ES的save是新增或更新
31
    }
32

33
    /**
34
     * 删除商品
35
     */
36
    public void deleteProduct(Long id) {
37
        // 1. 删除MySQL
38
        productMapper.deleteById(id);
39

40
        // 2. 删除ES
41
        productRepository.deleteById(id);
42
    }
43
}

展开收起

八、新人避坑指南#

坑	正确做法
连不上ES	检查地址、端口、账号密码
搜索不到数据	检查分词器配置，字段类型
中文搜索不准	安装IK分词器
字段类型错误	text支持分词，keyword精确匹配
数据不同步	写MySQL后记得同步到ES
没建索引就存数据	先创建索引和映射

九、问同事的问题#

刚入职用ES时，可以问同事：

问题	说明
”ES地址是什么？“	配置需要
”索引命名有什么规范吗？“	了解命名规范
”用的哪个客户端？“	确认技术方案
”有IK分词器吗？“	中文搜索需要
”数据怎么同步的？“	了解同步方案

十、注意事项#

ES不是数据库：主要用来搜索，不是用来存数据
分词器很重要：中文要用IK分词器
字段类型要选对：text分词，keyword精确匹配
数据要同步：MySQL和ES数据要一致
不要深度分页：from+size不要超过10000

十一、ES 8.x 新客户端（了解）#

如果项目用的是ES 8.x，要用新的Java Client：

1
<dependency>
2
    <groupId>co.elastic.clients</groupId>
3
    <artifactId>elasticsearch-java</artifactId>
4
    <version>8.11.0</version>
5
</dependency>

用法类似，只是API略有不同。

十二、终极建议#

ES不难，关键是理解它和MySQL的区别，知道什么时候用ES。

使用步骤记住五步：

确认ES地址和版本
引入依赖
定义实体类（加@Document注解）
定义Repository（继承ElasticsearchRepository）
直接调用方法使用

记住：搜索功能、大量数据查询用ES，普通CRUD用MySQL！

工作中git的使用

Sat, 01 Aug 2026 00:00:00 GMT

一、git是什么？为什么需要git？#

1、git是什么#

简单的说，Git就是一个分布式版本控制系统。

分布式：每个人的电脑上都有一个完整的仓库，包含了全部的历史记录。 这样你可以在自己的电脑上独立工作（提交代码、创建分支），不需要随时联网。等完成了一个功能后，再把自己的修改推送到一个大家约定的“中央服务器”上（比如 GitHub, Gitee）进行共享和协作。

版本控制：Git 就是帮你自动化、智能化地管理这个过程的工具。 它就像一个“时光机器”，记录你对项目文件所做的每一次修改（我们称之为“提交”）。你可以随时回溯到任何一个过去的版本，看看某一行代码是谁、在什么时候、为什么而修改的。

Git 的四个工作区域：

workspace：工作区

就是平时存放项目代码的地方。
index：暂存区

在将工作区内容加入到本地仓库，在加入到本地仓库前，是先放置在暂存区的
Repository：本地仓库

位于自己的机器，本地仓库保存了被提交过的各个版本，比起工作区和暂存区的内容，它更旧一些。
Remote：远程仓库

位于托管代码的服务器，就比如gitee、github、gitlab，远程仓库的内容能够被分布在多个地点的处于协作关系的本地仓库修改。比起本地仓库，远程仓库通常旧一些，因此本地仓库修改完之后需要同步到远程仓库.

2、为什么需要git?#

对个人：再也不怕“改错代码”和“误删文件”
对团队：高效协作开发
对项目：清晰的历史记录和权责明晰

二、git的安装#

1
1、安装过程基本直接下一步就可以
2
2、安装完成后，打开cmd，输入如下命令，能够查看到git版本，便是安装成功
3
       git --version
4
3、配置用户名和邮箱
5
1）配置全局
6
     git config --global user.name zy
7
     git config --global user.email 736173273@qq.com
8
2）配置项目级别
9
      切换到项目根目录下执行
10
     git config  user.name   fengqingyang
11
     git config  user.email  fengqingyang@zcloud.com
12
4、查看是否配置成功
13
 1)查看全局配置
14
      git config --global user.name
15
      git config --global user.email
16
 2）查看项目级配置
17
切换到项目根目录下执行
18
      git config  user.name
19
      git config  user.email

展开收起

三、git常用命令#

在你需要操作的目录打开鼠标右击当前目录空白区域，选择git bash命令窗口打开

git-bash打开

1、克隆代码#

克隆远程仓库代码到本地

1
git clone  [远程仓库地址]

克隆远程仓库指定分支代码到本地

1
git clone -b  [分支名]   [远程仓库地址]

指定用户名密码克隆远程仓库代码到本地

指定账户密码只能是http/https地址

1
git clone http://<用户名>:<密码>@<远程仓库地址>

指定用户名密码的时候，是因为本地有缓存其他git的凭据信息，所以，需要指定此次克隆地址的用户名和密码。或者使用下面命令清除本地缓存的git凭据信息

1
git config --global --unset credential.helper

再次克隆若出现如下界面，则填写对应你克隆仓库的账号密码即可。

git-输入账号密码

4）开启2FA双重认证的git仓库代码克隆

对于开启2FA双重认证的git仓库的克隆，此时使用账号密码是克隆不下来代码的，需要在平台获取访问令牌。

gitlab-创建访问令牌

点击创建个人访问令牌之后，出现如下界面：

gitlab-token

拿到token,使用token克隆即可：

1
git clone http://<用户名>:<token>@<远程仓库地址>
2
使用示例：
3
git clone http://zhuoye:glpat-HaQ_A4ejLRP1Jx-12yXz@192.168.3.3:9000/zCloud/study-platform/zy-cloud.git

git带token克隆

注意：克隆代码的远程仓库地址可以使用http/https或者ssh地址，http/https地址直接使用就行，ssh地址需要本地生成密钥，然后远程仓库添加这个密钥。

ssh密钥配置流程：

生成本地密钥

1
  ssh-keygen -t ed25519 -C "736170173@qq.com"

生成ssh密钥

默认生成在C:\Users\Administrator\ .ssh 其中Administrator是登录电脑的用户名，换成对应自己登录电脑的名字即可！

git上添加密钥

在个人资料里面添加上述步骤生成的公钥，以.pub结尾的那个文件就是公钥。

添加密钥

配置完成后，便可以使用git中的ssh地址来进行克隆！

2、将代码从工作区添加到暂存区#

1
#添加单个文件
2
git add  filename.txt
3

4
#添加多个文件
5
git add file1.txt file2.js file3.css
6

7
#添加当前目录所有更改（最常用）
8
git add .
9

10
#添加特定类型的文件
11
git add *.js      # 添加所有js文件
12
git add src/*.ts  # 添加src目录下所有ts文件

3、提交代码到本地仓库#

1
#提交暂存区里面的代码到本地仓库
2
git commit -m "提交说明"
3

4
#提交并添加所有更改（跳过 git add 步骤）
5
git commit -am "提交说明"

4、更新远程仓库代码到本地#

1
#拉取当前分支对应的远程分支代码并自动合并
2
git pull
3

4
#拉取远程特定分支并合并到当前分支
5
git pull origin 分支名

5、推送代码到远程仓库#

1
#推送当前分支到与之关联的远程分支
2
git push
3

4
#首次推送时需要设置上游分支
5
git push -u origin 分支名
6

7
# 推送当前分支到远程的指定分支
8
git push origin 本地分支名:远程分支名
9

10
# 强制推送，覆盖远程历史
11
git push --force

6、其它命令#

1
#新建分支
2
git branch  分支名
3

4
#切换分支
5
git checkout  分支名
6

7
#合并指定分支到当前分支
8
git merge 分支名

三、git集成idea的使用#

1、使用git开发前的注意事项#

git操作需谨慎！！！在进行不熟悉的git的操作或者复杂的git操作前，可以把代码做一个整体备份，一是防止误操作导致代码丢失，二是，这样的话你就放心的可以基于现在这份代码来试错了。备份的方式就是ctrl c ctrl v 粘贴复制保存一份未操作之前的代码，或者打个压缩包来保存也行。
开发前，确定是在哪个分支开发，还是基于新的分支开发，如果基于新的分支开发，要确认清楚，基于哪个分支新建。
推送代码之前，先把本地代码commit，然后再pull代码更新远程仓库代码，最后push
切换分支之前，记得把当前分支没有commit的代码commit后再切换分支。
合并分支代码之前，要问清楚你们是直接自己手动合并，还是要在git仓库管理平台发起合并请求。

2、idea集成git#

idea的settings里面找到Version Control里面的Git下配置本地安装的git

idea集成git

3、克隆代码#

idea也可以克隆代码，克隆之后，就可以直接打开克隆的代码，这种方式还是很方便的。

image-20250908184030482

URL就是代码仓库地址，Directory就是代码要克隆的目录。填写完成后，点击Clone按钮即可！

idea克隆代码

有时候，idea可能会出现如下无法克隆的问题。确保idea已经集成git的情况下，还是有如下问题的话，便可以使用git bash命令窗口通过git clone命令来把代码克隆下来，然后再用idea打开克隆下来的代码。

idea克隆代码报错

3、常见操作#

idea中git常见操作

图 3-1

3.3.1 提交代码#

点击图 3-1 的提交代码按钮，便会出现如下界面，按照图中描述的进行操作即可！注意，我们在工作中的时候，同事之间经常说的你有没有提交代码，其实是口语化的表达，并不是说你有没有commit，而是问你有没有push到远程仓库！commit只是把代码commit到你的本地仓库，只有把代码push到远程仓库，他那边才能从远程仓库更新代码到他的本地仓库！

idea-提交代码

3.3.2 更新代码#

点击图 3-1 中的 Update Project,即可将远程分支代码更新到当前分支(建议更新代码先把代码commit一下，避免出现代码冲突误操作导致代码丢失的话，也可以进行回滚)

3.3.3 推送代码#

点击图 3-1 中的 Push就会出现如下界面，点击下图对应按钮进行推送。一般情况点击Push正常推送即可！除非你本地代码和远程代码不一致，你又想要远程仓库代码和你本地代码保持一致，才使用Force Push进行强制推送！强制推送要谨慎！

推送代码

3.3.4 分支相关操作#

如下图，当我们点击分支后右尖括号的时候便可以针对当前分支进行对应操作。

新建分支

图 3-3-4-1

3.3.4.1 新建分支#

新建分支，如图3-3-4-1，点击 new branch from main ,从而基于当前分支进行新建。

idea-新建分支

3.3.4.2 切换分支#

点击图3-3-4-1 的CheckOut将代码切换到当前选中分支，切换代码前，如果当前分支有未commit的代码，可能会出现如下提示：

idea-切换分支提示

此时应点击 Don’t Checkout 暂不切换！可经过以下两种处理方式之后，再进行切换！需要注意的是，即使没有弹出该界面，最好也要手动commit或者暂存未commit的代码再切换分支！

把当前未commit的代码进行commit

把未提交的代码进行commit，然后再切换分支。再次切换回来之后，如果不想保留这个commit记录。可以使用undo commit来撤销commit！

idea-撤销提交

暂存当前未commit的代码

如下图，鼠标右击任一空白区域，然后点击 Stash Changes 暂存当前分支修改的文件！

idea-暂存代码

点击 Stash Changes 后出现如下界面，按下图指引进行操作即可！

idea-输入暂存消息

再次切换回来之后，把暂存的代码恢复，如下点击 Unstash Changes

idea-恢复暂存

3.3.4.3 合并代码#

分支代码合并，有本地合并和平台合并两种方式。具体哪种合并方式，要确认清楚。一般往重要分支合并都是需要平台发起合并请求，让有权限的人来审核你的代码，看是否合并。正常情况下，我们在源分支往子分支合并代码的话本地合并就行，而子分支代码往源分支合并的时候，则需要平台发起合并请求来进行合并。源分支一般都是受保护的，是不允许直接推送代码的！

需要注意的是，在平台发起合并请求的时候，也就是将子分支合并到源分支之前，最好按照下面本地合并的步骤，把源分支的更新合并到你的子分支。这样做的目的，就是把可能出现的冲突提前在本地解决掉。否则，如果有冲突的话，平台上是无法合并的！

1、本地合并

本地合并代码，如图 3-3-4-1点击你要合并的分支后的左尖括号后，点击 Merge ‘main’ into ‘dev’ 。这个意思就是将main分支代码合并到当前dev分支。dev分支就是你当前的分支，mian分支就是你要合并代码过来的分支。

1）源分支合并到子分支

注意的是，如果你点击的是合并本地main分支的话，一定要先切换到main分支更新一下你本地main分支的代码，保证本地main分支代码是最新的。然后，再切换回你的dev分支，按上述说的，来将main分支代码合并到你当前dev分支。如果，你是点击的远程分支，则直接合并即可！当然，如果dev分支，并不是你一个人的分支，合并之前，也要更新一下dev分支代码，保证dev分支代码也是最新的！

idea-合并代码-1

2）子分支合并到源分支

子分支合并到源分支，最好先按照源分支合并到子分支的步骤合并完，再切换到源分支后，将子分支合并到源分支。合并完成之后，将代码推送到远程仓库即可！

2、平台合并

平台合并就是在git管理平台发起合并请求，待对应审核人员来进行审核，审核通过，同意合并，则合并成功。这里以gitlab为例，流程如下：

首先进入需要发起合并请求的代码仓库里，点击左侧合并请求选项（注意需要合并的代码未push的要push上去）

gitlab-合并请求-1

然后会出现如下界面，点击新建合并请求

gitlab-新建合并请求

然后出现如下界面，选择对应需要合并的分支，点击 比较分支并继续

gitlab-合并分支-选择分支

然后出现如下界面，按照下图注释填写对应内容即可！

gitlab-合并请求

3.3.5 回退代码#

3.3.5.1 本地仓库代码回退#

本地仓库代码回退指的是你还没有将提交推送到远程仓库，或者你只想在本地回退代码。如下选择你要回退的版本进行回退。

回退代码

会有如下四个选项:

git-回退选项

Soft

暂存区和工作区的内容保持不变。提交历史回退到了 提交一，但 提交二 中所做的所有更改，会放在暂存区里等待你再次提交。之前工作区的内容还在工作区，保持不变，不会丢失文件或者代码！
Mixed

提交历史回退到了 提交一，但 提交二 中所做的所有更改，会回退到工作区里，之前暂存区的内容也会回退到工作区，工作区的内容保持不变。使用该模式，也不会出现丢失文件或者代码！
Hard

提交历史回退到了 提交一 的样子。从 提交一 之后提交的所有修改都将被永久丢弃，包括暂存区的内容。工作区内容不受影响！
Keep

提交历史回退到了 提交一，但之前提交 提交二 中所做的所有更改会丢失。之前暂存区的内容也会回退到工作区，工作区的内容保持不变。

总结表格如下：

模式	工作区	暂存区	回退版本后提交记录的代码	应用场景
—soft	不变	不变	回退到暂存区	“刚刚提交错代码了，想重新提交一次”
—mixed（默认）	不变	回退到工作区	回退到工作区	“提交太草率，想重新挑选文件再提交”
—hard	不会	丢弃	丢弃	“代码彻底不要了，回到干净的历史点”
—keep	不会	回退到工作区	丢弃	“想回退，但本地没提交的好改动想保留”

3.3.5.2 远程仓库代码回退#

远程仓库代码回退指的是你已经将提交推送到了远程仓库，现在需要将远程仓库的代码也回退到之前的某个版本。此时回退的方法有如下两个方式：

1）不需要强制推送（推荐）

此方式不需要强制推送，会保留原有提交记录，并生成一条新的撤销记录，用于对应需要回退的那条记录。主要方式如下:

非强制推送-1

点击后会生成一条新的提交记录，该记录仅回滚你选中的那次提交所引入的代码修改。因此，它不会影响中间其他提交记录的代码。但是，如果中间的某次提交与你回滚的提交修改了同一个文件，则可能会产生冲突，需要手动解决。

非强制推送-3

需要注意的是，点击Revert Commit 回退之前需要将未提交的代码提交或者暂存，如果没有提交或者暂存Idea右下角会有如下提示

非强制推送-2

2）需要强制推送 (谨慎)

步骤就是，先按照本地仓库的回退步骤进行本地回退，然后再推送代码的时候选择强制推送即可。此时，如果强制推送即 Force Push 置灰不可点击，则说明该分支是受保护，不允许强制推送的！那么远程仓库代码该分支就是不允许做回滚的！那么就只能使用方式一。请注意，强制推送仅建议用于个人分支。如果该分支是公共的，那么强制回退该分支远程仓库代码可能会给其他人带来麻烦。因此，如果你要回退远程仓库公共分支代码之前，最好通知团队中的其他成员。

git-强制推送

3.3.6 其他常见操作#

3.3.6.1 查看代码行提交人#

鼠标右击代码的左侧栏（也是打断点的地方），然后选择 Annotate with Git Blame ，便可查看每行代码是谁写的！

idea-查看每行代码谁写的

3.3.6.2 git日志窗口#

使用快捷键 Alt + 9 可以唤出git的日志窗口，在这里我们除了可以查看git提交的提交人、提交信息、提交时间等提交相关信息之外。还可以针对提交记录，做很多操作，比如上面说的回退代码，还有下面会说的合并指定提交记录代码、合并提交记录、修改提交信息等操作！

idea-git日志窗口

3.3.6.3 合并指定提交记录代码#

当你只需要合并某个分支的某个提交记录的时候，则在git日志窗口，选择对应分支之后，鼠标右击你需要合并的提交记录之后，点击 Cherry-Pick 把该记录合并过来。

idea-cherry-pick

3.3.6.4 更改远程仓库地址#

当我们公司的远程仓库地址变更后，我们本地的项目中的远程地址也需要同步更改！

更改远程仓库地址

出现如下界面修改远程仓库地址后，点击 OK 即可！

更改远程仓库地址-2

3.3.6.5 新增变更列表#

在我们打开commit窗口的时候，默认是，有一个名为Changes的默认更改列表。所有新更改都会自动放入这个更改列表中。还有一个未版本控制的文件更改列表，用于对尚未添加到暂存区中的新创建的文件进行分组。你可以根据需要创建任意数量的更改列表。比如，当我们需要根据本地环境更改一些配置文件的时候，而这些配置文件是不需要提交的，那么我们就可以新建一个更改列表，然后，把这些不需要提交的配置文件放到这个更改列表里面，这样后续，提交代码的时候，这些更改的配置文件就不会出现在默认的更改列表Changes中了。

idea-新增变更列表-1

出现如下界面填写变更列表名称，点击 OK ，便新建一个变更列表！

idea-新增变更列表-1

把不需要提交的文件，使用鼠标拖到该变更列表即可！

idea-新增变更列表-3

3.3.6.6 合并提交记录#

在开发过程中，我们常常会遇到需要将多个提交记录整合为单一提交的情况。比如，在我们平时开发的时候，怕代码丢失，可能会频繁的多次提交。但是，正常情况下，我们应该完成某个功能之后，才应该算一个提交。所以，在完成该功能的开发时，我们可以采用合并提交记录的方式，把分散的多次提交整合成一个统一的提交，这样不仅有助于保持提交历史的清晰和简洁，也便于后续的代码审查与维护。需要注意的是，这些提交必须是尚未推送到远程仓库的本地提交。如果已经推送，再尝试压缩并重新推送的话，可能需要使用强制推送（force push），而强制推送通常是不推荐的，因为它可能会覆盖其他人的代码或导致不必要的冲突！

idea-合并提交记录

出现如下界面，进行提交记录合并

idea-合并提交记录-1

除此之外也可以按住Ctrl键鼠标右击你选中的提交记录，点击 Squash Commits 来快速合并多条提交记录为一条

合并提交记录-2

3.3.6.7 修改提交信息#

对于已经提交到本地仓库但没有push到远程仓库的提交记录，我们可以通过如下操作来修改提交信息。

idea-修改提交信息

出现如下界面，填写修改后的提交信息，点击 OK 即可！

idea-修改提交信息-2

4、常见问题#

3.4.1 git代码冲突#

当你在合并代码或者更新代码的时候，就有可能会出现冲突，发生文件冲突的时候，idea会出现如下界面：

idea-git冲突

有时候，出现冲突的时候是先出现如下界面，当你点击 Merge之后进入上图界面

idea-git-合并冲突

注意，出现该问题一定不要直接叉掉不处理，这样会出现后面3.4.5的问题，并且可能会导致你没有提交的代码丢失！

3.4.2 代码无法克隆#

当出现代码无法克隆的时候，可以按照如下步骤进行排查，若以下步骤排查之后，还是不行，则直接可问同事！

代码无法克隆

3.4.3 代码无法推送#

当出现代码无法推送的时候，可以按照如下步骤进行排查，若以下步骤排查之后，还是不行，则直接可问同事！

代码无法推送

3.4.4 idea使用git的过程，弹出填写token界面#

出现如下界面，随便填写一个token，然后点击 Log In 登录

idea-token登录-1

出现如下界面点击，Log in via Git

idea-token登录-2

出现如下界面，输入你git的账号密码登录即可！

idea-token登录-3

还有一种方式就是把idea默认安装的gitlab插件给禁用，这样后续需要登录的时候就会直接弹出账号密码的登录，而不会是用Token登录！

3.4.5 当前分支名前出现Rebasing或者Merging#

如下图，有时候我们会发现自己当前的分支名前，会出现 Rebasing 或者 Merging，出现这个的原因，往往是你因为你进行了合并或者更新等可能引起冲突的操作，但是却没有对冲突文件进行处理，导致对应操作未实际完成的原因！

idea-分支名前出现Rebasing

或者

idea-分支前出现Merging

点击 Resolve Conflicts 处理冲突！

idea-分支名前出现Rebasing-2

工作中Mybatis动态SQL的使用

Sat, 01 Aug 2026 00:00:00 GMT

一、基础概述#

1、什么是动态SQL？#

简单说：动态SQL就是根据条件自动拼接SQL语句。

为什么要用动态SQL？

举个例子：查询用户列表时，用户可能只输入用户名，也可能同时输入用户名和手机号，还可能什么都不输入。如果不用动态SQL，你就得写多个方法：

1
// 不用动态SQL，要写多个方法
2
List<User> listAll();                           // 查全部
3
List<User> listByName(String userName);         // 按用户名查
4
List<User> listByPhone(String phone);           // 按手机号查
5
List<User> listByNameAndPhone(String userName, String phone); // 按用户名和手机号查

用动态SQL，只需要一个方法：

1
// 用动态SQL，一个方法搞定
2
List<User> list(UserQueryDto query);

2、动态SQL能解决什么问题？#

问题	动态SQL解决方案
条件不确定	根据参数有无动态拼接条件
SQL拼接繁琐	自动处理AND、OR、逗号等
代码冗余	一个SQL搞定多种情况

二、常用动态SQL标签#

1、if标签 - 条件判断#

最常用的标签！ 用于判断参数是否满足条件。

基本语法#

1
<if test="判断条件">
2
    SQL语句
3
</if>

使用示例#

1
<select id="list" resultType="User">
2
    SELECT * FROM t_user
3
    <where>
4
        <!-- 如果userName不为空，就拼接这个条件 -->
5
        <if test="userName != null and userName != ''">
6
            AND user_name = #{userName}
7
        </if>
8
        <!-- 如果phone不为空，就拼接这个条件 -->
9
        <if test="phone != null and phone != ''">
10
            AND phone = #{phone}
11
        </if>
12
        <!-- 如果status不为空，就拼接这个条件 -->
13
        <if test="status != null">
14
            AND status = #{status}
15
        </if>
16
    </where>
17
</select>

展开收起

不同类型的判断方式#

类型	判断方式	示例
Integer类型	只判断null
String类型	判断null和空串
List类型	判断null和size
Boolean类型	直接判断

新人注意：Integer类型判断时不要加空字符串判断！值为0时会被误判为空。

1
<!-- 错误：Integer类型加了空字符串判断 -->
2
<if test="status != null and status != ''">
3
    AND status = #{status}
4
</if>
5
<!-- 当status=0时，这个条件不会生效！ -->
6

7
<!-- 正确：Integer类型只判断null -->
8
<if test="status != null">
9
    AND status = #{status}
10
</if>

2、where标签 - 智能处理WHERE#

where标签的作用：

自动添加WHERE关键字
自动去除多余的AND或OR

使用示例#

1
<select id="list" resultType="User">
2
    SELECT * FROM t_user
3
    <where>
4
        <if test="userName != null and userName != ''">
5
            AND user_name = #{userName}
6
        </if>
7
        <if test="phone != null and phone != ''">
8
            AND phone = #{phone}
9
        </if>
10
    </where>
11
</select>

效果说明：

情况	生成的SQL
两个条件都有	SELECT * FROM t_user WHERE user_name = ? AND phone = ?
只有userName	SELECT * FROM t_user WHERE user_name = ?
条件都为空	SELECT * FROM t_user

注意： where标签会自动去掉第一个AND，所以if里面的AND写在前面没问题。

3、set标签 - 智能处理UPDATE#

set标签的作用：

自动添加SET关键字
自动去除多余的逗号

使用示例#

1
<update id="update">
2
    UPDATE t_user
3
    <set>
4
        <if test="userName != null and userName != ''">
5
            user_name = #{userName},
6
        </if>
7
        <if test="phone != null and phone != ''">
8
            phone = #{phone},
9
        </if>
10
        <if test="email != null and email != ''">
11
            email = #{email},
12
        </if>
13
    </set>
14
    WHERE id = #{id}
15
</update>

展开收起

效果： 只更新传入的字段，没传的不更新。

4、choose/when/otherwise - 多选一#

类似Java的switch-case，只执行第一个满足条件的分支。

使用示例#

1
<select id="query" resultType="User">
2
    SELECT * FROM t_user WHERE 1=1
3
    <choose>
4
        <when test="userName != null and userName != ''">
5
            AND user_name = #{userName}
6
        </when>
7
        <when test="phone != null and phone != ''">
8
            AND phone = #{phone}
9
        </when>
10
        <otherwise>
11
            AND status = 1
12
        </otherwise>
13
    </choose>
14
</select>

效果说明：

如果userName有值，只按userName查
如果userName没值但phone有值，只按phone查
如果都没有，就查status=1的数据

5、foreach标签 - 遍历集合#

用于批量操作：批量插入、批量更新、IN查询等。

基本语法#

1
<foreach collection="集合名" item="元素名" separator="分隔符" open="开始符号" close="结束符号">
2
    #{元素名}
3
</foreach>

属性	说明
collection	集合参数名
item	遍历时每个元素的变量名
separator	元素之间的分隔符
open	以什么开始
close	以什么结束

使用场景#

（1）IN查询

1
<select id="listByIds" resultType="User">
2
    SELECT * FROM t_user WHERE id IN
3
    <foreach collection="ids" item="id" separator="," open="(" close=")">
4
        #{id}
5
    </foreach>
6
</select>

生成的SQL：SELECT * FROM t_user WHERE id IN (1, 2, 3)

（2）批量插入

1
<insert id="insertBatch">
2
    INSERT INTO t_user (user_name, phone, status)
3
    VALUES
4
    <foreach collection="list" item="user" separator=",">
5
        (#{user.userName}, #{user.phone}, #{user.status})
6
    </foreach>
7
</insert>

（3）批量更新

1
<update id="updateBatch">
2
    <foreach collection="list" item="user" separator=";">
3
        UPDATE t_user
4
        <set>
5
            <if test="user.userName != null">
6
                user_name = #{user.userName},
7
            </if>
8
            <if test="user.phone != null">
9
                phone = #{user.phone},
10
            </if>
11
        </set>
12
        WHERE id = #{user.id}
13
    </foreach>
14
</update>

6、trim标签 - 自定义处理#

更灵活地处理前缀后缀。

使用示例#

1
<!-- 等价于where标签 -->
2
<trim prefix="WHERE" prefixOverrides="AND">
3
    <if test="userName != null and userName != ''">
4
        AND user_name = #{userName}
5
    </if>
6
    <if test="phone != null and phone != ''">
7
        AND phone = #{phone}
8
    </if>
9
</trim>
10

11
<!-- 等价于set标签 -->
12
<trim prefix="SET" suffixOverrides=",">
13
    <if test="userName != null and userName != ''">
14
        user_name = #{userName},
15
    </if>
16
    <if test="phone != null and phone != ''">
17
        phone = #{phone},
18
    </if>
19
</trim>

展开收起

三、实际工作中的使用场景#

1、查询列表（最常用）#

1
<select id="list" resultType="UserVo">
2
    SELECT * FROM t_user
3
    <where>
4
        <if test="userName != null and userName != ''">
5
            AND user_name LIKE CONCAT('%', #{userName}, '%')
6
        </if>
7
        <if test="phone != null and phone != ''">
8
            AND phone = #{phone}
9
        </if>
10
        <if test="status != null">
11
            AND status = #{status}
12
        </if>
13
        <if test="startTime != null">
14
            AND cr_time >= #{startTime}
15
        </if>
16
        <if test="endTime != null">
17
            AND cr_time <= #{endTime}
18
        </if>
19
    </where>
20
    ORDER BY cr_time DESC
21
</select>

展开收起

2、动态更新#

1
<update id="updateSelective">
2
    UPDATE t_user
3
    <set>
4
        <if test="userName != null and userName != ''">
5
            user_name = #{userName},
6
        </if>
7
        <if test="phone != null">
8
            phone = #{phone},
9
        </if>
10
        <if test="email != null">
11
            email = #{email},
12
        </if>
13
        up_time = NOW(),
14
    </set>
15
    WHERE id = #{id}
16
</update>

展开收起

3、动态插入#

1
<insert id="insertSelective">
2
    INSERT INTO t_user
3
    <trim prefix="(" suffix=")" suffixOverrides=",">
4
        <if test="userName != null">
5
            user_name,
6
        </if>
7
        <if test="phone != null">
8
            phone,
9
        </if>
10
        <if test="email != null">
11
            email,
12
        </if>
13
        cr_time,
14
    </trim>
15
    <trim prefix="VALUES (" suffix=")" suffixOverrides=",">
16
        <if test="userName != null">
17
            #{userName},
18
        </if>
19
        <if test="phone != null">
20
            #{phone},
21
        </if>
22
        <if test="email != null">
23
            #{email},
24
        </if>
25
        NOW(),
26
    </trim>
27
</insert>

展开收起

四、新人常见错误#

1、Integer类型判断错误#

1
<!-- 错误：Integer类型加了空字符串判断 -->
2
<if test="status != null and status != ''">
3
    AND status = #{status}
4
</if>
5

6
<!-- 正确 -->
7
<if test="status != null">
8
    AND status = #{status}
9
</if>

2、忘记加AND或逗号#

1
<!-- 错误：忘记加AND -->
2
<where>
3
    <if test="userName != null">
4
        user_name = #{userName}  <!-- 少了AND -->
5
    </if>
6
    <if test="phone != null">
7
        AND phone = #{phone}
8
    </if>
9
</where>
10

11
<!-- 正确：第一个条件也要加AND，where标签会自动去掉 -->
12
<where>
13
    <if test="userName != null">
14
        AND user_name = #{userName}
15
    </if>
16
    <if test="phone != null">
17
        AND phone = #{phone}
18
    </if>
19
</where>

展开收起

3、批量操作没处理好#

1
<!-- 错误：批量插入格式不对 -->
2
<insert id="insertBatch">
3
    INSERT INTO t_user (user_name, phone) VALUES
4
    <foreach collection="list" item="user">
5
        (#{user.userName}, #{user.phone})  <!-- 没有分隔符 -->
6
    </foreach>
7
</insert>
8

9
<!-- 正确：加上separator -->
10
<insert id="insertBatch">
11
    INSERT INTO t_user (user_name, phone) VALUES
12
    <foreach collection="list" item="user" separator=",">
13
        (#{user.userName}, #{user.phone})
14
    </foreach>
15
</insert>

展开收起

4、foreach没有判空#

新人常见错误！如果list为空，<foreach> 不会生成任何内容，SQL就会变成不合法的语法，直接报错。

1
<!-- 错误：没有判空，list为空时SQL变成 INSERT INTO t_user (user_name, phone) VALUES  ← 后面啥都没有，语法错误！ -->
2
<insert id="insertBatch">
3
    INSERT INTO t_user (user_name, phone) VALUES
4
    <foreach collection="list" item="user" separator=",">
5
        (#{user.userName}, #{user.phone})
6
    </foreach>
7
</insert>
8

9
<!-- 错误：同样的问题，list为空时SQL变成 WHERE id IN  ← 后面没有值，语法错误！ -->
10
<select id="listByIds" resultType="User">
11
    SELECT * FROM t_user WHERE id IN
12
    <foreach collection="ids" item="id" separator="," open="(" close=")">
13
        #{id}
14
    </foreach>
15
</select>

展开收起

正确做法：在Service层判空，list为空时不调用Mapper方法：

1
@Override
2
public void insertBatch(List<UserDto> userList) {
3
    // 在Service层判空，避免传空集合到Mapper
4
    if (CollectionUtils.isEmpty(userList)) {
5
        return;
6
    }
7
    // 分批处理，每批不超过1000条
8
    int batchSize = 1000;
9
    for (int i = 0; i < userList.size(); i += batchSize) {
10
        int end = Math.min(i + batchSize, userList.size());
11
        userMapper.insertBatch(userList.subList(i, end));
12
    }
13
}

总结：<foreach> 一定要配合判空使用。建议在Service层判断，集合为空直接return或抛异常，不要让空集合传到Mapper里。

五、新人避坑指南#

坑	正确做法
Integer判断加空字符串	Integer只判断null
String判断只判断null	还要判断空字符串
第一个if条件不加AND	要加AND，where标签会自动去掉
set里最后没逗号	要加逗号，set标签会自动去掉
foreach没写separator	批量操作要加分隔符
foreach没有判空	在Service层判空，集合为空时不调用Mapper，避免SQL语法错误
复制粘贴不改参数名	仔细检查参数名是否正确

六、调试技巧#

1、开启SQL日志#

MyBatis项目：

application.yml

1
mybatis:
2
  configuration:
3
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

MyBatis-Plus项目：

application.yml

1
mybatis-plus:
2
  configuration:
3
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

注意区分： MyBatis和MyBatis-Plus只是配置前缀不同，一个是mybatis:，一个是mybatis-plus:。看看项目用的是哪个就配哪个。

开启日志后，控制台会打印实际执行的SQL，检查是否符合预期。

2、使用MyBatis Log Free插件（推荐）#

在IDEA中安装 MyBatis Log Free 插件，可以把MyBatis日志中带?占位符的SQL直接还原成完整的、可执行的SQL，复制到Navicat里直接运行排查问题。

安装方式： IDEA → Settings → Plugins → 搜索 MyBatis Log Free → Install

mybatislogfree-1

如果安装失败：

mybatislogfree-2

在 Appearance & Behavior->System Settings->HTTP Proxy 路径中勾选 Auto-detect proxy settings 后再重新 install 插件 MyBatis Log Free

mybatislogfree-3

使用步骤：

开启SQL日志（上面的第1步）

调用接口后，控制台会打印类似这样的日志：

1
==> Preparing: SELECT * FROM t_user WHERE user_name = ? AND status = ?
2
==> Parameters: 张三(String), 1(Integer)

打开IDEA底部的 MyBatis Log Free 面板（Tools → MyBatis Log Free）

插件会自动还原成完整SQL：

1
SELECT * FROM t_user WHERE user_name = '张三' AND status = 1

mybatislogfree-4

复制这条SQL，直接粘贴到Navicat执行，排查数据和条件是否正确

新人必装！ 不装这个插件的话，你需要手动把?和参数一一对应替换，参数多了很容易搞错。有了这个插件一键还原，效率提升很多。

七、终极建议#

工作中90%的动态SQL就是if + where的组合，把这个练熟就够了。

遇到不确定的情况，开启SQL日志，看实际生成的SQL是什么样的，然后调整。

工作中Redis的使用

Sat, 01 Aug 2026 00:00:00 GMT

一、什么是Redis？#

Redis是一个开源的内存数据结构存储系统，可以用作数据库、缓存和消息中间件。它支持多种类型的数据结构，如字符串、哈希、列表、集合、有序集合等。

1、Redis的特点#

特点	说明
高性能	数据存储在内存中，读写速度极快，QPS可达10万+
丰富的数据类型	支持String、Hash、List、Set、ZSet等多种数据结构
持久化	支持RDB和AOF两种持久化方式，防止数据丢失
支持集群	支持主从复制和集群模式，实现高可用
原子性	所有操作都是原子性的，支持事务

2、Redis的五种基本数据类型#

数据类型	说明	适用场景
String	最基本的类型，可以存储字符串、整数、浮点数	缓存、计数器、分布式锁
Hash	键值对集合，适合存储对象	用户信息、商品信息
List	有序列表，支持从两端插入和弹出	消息队列、最新列表
Set	无序集合，元素唯一	标签、共同关注
ZSet	有序集合，每个元素关联一个分数	排行榜、延时队列

二、项目中如何使用Redis#

1、项目中首次使用Redis#

1.1 引入依赖#

1
<dependency>
2
    <groupId>org.springframework.boot</groupId>
3
    <artifactId>spring-boot-starter-data-redis</artifactId>
4
</dependency>

1.2 配置Redis信息#

基础配置：

1
spring:
2
  redis:
3
    host: 127.0.0.1
4
    port: 6379
5
    password: 123456
6
    database: 0

完整配置（推荐）：

1
spring:
2
  redis:
3
    host: 127.0.0.1
4
    port: 6379
5
    password: 123456
6
    database: 0
7
    timeout: 10000ms
8
    lettuce:
9
      pool:
10
        max-active: 8        # 连接池最大连接数
11
        max-wait: -1ms       # 连接池最大阻塞等待时间（负值表示无限制）
12
        max-idle: 8          # 连接池最大空闲连接
13
        min-idle: 0          # 连接池最小空闲连接

1.3 配置RedisTemplate#

1
@Configuration
2
public class RedisConfig {
3

4
    @Bean
5
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
6
        RedisTemplate<String, Object> template = new RedisTemplate<>();
7
        template.setConnectionFactory(factory);
8

9
        // 使用Jackson2JsonRedisSerializer来序列化和反序列化redis的value值
10
        Jackson2JsonRedisSerializer<Object> jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer<>(Object.class);
11
        ObjectMapper mapper = new ObjectMapper();
12
        mapper.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
13
        mapper.activateDefaultTyping(LaissezFaireSubTypeValidator.instance, ObjectMapper.DefaultTyping.NON_FINAL);
14
        jackson2JsonRedisSerializer.setObjectMapper(mapper);
15

16
        // 使用StringRedisSerializer来序列化和反序列化redis的key值
17
        StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();
18

19
        // key采用String的序列化方式
20
        template.setKeySerializer(stringRedisSerializer);
21
        // hash的key也采用String的序列化方式
22
        template.setHashKeySerializer(stringRedisSerializer);
23
        // value序列化方式采用jackson
24
        template.setValueSerializer(jackson2JsonRedisSerializer);
25
        // hash的value序列化方式采用jackson
26
        template.setHashValueSerializer(jackson2JsonRedisSerializer);
27

28
        template.afterPropertiesSet();
29
        return template;
30
    }
31
}

展开收起

1.4 写Redis工具类#

1
@Component
2
public class RedisUtils {
3

4
    @Autowired
5
    private RedisTemplate<String, Object> redisTemplate;
6

7
    // =============================String类型操作=============================
8

9
    /**
10
     * 设置缓存
11
     */
12
    public void set(String key, Object value, long time) {
13
        redisTemplate.opsForValue().set(key, value, time, TimeUnit.SECONDS);
14
    }
15

16
    /**
17
     * 获取缓存
18
     */
19
    public Object get(String key) {
20
        return key == null ? null : redisTemplate.opsForValue().get(key);
21
    }
22

23
    /**
24
     * 判断key是否存在
25
     */
26
    public Boolean hasKey(String key) {
27
        return redisTemplate.hasKey(key);
28
    }
29

30
    /**
31
     * 删除缓存
32
     */
33
    public Boolean delete(String key) {
34
        return redisTemplate.delete(key);
35
    }
36

37
    /**
38
     * 批量删除
39
     */
40
    public Long delete(Collection<String> keys) {
41
        return redisTemplate.delete(keys);
42
    }
43

44
    /**
45
     * 设置过期时间
46
     */
47
    public Boolean expire(String key, long time) {
48
        return redisTemplate.expire(key, time, TimeUnit.SECONDS);
49
    }
50

51
    /**
52
     * 获取过期时间
53
     */
54
    public Long getExpire(String key) {
55
        return redisTemplate.getExpire(key, TimeUnit.SECONDS);
56
    }
57

58
    /**
59
     * 自增
60
     */
61
    public Long increment(String key) {
62
        return redisTemplate.opsForValue().increment(key);
63
    }
64

65
    /**
66
     * 自增指定值
67
     */
68
    public Long increment(String key, long delta) {
69
        return redisTemplate.opsForValue().increment(key, delta);
70
    }
71

72
    /**
73
     * 自减
74
     */
75
    public Long decrement(String key) {
76
        return redisTemplate.opsForValue().decrement(key);
77
    }
78

79
    // =============================Hash类型操作=============================
80

81
    /**
82
     * 获取Hash中的值
83
     */
84
    public Object hGet(String key, String field) {
85
        return redisTemplate.opsForHash().get(key, field);
86
    }
87

88
    /**
89
     * 设置Hash中的值
90
     */
91
    public void hSet(String key, String field, Object value) {
92
        redisTemplate.opsForHash().put(key, field, value);
93
    }
94

95
    /**
96
     * 获取Hash中所有值
97
     */
98
    public Map<Object, Object> hGetAll(String key) {
99
        return redisTemplate.opsForHash().entries(key);
100
    }
101

102
    /**
103
     * 设置整个Hash
104
     */
105
    public void hSetAll(String key, Map<String, Object> map) {
106
        redisTemplate.opsForHash().putAll(key, map);
107
    }
108

109
    /**
110
     * 删除Hash中的字段
111
     */
112
    public Long hDelete(String key, Object... fields) {
113
        return redisTemplate.opsForHash().delete(key, fields);
114
    }
115

116
    /**
117
     * 判断Hash中是否存在该字段
118
     */
119
    public Boolean hHasKey(String key, String field) {
120
        return redisTemplate.opsForHash().hasKey(key, field);
121
    }
122

123
    // =============================List类型操作=============================
124

125
    /**
126
     * 获取List中的值
127
     */
128
    public Object lGet(String key, long index) {
129
        return redisTemplate.opsForList().index(key, index);
130
    }
131

132
    /**
133
     * 获取List指定范围内的值
134
     */
135
    public List<Object> lGet(String key, long start, long end) {
136
        return redisTemplate.opsForList().range(key, start, end);
137
    }
138

139
    /**
140
     * 从右边插入
141
     */
142
    public Long lPush(String key, Object value) {
143
        return redisTemplate.opsForList().rightPush(key, value);
144
    }
145

146
    /**
147
     * 从右边弹出
148
     */
149
    public Object rPop(String key) {
150
        return redisTemplate.opsForList().rightPop(key);
151
    }
152

153
    /**
154
     * 获取List长度
155
     */
156
    public Long lSize(String key) {
157
        return redisTemplate.opsForList().size(key);
158
    }
159
}

展开收起

1.5 使用Redis工具类#

1
@Service
2
public class UserService {
3

4
    @Autowired
5
    private RedisUtils redisUtils;
6

7
    public User getUserById(String userId) {
8
        // 先从缓存获取
9
        Object cached = redisUtils.get("user:" + userId);
10
        if (cached != null) {
11
            return (User) cached;
12
        }
13

14
        // 缓存没有，从数据库查询
15
        User user = userMapper.selectById(userId);
16

17
        // 存入缓存，设置1小时过期
18
        if (user != null) {
19
            redisUtils.set("user:" + userId, user, 3600);
20
        }
21

22
        return user;
23
    }
24

25
    public void updateUser(User user) {
26
        // 更新数据库
27
        userMapper.updateById(user);
28

29
        // 删除缓存（保证一致性）
30
        redisUtils.delete("user:" + user.getId());
31
    }
32
}

展开收起

2、项目中非首次使用Redis#

直接可以使用 Ctrl + Shift + R 全局搜索redis，参考别人的代码是如何使用的，照葫芦画瓢（这个技能很重要）。

三、项目中使用Redis的常见场景#

1、缓存热点数据#

有些图表数据来源的表数据较多，处理过程复杂，导致接口响应慢，可以使用Redis缓存。

1
public List<DataVO> getChartData(String type) {
2
    String cacheKey = "chart:data:" + type;
3

4
    // 先查缓存
5
    Object cached = redisUtils.get(cacheKey);
6
    if (cached != null) {
7
        return (List<DataVO>) cached;
8
    }
9

10
    // 查询数据库并处理
11
    List<DataVO> data = processData(type);
12

13
    // 存入缓存，5分钟过期
14
    redisUtils.set(cacheKey, data, 300);
15

16
    return data;
17
}

展开收起

2、存储验证码/Token#

1
// 存储验证码，5分钟过期
2
public void saveVerifyCode(String phone, String code) {
3
    redisUtils.set("verify:" + phone, code, 300);
4
}
5

6
// 验证验证码
7
public boolean verifyCode(String phone, String code) {
8
    Object cached = redisUtils.get("verify:" + phone);
9
    return code.equals(cached);
10
}

3、分布式锁#

使用Redis实现分布式锁，防止重复操作：

1
public boolean tryLock(String lockKey, String requestId, int expireTime) {
2
    Boolean result = redisTemplate.opsForValue()
3
        .setIfAbsent(lockKey, requestId, expireTime, TimeUnit.SECONDS);
4
    return Boolean.TRUE.equals(result);
5
}
6

7
public boolean releaseLock(String lockKey, String requestId) {
8
    String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
9
    RedisScript<Long> redisScript = RedisScript.of(script, Long.class);
10
    Long result = redisTemplate.execute(redisScript, Collections.singletonList(lockKey), requestId);
11
    return result != null && result == 1L;
12
}

推荐使用Redisson实现分布式锁：

1
<dependency>
2
    <groupId>org.redisson</groupId>
3
    <artifactId>redisson-spring-boot-starter</artifactId>
4
    <version>3.23.4</version>
5
</dependency>

1
@Autowired
2
private RedissonClient redissonClient;
3

4
public void doSomething() {
5
    RLock lock = redissonClient.getLock("myLock");
6
    try {
7
        // 尝试获取锁，最多等待10秒，锁30秒后自动释放
8
        if (lock.tryLock(10, 30, TimeUnit.SECONDS)) {
9
            // 执行业务逻辑
10
        }
11
    } finally {
12
        if (lock.isHeldByCurrentThread()) {
13
            lock.unlock();
14
        }
15
    }
16
}

展开收起

4、计数器#

1
// 点赞数增加
2
public void likeArticle(String articleId) {
3
    redisUtils.increment("article:like:" + articleId);
4
}
5

6
// 获取点赞数
7
public Long getLikeCount(String articleId) {
8
    Object count = redisUtils.get("article:like:" + articleId);
9
    return count == null ? 0L : Long.parseLong(count.toString());
10
}

5、限流#

使用Redis实现简单的限流：

1
public boolean allowRequest(String userId, int maxCount, int seconds) {
2
    String key = "rate:" + userId;
3
    Long count = redisUtils.increment(key);
4

5
    if (count == 1) {
6
        redisUtils.expire(key, seconds);
7
    }
8

9
    return count <= maxCount;
10
}

四、缓存三大问题#

1、缓存穿透#

问题：查询一个不存在的数据，缓存中没有，数据库中也没有。导致每次请求都穿透缓存直接查询数据库。

解决方案：

方案	说明
缓存空值	查询结果为空时，也将空值缓存起来，设置较短的过期时间
布隆过滤器	在查询前先判断数据是否可能存在，不存在直接返回

1
public User getUserById(String userId) {
2
    Object cached = redisUtils.get("user:" + userId);
3
    if (cached != null) {
4
        if ("NULL".equals(cached)) {
5
            return null;  // 命中空值
6
        }
7
        return (User) cached;
8
    }
9

10
    User user = userMapper.selectById(userId);
11
    if (user != null) {
12
        redisUtils.set("user:" + userId, user, 3600);
13
    } else {
14
        // 缓存空值，5分钟过期
15
        redisUtils.set("user:" + userId, "NULL", 300);
16
    }
17
    return user;
18
}

展开收起

2、缓存击穿#

问题：某个热点key过期，此时大量请求同时查询这个key，全部穿透到数据库。

解决方案：

方案	说明
热点数据永不过期	对于真正的热点数据，可以不设置过期时间
加互斥锁	只允许一个线程去查询数据库，其他线程等待

1
public User getUserWithLock(String userId) {
2
    Object cached = redisUtils.get("user:" + userId);
3
    if (cached != null) {
4
        return (User) cached;
5
    }
6

7
    // 获取分布式锁
8
    String lockKey = "lock:user:" + userId;
9
    try {
10
        if (tryLock(lockKey, "1", 10)) {
11
            // 再次检查缓存
12
            cached = redisUtils.get("user:" + userId);
13
            if (cached != null) {
14
                return (User) cached;
15
            }
16

17
            // 查询数据库
18
            User user = userMapper.selectById(userId);
19
            if (user != null) {
20
                redisUtils.set("user:" + userId, user, 3600);
21
            }
22
            return user;
23
        } else {
24
            // 获取锁失败，等待后重试
25
            Thread.sleep(50);
26
            return getUserWithLock(userId);
27
        }
28
    } finally {
29
        releaseLock(lockKey, "1");
30
    }
31
}

展开收起

3、缓存雪崩#

问题：大量缓存key在同一时间集中过期，导致所有请求都落到数据库上。

解决方案：

方案	说明
过期时间加随机值	在基础过期时间上增加随机值，避免同时过期
多级缓存	使用多级缓存，如本地缓存 + Redis
熔断降级	当数据库压力过大时，进行熔断降级

1
// 过期时间加随机值
2
public void setWithRandomExpire(String key, Object value, long baseTime) {
3
    long randomTime = baseTime + new Random().nextInt(300);
4
    redisUtils.set(key, value, randomTime);
5
}

五、缓存一致性策略#

对于缓存一致性问题，直接先更新数据库，再删除缓存就能满足大部分的场景。

1
更新数据库 -> 删除缓存 -> 下次查询时重新写入缓存

为什么是删除缓存而不是更新缓存？

策略	优点	缺点
删除缓存	简单，避免无效计算	下次查询需要重新加载
更新缓存	下次查询更快	可能更新了但没被使用，浪费资源

延时双删策略（更高一致性要求）：

1
删除缓存 -> 更新数据库 -> 延时几百毫秒 -> 再次删除缓存

六、Redis常用命令#

1、String类型#

命令	说明
SET key value	设置键值
GET key	获取值
DEL key	删除键
EXPIRE key seconds	设置过期时间
SETNX key value	不存在时才设置
INCR key	自增1
DECR key	自减1

2、Hash类型#

命令	说明
HSET key field value	设置Hash字段值
HGET key field	获取Hash字段值
HGETALL key	获取Hash所有字段和值
HDEL key field	删除Hash字段
HEXISTS key field	判断字段是否存在

3、List类型#

命令	说明
LPUSH key value	从左边插入
RPUSH key value	从右边插入
LPOP key	从左边弹出
RPOP key	从右边弹出
LRANGE key start stop	获取指定范围元素

4、通用命令#

命令	说明
KEYS pattern	查找匹配的键（生产环境慎用）
TTL key	查看剩余过期时间
TYPE key	查看键的类型
EXISTS key	判断键是否存在
FLUSHDB	清空当前数据库

七、常见问题排查#

1、连接超时#

可能原因：

Redis服务未启动
防火墙未放行端口
配置的IP或端口错误
密码错误

排查命令：

Terminal window

1
# 测试端口连通性
2
telnet 127.0.0.1 6379
3

4
# 使用redis-cli连接测试
5
redis-cli -h 127.0.0.1 -p 6379 -a password

2、内存占用过高#

排查方法：

Terminal window

1
# 查看Redis内存使用情况
2
redis-cli info memory
3

4
# 查看大key
5
redis-cli --bigkeys

3、响应慢#

可能原因：

执行了慢查询（如KEYS *）
存在大key
网络延迟

工作中SVN的使用

Sat, 01 Aug 2026 00:00:00 GMT

一、svn是什么？#

集中式版本控制（Centralized VCS）。
所有历史版本集中存放在一台服务器，本地只保留当前工作副本。

核心概念：

1
中央仓库：SVN 采用客户端-服务器模式。所有文件的历史版本都集中存储在一个中央服务器上。
2
工作副本：开发者从中央服务器“检出”一份文件到自己的本地电脑，这份本地的文件就是工作副本。
3
版本记录：SVN 会记录每一次文件提交，包括：谁、在什么时候、修改了哪些内容、以及为什么修改。每个版本都有一个唯一的版本号。
4
提交与更新：
5
提交：当你修改完本地代码后，通过“提交”操作将变更同步到中央服务器，从而创建一个新的版本。
6
更新：通过“更新”操作，将本地工作副本与中央服务器的最新版本同步，获取其他同事的修改。

二、有了git，为啥还需要svn?#

历史原因：大量现存的老项目跑在 SVN 上，迁移成本和风险高。
场景需求：对于需要严格目录级权限控制和频繁处理大型二进制文件（如游戏美术资源）的团队，SVN 的方案可能更简单、更稳定。
团队习惯：对于非技术背景成员较多或团队习惯已定的情况，SVN 的统一、简单的工作流更容易管理和维护。

结论就是：工具没有绝对的好坏，只有是否适合当前的团队和项目。 Git 在绝大多数软件开发场景下是更优的选择，但 SVN 在它的特定领域内，依然是一个可靠、甚至是更合适的选择。

三、svn的安装#

svn是分为服务端和客户端的。对于我们使用者来说只用安装svn的客户端就行。就像git一样我们本地也是需要安装git的客户端，而服务端比如gitlab是不需要我们安装的。svn客户端的安装很简单，除了下图需要单独设置一下，其他的只要一直点击下一步即可！只有安装的时候选择下面这个 Command Line Client Tools 的时候，你的安装目录的bin目录下面才有svn.exe文件。这样，后续，在idea中集成svn的时候才可以选择它。

svn客户端安装

四、SVN的基本操作#

1、检出操作#

拿到仓库地址URL ,鼠标右击空白区域-点击SVN检出

右击空白区域

在检出界面，填仓库地址URL ，默认检出地址，就是你点击的空白区域所在目录

检出

认证界面，填写用户名/密码

认证界面

出现如下界面，便是检出成功

检出成功

2、提交文件#

新增文件需要add之后，才能commit到远程仓库，或者在commit的时候选择未add的文件进行提交，修改的文件commit的时候默认是勾选的。当前目录空白区域鼠标右击，然后点击commit的时候，是commit当前目录下未commit的文件。如果点击某个文件右击的话，commit的就是当前文件。

commit

出现如下界面，填写提交信息后点击Ok提交：

commit信息

3、更新文件#

更新
4、查看历史版本#

通过查看历史版本，可以看到别人的提交记录，以及提交了什么文件。

查看历史日志

点击之后出现如下历史提交记录界面

提交日志

5、回滚#

点击下面按钮，进入回滚界面

回退版本

进入回退版本界面，点击Show log查看历史提交记录，查看要回退的版本号

提交日志

填写要回退的版本的版本号进行回退

回退版本2

6、分支操作#

正常情况需要进行分支操作的时候，我们需要建立如下三个目录：

目录名	用途	优点
trunk	主开发线，存放最新的稳定代码	便于集中开发、持续集成
branches	用于并行开发、功能分支、修复分支等	支持多人协作、功能隔离、风险控制
tags	用于标记发布版本（如 v1.0、v2.0），通常只读，不修改	便于版本回溯、发布管理、归档

6.1 新建分支#

基于主干新建分支的时候，右击主干分支，按下图选择新建分支。

新建分支

进入如下界面，填写对应信息，新建分支

新建分支-详情

需要注意的是，新建完分支之后，需要在update一下，本地对应目录才会有对应分支代码。

6.2 合并分支#

将分支内容合并到主干（branch => trunk），按如下步骤进行合并：

右击主干目录，点击 Merge 进行合并

合并1

进入如下界面直接点击下一步即可

合并2

进入如下界面，填写对应合并信息后，点击Next

合并3

一般按照默认就好先点击 Test merge ，进行合并测试，合并测试没问题，再点击 Merge 合并

合并4

需要注意的是，合并仅仅是合并到本地文件夹目录，所以合并完成后，记得要Commit提交到SVN。

合并5

6.3 切换分支#

右击需要切换分支的工作目录，选择 Switch 进入切换分支模块

切换分支

进入切换分支界面之后，选择要切换的分支，点击 OK

切换分支2

7、文件冲突#

当你在合并代码或者更新代码的时候，就有可能会出现冲突，发生文件冲突的时候，会出现如下界面：

冲突1

右击冲突文件，选择 Edit conflicts，编辑冲突文件

冲突2

进入如下界面后，按照图示进行冲突处理：

冲突3

冲突处理完成之后，点击 Save 保存

冲突4

如果冲突处理完成，并且点击的 Mark as resolved ，即标记为已解决，则之前文件前的冲突标识消失。

冲突5

五、idea集成SVN的基本使用#

1、idea集成svn#

idea的settings里面找到Version Control里面的 Subversion下配置本地安装的svn路径

idea集成svn

idea上方工具栏出现 SVN，则说明idea集成SVN成功!

idea集成svn2

2、提交、更新代码#

点击下图对应按钮，即可提交代码、更新代码。

idea-提交更新

点击提交代码，会出现如下界面，选择要提交的文件以及填写提交信息，之后点击 Commit 提交代码。需要注意的是SVN是没有

本地仓库的概念的，提交就是直接提交到远程仓库，类似GIT的提交界面中的 Commit and Push ！

idea-提交详情

idea右下角弹出如下界面就是提交成功！

idea-提交成功

点击更新代码会出现如下界面，直接点击 OK 便是更新当前分支代码。

idea-更新代码

3、查看历史版本#

SVN查看历史版本需要选中你要查看的文件，如果是要查看当前工程的历史提交记录，则右击工程目录。如果没有，选中任何文件，则查看的默认是你当前编辑区域窗口打开的文件的历史记录。

idea-历史记录

点击 Show History之后便会出现如下历史记录界面。

idea-历史记录2

4、回滚#

回滚也是点击更新代码的按钮，然后，进入如下界面之后就不能直接点击 OK了，而是按照下图步骤进行操作：

idea-回滚

5、分支操作#

5.1 新建分支#

SVN → Subversive → Branch or Tag 创建新的分支

idea-创建分支1

点击新建分支，出现如下界面，可按图示进行分支创建

idea-创建分支2

5.2 切换分支#

如果上面我们没有勾选，切换分支，那么此时我们也可以通过如下操作来切换分支。同样，切换分支也是点击更新代码的按钮，然后，按照下图进行操作：

idea-切换分支

5.3 合并分支#

按照下图操作，进入选择分支界面。下面的操作是将其他分支代码合并到当前分支。

idea-合并分支

进入选择分支界面，选择需要合并过来的分支。

idea-合并分支2

点击 Merge All

idea-合并分支3

点击 Continue merge 完成合并！

idea-合并分支4

6、文件冲突#

idea里面的冲突文件会爆红，如下图，右击冲突文件，按照下图点击 Resolve Text Conflict 解决冲突

idea-解决冲突

出现如下界面，根据需要按照下图示进行对应操作

idea-解决冲突2

当选则手动合并的时候，会出现如下界面，可根据需求按照下图示做对应操作

idea-解决冲突3

处理冲突之后，文件变蓝色，成待commit文件

idea-解决冲突4

基本的网络知识

Sat, 01 Aug 2026 00:00:00 GMT

一、为什么 Java 开发要学网络知识？#

很多刚入职的同学会觉得： “我是写 Java 的，又不是搞运维的，为什么还要学网络？”

因为在实际工作中，你经常会遇到这些问题：

前端说：接口访问不了
测试说：环境调不通
运维说：服务端口没开
你自己发现：数据库连不上、Redis 连不上、调用其他服务超时

这些问题表面上看像“代码问题”，实际上很多时候是网络、环境、端口、配置的问题。

所以，作为 Java 开发，网络知识不需要学得特别深，但一定要掌握最基础、最常用、工作中最容易遇到的部分。

二、网络区域划分#

2.1 什么是网络区域划分？#

网络区域划分是将网络按照安全级别和访问权限划分为不同的区域，每个区域有不同的安全策略和访问控制规则。这种划分可以有效保护内网核心资源，同时为外部用户提供必要的服务。

2.2 三大网络区域#

区域	全称	说明	安全级别
内网	Intranet	组织的核心网络，用于内部员工和资源之间的通信	最高
外网	Public Internet	公共互联网，连接到组织网络的最外层区域	最低
DMZ区	Demilitarized Zone	介于内网和外网之间的隔离区，也称”非军事化区”	中等

2.3 各区域详细说明#

2.3.1 内网（Intranet）#

定义：内网是组织内部使用的私有网络，只有经过授权的用户和设备才能访问。

特点：

位于防火墙内部，与外网隔离
存放核心业务数据、数据库、内部应用服务器
使用私有IP地址（如：10.x.x.x、172.16.x.x、192.168.x.x）
安全性最高，外部用户无法直接访问

访问方式：

VPN（Virtual Private Network）：虚拟专用网络，通过加密通道从外网安全访问内网
堡垒机：统一的安全入口，所有对内网的访问都需要通过堡垒机进行审计

注意：VPN 和堡垒机不是必须一起使用的。不同公司安全策略不同，有的只需要 VPN，有的需要 VPN + 堡垒机双重认证。

典型应用场景：

1
场景一：只需 VPN
2
在家办公 → 连接VPN → 访问内网资源
3

4
场景二：VPN + 堡垒机
5
在家办公 → 连接VPN → 通过堡垒机认证 → 访问内网资源

2.3.2 外网（Public Internet）#

定义：外网就是公共互联网，是全球互联的网络环境。

特点：

任何人都可以访问
安全风险最高，容易受到攻击
使用公网IP地址

2.3.3 DMZ区域（了解）#

定义：DMZ是介于内网和外网之间的隔离区域，用于放置对外提供服务的服务器。

特点：

从外网可以访问DMZ区
从DMZ区不能直接访问内网（需要特殊授权）
即使DMZ区被攻破，内网仍然安全

典型架构：

DMZ区常见服务：

Web服务器（Nginx、Apache等）
API网关
邮件服务器
FTP服务器
VPN服务器

三、IP、端口、域名等#

3.1 IP#

IP地址是网络上设备（网络接口）的唯一标识，类似于我们的家庭地址。通过IP地址，可以找到网络中的某台具体设备。严格来说，IP地址对应的是设备上的网络接口，一台设备可以有多个网卡、多个IP地址。

简单理解：

1
一台主机可以有多个网卡
2
   ↓
3
就像一栋楼可以有多个门
4
   ↓
5
每个网卡对应一个IP地址
6
   ↓
7
就像每个门有一个门牌号
8
   ↓
9
通过门牌号找到门，通过门进入大楼

IP地址分类：

类型	说明	示例
IPv4	32位地址，常用格式	192.168.1.100
IPv6	128位地址，新一代	2001:0db8:85a3:0000:0000:8a2e:0370<7334>

私有IP地址范围（内网使用）：

地址范围	用途
10.0.0.0 - 10.255.255.255	A类私有地址
172.16.0.0 - 172.31.255.255	B类私有地址
192.168.0.0 - 192.168.255.255	C类私有地址（最常见）

3.2 端口#

端口是应用程序与网络通信的通道，一个IP地址可以有65535个端口（范围是0-65535，其中0是保留端口，实际常用的是1024以上的端口）。

简单理解：

1
一个IP地址对应一台主机
2
   ↓
3
一台主机可以运行多个应用
4
   ↓
5
每个应用使用不同的端口
6
   ↓
7
通过IP+端口可以找到具体的应用

生活类比：

1
IP地址 = 公司地址（如：北京市朝阳区xx大厦）
2
端口   = 部门/房间号（如：8080房间）
3

4
要找到具体的人，需要：地址 + 房间号
5
要访问具体的应用，需要：IP + 端口

常见服务默认端口：

服务	端口	说明
MySQL	3306	数据库服务
Redis	6379	缓存服务
Tomcat	8080	Java Web服务器
Nginx	80/443	Web服务器/反向代理
SSH	22	远程登录服务
HTTP	80	超文本传输协议
HTTPS	443	加密的超文本传输协议

3.3 域名#

域名就是给 IP 起的更容易记忆的名字。

例如：

www.baidu.com
api.test.company.com

因为用户和开发都不方便记 IP，所以通常通过域名访问服务。

3.4 DNS#

DNS 的作用就是： 把域名解析成 IP 地址。

比如你访问：

1
api.test.company.com

系统会先通过 DNS 找到它对应的 IP，然后再去访问目标机器。

DNS 解析顺序（了解）：

1
浏览器缓存
2
  ↓ 未命中
3
操作系统缓存
4
  ↓ 未命中
5
hosts 文件
6
  ↓ 未命中
7
本地 DNS 服务器
8
  ↓ 未命中
9
上级 DNS 服务器（递归查询）
10
  ↓ 最终返回
11
拿到 IP 地址，发起访问

当 ping 域名不通，但 ping IP 能通 时，就可能是域名解析有问题。

3.5 hosts 文件#

hosts 文件可以手动指定“某个域名对应哪个 IP”。

例如：

1
192.168.1.20 api.test.company.com

意思是：访问这个域名时，直接去找这个 IP，不再走 DNS。

常见作用：

本地调试
临时切换环境
测试域名解析问题

注意：如果 hosts 配错了，会导致你访问到错误的服务。

四、127.0.0.1、localhost、0.0.0.0 的区别#

这个是 Java 开发必须知道的基本点，必须弄清楚。

理解这三个地址，要从两个角度来看：

服务端角度：你的服务启动时，监听在哪个地址？（决定了谁能连进来）
客户端角度：你要访问本机的某个服务，地址该填什么？（决定了你能不能连上）

4.1 127.0.0.1#

表示本机回环地址，只能本机访问自己。

服务端角度 — 监听：

如果服务监听在 127.0.0.1:8080，那么只有当前机器自己能访问，其他机器访问不了。 A mysql 127.0.0.1 B

1
服务监听：127.0.0.1:8080
2
   ↓
3
本机能访问：✅
4
其他机器访问：❌

客户端角度 — 访问本地服务：

在本地开发时，你的代码需要连接本机的服务，地址就填 127.0.0.1。这是最常见的用法：

1
# application.yml 连接本地数据库
2
spring:
3
  datasource:
4
    url: jdbc:mysql://127.0.0.1:3306/mydb
5

6
# 连接本地 Redis
7
spring:
8
  redis:
9
    host: 127.0.0.1
10
    port: 6379

4.2 localhost#

通常表示本机，本质上一般会解析到 127.0.0.1。

所以大多数情况下，localhost 和 127.0.0.1 可以理解成一样。

客户端角度 — 访问本地服务：

localhost 和 127.0.0.1 在使用上基本等价，都可以用来访问本机服务：

1
http://localhost:8080/api/test
2
http://127.0.0.1:8080/api/test
3

4
jdbc:mysql://localhost:3306/mydb
5
jdbc:mysql://127.0.0.1:3306/mydb

细微区别（了解即可）：localhost 需要经过 DNS 解析，而 127.0.0.1 是直接写死的 IP。极少数情况下 localhost 可能解析失败，写 127.0.0.1 更稳妥。

4.3 0.0.0.0#

表示监听所有网卡地址。

服务端角度 — 监听：

如果服务监听在 0.0.0.0:8080，那就意味着：

本机可以访问
局域网其他机器也可以访问
外部机器是否能访问，还要看防火墙、安全组、白名单等限制

1
服务监听：0.0.0.0:8080
2
   ↓
3
本机能访问：✅
4
局域网其他机器访问：✅（前提：防火墙放行）
5
外部机器访问：取决于防火墙、安全组等

4.4 两个角度的总结#

地址	服务端监听时	客户端访问本机服务时
127.0.0.1	只允许本机访问	填这个地址，连接本机服务
localhost	同 127.0.0.1	和 127.0.0.1 基本等价
0.0.0.0	允许所有网卡访问	一般不填这个，它只用于监听

注意：0.0.0.0 是监听地址，不是访问地址。你不会在配置文件里写 host: 0.0.0.0 去连接某个服务，它只在服务端启动时指定”监听所有网卡”。

五、常见网络工具#

工具速查表：

场景	推荐工具	说明
测试网络是否可达	ping	检测 IP/域名是否能通
测试端口是否开放	telnet	检测目标端口是否能连通
测试 HTTP 接口是否可用	curl	模拟 HTTP 请求，查看响应
查看数据包路由路径	tracert / traceroute	排查网络中间节点问题
查看端口监听情况	netstat	确认服务是否在监听
查看端口占用详情	lsof	确认哪个进程占用了端口
查看 Java 进程	jps / ps	确认 Java 服务是否启动
结束进程	kill	停止异常进程

5.1 ping#

作用：测试目标 IP 是否可达。

1
ping 192.168.1.10
2
ping www.baidu.com

说明

能 ping 通：说明网络层大概率可达
不能 ping 通：说明网络可能不通、被禁 ping、域名解析失败等

注意

ping 通 ≠ 服务可用

因为 ping 只说明 IP 层可能通，不代表应用端口一定通。

5.2 telnet#

作用：测试某个端口能不能连通。

1
telnet 192.168.1.10 3306
2
telnet 192.168.1.20 8080

说明

连得上：说明这个端口是通的
连不上：可能是服务没启动、端口没监听、防火墙没放行

Windows开启telnet功能：

1
控制面板 → 程序 → 启用或关闭Windows功能
2
→ 勾选"Telnet客户端"
3
→ 确定并等待安装完成

5.3 curl（了解）#

作用：测试 HTTP 接口是否可用。

说明：日常开发中推荐使用 Postman 等图形化工具测试接口。curl 的主要使用场景是 SSH 到服务器上排查问题时，服务器上没有 Postman，只能用命令行。
注意：Windows 10 及以上系统自带 curl，较老系统可安装 Git Bash 后使用。

作用

测试 HTTP 接口是否能访问
查看响应头、响应体
模拟 GET/POST 请求

5.3.1 访问一个 GET 接口#

1
curl http://127.0.0.1:8080

5.3.2 查看响应头#

1
curl -i http://127.0.0.1:8080

5.3.3 发送 POST 请求#

1
curl -X POST -H "Content-Type: application/json" -d '{"id":1}' http://127.0.0.1:8080/api/test

5.3.4 查看详细请求过程#

1
curl -v http://127.0.0.1:8080

可以看到完整的请求头、响应头、TLS 握手等信息，排查问题非常有用。

5.3.5 只看 HTTP 状态码#

1
curl -o /dev/null -s -w '%{http_code}' http://127.0.0.1:8080/api/test

输出示例：200、404、500，快速判断接口是否正常。

注意

ping 看 IP 通不通
telnet 看端口通不通
curl 看 HTTP 接口是否真的可用

5.4 tracert / traceroute（了解）#

作用：查看数据包经过哪些路由节点到达目标机器。

Windows A B

1
tracert www.baidu.com

Linux

1
traceroute www.baidu.com

场景

当你怀疑网络路径中间某一跳出了问题时，可以用它做辅助排查。

5.5 netstat#

作用：查看端口监听情况。

Windows

1
netstat -ano | findstr 8080

Linux

1
netstat -tunlp | grep 8080

场景

查看某端口是否已启动
查看端口是否被占用
查看服务是否在监听

5.6 lsof#

Linux 中查看端口占用、文件占用很常用。

1
lsof -i :8080

注意：lsof 是 Linux 专属命令，Windows 上没有对应工具，可使用 netstat -ano | findstr 端口号 代替。

场景

排查：

端口被谁占用了
某服务是不是在监听该端口

5.7 ps / jps#

查看 Linux 进程

1
ps -ef | grep java

jps

查看 Java 进程

1
jps

场景

确认 Java 服务是否启动
找到对应进程 ID

5.8 kill#

结束进程。

1
kill -15 12345
2
kill -9 12345

注意

kill -15：正常停止
kill -9：强制杀死，谨慎使用

六、访问控制：防火墙、安全组、白名单与中间链路策略#

6.1 访问控制#

访问控制可以理解为：

控制“谁可以访问谁”、“通过什么方式访问”、“哪些访问要被拦截”的一整套规则。

对于 Java 开发来说，访问控制并不只是“服务器上有没有开端口”这么简单。一个请求从源头到目标服务，中间可能会经过多层限制，例如：
- 服务器本机防火墙
- 云平台安全组
- 白名单限制
- 中间链路上的网络设备或安全策略
所以你要建立一个意识：

服务访问不了，不一定是代码问题，也不一定只是目标机器本身的问题，访问链路上的任意一层控制策略都可能拦住请求。

6.2 常见的访问控制位置#

实际工作中，常见的访问控制可能出现在以下几个位置：

6.2.1 服务器本机防火墙#

（1）firewalld

这是很多 CentOS 7 / RHEL 7 系统默认使用的防火墙管理工具。特点是：

命令相对简单
比较适合日常管理
现在企业里比较常见

常用命令

1
#查看防火墙状态
2
systemctl status firewalld
3
#关闭防火墙
4
systemctl stop firewalld
5
#重启防火墙
6
systemctl restart firewalld
7
#永久开放端口
8
firewall-cmd --permanent --zone=public --add-port=161/udp
9
firewall-cmd --permanent --zone=public --add-port=3306/tcp
10
#永久关闭端口
11
firewall-cmd --zone=public --remove-port=3306/tcp --permanent
12
#刷新配置，立即生效
13
firewall-cmd --reload
14
#查看防火墙
15
firewall-cmd --zone=public --list-all

展开收起

（2）iptables

这是 Linux 里更底层、更经典的防火墙工具。特点是：

功能强大
规则更灵活
配置更复杂一些

很多老项目、老服务器，或者某些运维场景里仍然会看到它。

常用命令

1
#查看防火墙状态
2
systemctl status iptables
3
#关闭防火墙
4
systemctl stop iptables
5
#重启防火墙
6
systemctl restart iptables
7
#查看防火墙策略
8
iptables -L
9
#编辑防火墙策略
10
vim /etc/sysconfig/iptables
11
#允许访问3306端口
12
-A INPUT -p tcp  --dport 3306 -j ACCEPT
13
-A OUTPUT -p tcp --sport 3306 -j ACCEPT

注意：iptables 修改后需要保存并重启才能永久生效：

Terminal window

1
# 保存规则
2
service iptables save
3
# 或
4
iptables-save > /etc/sysconfig/iptables
5

6
# 重启 iptables 使配置生效
7
systemctl restart iptables

6.2.2 云平台安全组#

如果服务部署在云服务器上，还可能有云平台提供的安全组策略。即使服务器本机已经开放端口，如果安全组没放开，外部仍然访问不了。

6.2.3 白名单#

白名单就是：

只允许特定来源访问，其他来源一律拒绝。

常见于：

数据库
Redis
MQ
第三方接口回调
管理后台

典型现象

你本机能连，别人机器不能连
测试环境能访问，开发环境不能访问
某台服务器能调通，另一台服务器调不通

这种情况就要考虑是不是来源限制导致的。

6.2.4 中间链路策略#

很多同学一想到访问控制，只会想到服务器上的 firewalld 或 iptables。但真实公司网络里，中间链路也可能有访问控制。

常见中间链路策略

网络防火墙设备
路由器 ACL
交换机访问控制策略
网关访问策略
负载均衡访问控制
WAF 拦截规则

6.3 作为 Java 开发，你最该记住什么#

这一节你不用去背复杂规则，但至少要记住下面这几点：

1）服务访问不了，不一定是代码问题

有可能是：

端口没开放
防火墙拦截了
安全组没放行
白名单没加
中间链路有墙

2）先确认服务是否真的启动、端口是否监听

比如先查：

1
netstat -tunlp | grep 8080
2
lsof -i :8080

如果服务都没监听，那就不是防火墙问题，而是服务本身没起来。

3）防火墙和安全组可能同时限制访问

你不能只看服务器本机。如果在云环境里，还要考虑云平台的安全组规则。如果网络中间经过其他有墙的设备，也要考虑这个中间链路设备的墙。

4）生产环境不要随便改防火墙

线上环境改防火墙规则一般要按公司流程走，很多公司由运维统一处理。你要做的是：

能意识到这是排查方向
知道怎么和运维沟通
能提供清楚的信息：IP、端口、协议、环境

6.4 和运维沟通时怎么说更专业#

比如你可以这样说：

“服务已经正常启动，8080 端口也在监听，本机访问正常。麻烦帮忙确认一下测试环境这台机器的防火墙/安全组是否已放行 8080 端口。”

或者：

“我这边怀疑不是代码问题，可能是网络访问策略限制，麻烦帮忙看下目标机器的端口开放情况和白名单配置。”

这样沟通会比“接口不通，帮我看看”更专业很多。

七、服务访问与网络连通性问题的排查顺序（重要）#

遇到下面这类问题时：

服务访问不了
数据库连不上
接口调不通
服务间调用失败

建议优先按下面这个顺序查，不要一上来就怀疑代码，也不要一上来就只看网络。

第一步：先确认目标信息是否正确

先确认最基础的信息有没有写错：

IP 对不对
端口对不对
域名对不对
接口路径对不对
当前是不是对应环境（dev / test / pre / prod）
配置文件里填的是不是正确地址

很多问题其实在这一步就能发现，比如：

连错环境
连错机器
端口写错
域名写错
调错接口路径

第二步：确认目标服务/应用是否真的存在、是否正常运行

这是非常关键的一步。如果服务本身都没启动，后面的网络排查意义就不大。

使用第五章介绍的 netstat、lsof、ps、jps 命令，确认两件事：

应用有没有启动
应用有没有监听目标端口

如果服务没启动或端口没监听，那问题优先就不是网络，而是服务本身。

第三步：看网络是否可达

使用第五章 5.1 介绍的 ping 命令：

ping IP：看目标机器网络层是否可达
ping 域名：看域名解析和网络是否正常

如果 ping IP 通，但 ping 域名不通，优先怀疑 DNS 或 hosts 配置问题（见第三章 3.4、3.5）。

注意：ping 通不代表服务一定可用。ping 只说明 IP 层大概率可达，不代表目标端口一定开放。

第四步：看端口是否可达

如果目标机器可达，使用第五章 5.2 介绍的 telnet 命令测试目标端口：

1
telnet IP 端口

如果端口不通，常见原因有：

服务没启动或没监听该端口（回到第二步确认）
服务只监听了 127.0.0.1，外部无法访问（见第四章）
本机防火墙拦住了（见第六章）
云安全组没放开（见第六章）
白名单没加（见第六章）
中间链路策略拦截了访问（见第六章）

如果确认是端口被其他进程占用，可参考第八章的方法解决。

此时可以找运维人员，确认一下端口是否放开，然后再继续后续排查。

记住：本机能访问，不代表别人机器也能访问。 检查服务是否监听在 0.0.0.0 而非 127.0.0.1（见第四章）。

第五步：看 HTTP 接口是否真的可用（仅限 Web 服务 / HTTP 接口）

注意：如果目标是数据库、Redis、MQ 等非 HTTP 服务，端口通了就说明连通性没问题，可以跳过这一步。

如果是 Web 服务或 HTTP 接口，最好不要只停留在”端口通不通”，使用第五章 5.3 介绍的 curl 命令继续确认接口本身是否可用：

1
curl http://IP:端口/接口路径

如果 curl 不通，要继续排查：

服务日志
Nginx 配置
网关配置
服务监听地址
接口路径 / 请求方式是否正确（GET / POST）

第六步：最后结合应用日志进一步判断

很多问题表面上像“网络不通”，实际上可能是应用内部问题。

常见情况

服务启动失败
配置错误
数据库连接异常
Redis/MQ 连接异常
应用内部抛异常
Nginx/网关转发失败

所以排查时一定不要脱离日志。 网络排查和日志排查通常要结合起来看。

八、常见端口占用问题排查#

问题场景：启动应用时提示”端口已被占用”

原因：该端口已被其他进程使用

以下涉及的命令（netstat、lsof、ps、jps、kill）用法详见第五章。

8.1 Windows 系统#

第一步：查看端口占用情况（使用 5.5 介绍的 netstat）

1
netstat -ano | findstr 8080

输出结果最后一列数字就是进程ID（PID）。

第二步：查看进程详情

1
tasklist | findstr 12345

第三步：结束占用端口的进程

方式1：使用taskkill强制结束

1
taskkill /PID 12345 /F

方式2：打开任务管理器 → “详细信息”标签页 → 找到对应PID → 右键结束任务

8.2 Linux 系统#

第一步：查看端口占用情况（使用 5.5 的 netstat 或 5.6 的 lsof）

1
netstat -tunlp | grep 8080
2
# 或（推荐）
3
lsof -i :8080

第二步：查看进程详情（使用 5.7 的 ps / jps）

1
ps -ef | grep 12345
2
# 或查看Java进程
3
jps

第三步：结束占用端口的进程（使用 5.8 的 kill）

1
kill 12345        # 优雅结束（推荐）
2
kill -9 12345     # 强制结束

开发流程及开发中的术语

Sat, 01 Aug 2026 00:00:00 GMT

开发流程及开发中的术语#

一、一般开发流程#

注意：下面介绍的只是一个比较通用的开发流程。实际上，每家公司的流程可能都不一样，甚至同一个公司不同项目的流程也会有差异。所以入职之后，一定要尽早搞清楚你所在团队的实际开发流程——比如用什么分支管理、怎么提测、开发规范、谁来部署、环境有哪些、上线审批走什么流程等等。别等出了问题才去问，早点了解心里更有底，也能避免后续因为流程问题而内耗。

开发流程

二、开发流程关键步骤解释#

需求评审

评审需求是否清晰、可行、可验收。重点确认：
- 目标是什么（为什么做）
- 范围边界（做哪些 / 不做哪些）
- 验收标准（做到什么算完成）
- 技术评估：能不能做、有没有更简单的实现方式、是否需要提出替代方案，以及技术上的风险和依赖
建议：需求评审时建议录音（线下会议）或录屏（线上会议），方便后续回顾。会上讨论的东西可能很多，光靠脑子记容易遗漏关键细节，尤其是新人，有录音/录屏回头听一遍，理解会更到位。
举个例子：产品提出需求”在大屏上实时展示用户操作记录”。
- 目标：让运营人员能及时看到用户行为，便于监控和分析
- 范围边界：只展示操作记录，不包含用户个人信息；只在内部大屏展示，不做对外功能
- 验收标准：大屏能显示操作记录，延迟不超过1分钟
- 技术评估：实时同步开发成本高、容易出 bug、对服务器压力大。可以提出替代方案：“每5秒刷新一次”，既满足业务展示需求，又大幅降低实现难度和风险
项目经理分配任务

项目经理会把需求拆分成任务，分给不同角色（后端/前端/测试等）。有些项目经理会在分配任务时顺便问你“多久能做完”。这个时候不要为了显得厉害就当场拍时间，可以更稳妥地说： “我先把需求理解清楚，把实现方案和影响面梳理一下，再给你一个更准确的时间。” 这样既专业，也能避免因为信息不全导致估时不准。

根据任务进行排期

如果项目经理只分配了任务、没有给具体排期，那就需要开发人员自己先做排期。排期时不要只算写代码的时间，至少要把下面这些都算进去：

需求梳理/方案设计（复杂需求很重要）
编码实现
自测（主流程、边界、异常）
联调（和前端/其他服务对接）
修 bug + 回归验证
部署测试环境/提测沟通（如果你负责）你可以给出一个拆解后的时间，而不是一句“我估计两天”。这样项目经理更容易判断整体排期是否合理。

确认任务能否按时完成，有没有疑问

如果项目经理在分配任务时已经给了排期，那么在排期发出来之后，你要第一时间判断：这个时间是否合理、有没有卡点。

有问题一定要及时沟通，不要闷头硬扛到最后爆雷，影响整个版本。
沟通时不要只说“有难点”，要把难点说具体：卡在哪里、影响是什么、需要谁支持、有没有替代方案。很多你以为的难点，可能只是你还没见过类似实现——项目经理或同事一句话点一下，你就知道可以参考现有样例，复制改造就能解决。

根据需求进行设计开发

有些公司在开发前要求写设计文档（方案文档），那就按规范写并参与评审。不会写时可以找同事要一份模板参考。如果公司不强制要求，你也可以在需求复杂时自己简单写一版方案，目的不是走形式，而是通过设计，能够对需求有更深刻的理解。

当然，开发过程中如果对需求有疑问，仍然要及时跟产品经理沟通，避免做偏。

自测

代码写完后，先自己测一遍，把低级问题消灭掉。至少要验证：主流程、关键边界、常见异常，以及日志/错误码是否符合预期。
举个例子：假设你写了一个”根据用户ID查询订单”的接口，自测时至少要验证：
- 主流程：传入正常用户ID，能返回订单列表
- 关键边界：用户ID为空、用户ID不存在、用户有0条/1条/多条订单
- 常见异常：参数格式错误（如ID传了字符串）
- 日志/错误码：正常返回日志是否记录、异常时错误码和提示信息是否清晰
与前端联调

自测通过后，与前端进行联调，重点是把”各自能跑”变成”整体能跑”。要对齐：
- 接口字段（名称、类型、是否可为空、默认值）
- 入参校验规则
- 返回结构与异常处理（错误码、提示信息）
联调过程中前端往往也会发现一些问题（字段不一致、边界漏测、错误码不匹配、后端异常报错等），这些都需要你配合修复。
提测

联调完成后，将个人分支的代码合并到测试分支（如 test 或 develop），部署到测试环境，提交给测试团队验证。

测试过程中大概率会发现 bug，你需要在个人分支上修复，修复后再次合并到测试分支、部署测试环境，让测试同学重新验证。

注意：不要在测试通过之前就合并到主分支，避免有问题的代码污染主分支。
代码评审（CR）与上线发布

测试全部通过后，将代码推送到远程仓库，提交合并请求（MR/PR）到主分支（如 master 或 main），等待同事进行代码评审。

为什么 CR 放在这个阶段？ 因为测试过程中会反复修复 bug，如果提前做 CR，这些修复的代码就没有被 review。在合并到主分支时做 CR，审的就是最终稳定版本，所有改动都包含在内。

CR 的目的不是挑毛病，而是：
- 保证质量：发现潜在的逻辑漏洞、边界问题、安全隐患
- 知识共享：让团队成员了解彼此的改动，避免信息孤岛
- 统一规范：确保代码风格、命名、结构符合团队标准
新人必做：入职后先搞清楚团队有没有代码评审、有没有相关的开发规范（命名规则、代码风格、分层结构、注释要求等）。如果有，写代码的时候就按规范来，别等 CR 的时候被指出一堆规范问题——逻辑问题可以理解，但规范问题全是本可以避免的，既浪费评审人的时间，也显得自己不够专业。

CR 一般关注：逻辑是否正确、是否有更好的实现方式、是否有遗漏的异常处理、SQL 是否有性能问题、是否有安全风险等。

新人对待 CR 意见的态度：虚心接受，不懂就问。CR 意见不是质疑你的能力，而是帮你快速成长的途径。有不同看法可以讨论，但不要把意见当成针对个人，本能地反驳或找借口。

CR 通过后，合并代码到主分支，部署到生产环境。

上线后要做的事：
- 观察监控和日志：关注错误率、接口响应时间、系统资源使用情况，确认服务运行正常
- 及时响应问题：如果出现严重问题，第一时间通知相关人（项目经理、测试、运维），并评估是否需要回滚
- 回滚优先于修复：线上出问题时，先恢复服务（回滚到上一版本），再排查根因，避免长时间影响用户
部分公司会采用灰度发布，先让小部分用户使用新版本，确认没问题后再全量放开。

三、常见术语#

下面列出的是通用术语。实际工作中，每个公司、每个项目还会有自己的内部术语或业务术语。遇到不认识的术语，可以先百度或问大模型，如果查不到，大概率就是内部术语，直接问同事即可。
但要注意：通用术语不能靠临时查，必须提前掌握。如果连这些基本术语都不知道，和同事沟通时很容易懵，甚至露馅。

3.1 测试相关#

术语	一句话说明
测试用例（用例）	测试人员编写的测试方案与步骤，包含预期结果
自测	开发完成后自己先测一遍，减少低级 bug（详见第二章第6步）
提测	开发把版本交给测试验证（详见第二章第8步）
单测（单元测试）	对方法或小功能的验证，通常由开发编写
冒烟测试	提测后测试人员做的第一轮快速验证，只覆盖主流程，确认核心功能可用后再进入正式测试
功能测试	按需求验证功能是否符合预期
回归测试	修复 bug 后再测一遍，确认问题解决且未引入新问题
集成测试	多个模块/服务组合起来一起测，验证”整体链路”是否通
兼容性测试	在不同系统、浏览器或设备上的适配验证
压力测试（压测）	验证系统在高并发或大流量下的性能与稳定性
灰度测试	小范围先发布给部分用户试用，逐步扩大使用面，边用边观察问题（与”灰度发布”含义接近，侧重验证阶段）
缺陷（Bug）	测试发现的问题记录与跟踪项
严重级别	问题影响范围与危害程度（致命/严重/一般/轻微）
优先级	修复处理的先后顺序（P0-P3 等）

3.2 环境与设备相关#

术语	一句话说明
服务器	可以运行服务应用的机器。只要你的电脑部署了服务，也可以理解成就是一个服务器
物理机	实体服务器，相对虚拟机而言的真实硬件
虚拟机	运行在物理机上的逻辑机器
容器	轻量级运行环境（如 Docker），便于部署
开发机	开发人员日常使用的工作机器，可安装开发软件、访问内网平台并进行联调
环境	开发中常说的环境一般是指系统运行所依赖的全部外部条件的总和，包括硬件（服务器）和软件（操作系统、MySQL、Redis等）
开发环境	开发人员本地编码和自测的环境
测试环境	供测试使用的环境，通常接近真实业务
预发环境	接近生产的验证环境，用于上线前最后验证
生产环境	真实用户使用的环境，变更需谨慎
VPN	远程安全连接公司内网的通道（在家办公常用）
堡垒机	进入内网环境的统一入口，负责登录认证、权限控制和审计
跳板机	登录后用于中转访问其他内网服务器的机器
内网	仅在公司或单位内部可访问的局域网（详见《基本的网络知识》）
外网	互联网，面向公众可访问的网络（详见《基本的网络知识》）

3.3 项目管理相关#

术语	一句话说明
PRD	产品需求文档（需求背景/范围/验收标准）
需求评审	团队对需求范围与可行性的统一确认（详见第二章第1步）
设计评审	对技术方案与架构设计的讨论与确认
原型图	产品功能的页面原型，用于指导前后端开发
任务拆分	将需求拆解为可交付的开发任务
排期	对任务的时间估算与交付计划（详见第二章第3步）
迭代	以固定周期推进的开发交付单位
版本	一次发布的功能集合与版本号
分支	多人协作时的代码隔离与并行开发方式
合并请求（MR/PR）	将分支代码合并到主分支的申请流程
代码评审（CR）	合并前对代码质量与规范的检查
风险	可能延期/出事故的点，要提前说并给预案
依赖	你要完成必须等别人先完成的东西
联调	前后端对接接口并修正联调问题的过程（详见第二章第7步）
上线/发布	将功能部署到生产环境对外提供（详见第二章第9步）
回滚	上线后出现问题时恢复到上一版本
灰度发布	按比例逐步开放新版本，控制风险

3.4 技术相关#

术语	一句话说明
接口	日常开发中说的”接口”通常指 API 接口（即一个可访问的 URL 地址，前端通过它与后端交互数据）。Java 语法中的 interface 是另一种概念，指的是类的行为抽象
接口文档	描述接口地址、参数、返回与错误码
北向接口	提供给外部厂商或运营商接入的接口
南向接口	向下对接下游系统或设备的接口
幂等	同一请求重复调用，结果保持一致
鉴权/授权	验证身份与权限是否允许访问
开关	功能可随时开/关，用于灰度/止血
全量同步	每次都同步全部数据
增量同步	首次全量，之后只同步新增或变更的数据
数仓（数据仓库）	用于存放与分析业务数据的系统
HTTP/HTTPS	常用 Web 传输协议，HTTPS 更安全（详见《基本的网络知识》）
JSON	常用接口数据格式
RPC	远程过程调用，服务间通信方式
ES	Elasticsearch，基于 Lucene 的分布式搜索引擎
SSO	单点登录
消息队列	用于在服务间异步传递消息的中间件，可以实现削峰填谷、系统解耦（如 Kafka）
缓存	将数据存储在高速存储层（如 Redis），以减少对数据库的访问，提升读取速度
负载均衡	将用户请求分发到多台服务器上，以提高系统的处理能力和可用性
ping	测试两端 IP 是否可达（详见《基本的网络知识》）
telnet	测试两端应用端口是否可连通（详见《基本的网络知识》）
日志	运行记录，用于排查问题与追踪行为
监控/告警	系统指标采集与异常通知
CI/CD	自动构建、测试与部署的流程
密评	对系统敏感数据加密与安全性的评测

3.5 敏捷与协作相关#

术语	一句话说明
敏捷开发	以短周期迭代、快速交付、持续反馈为核心的开发方式
站会	每天15分钟左右的短会，同步昨天做了什么、今天计划做什么、有什么阻塞
看板	可视化任务状态的工具或页面，常见状态：待开发→开发中→测试中→已完成
复盘/回顾	迭代或项目结束后，总结做得好的和需要改进的
Owner	某个功能或模块的主要负责人

四、新人常见误区#

以下是新人入职后容易踩的坑，提前了解可以少走弯路：

1）自测只走正常流程

只测”happy path”（正常流程），不测异常和边界，结果提测后被测试同学打回来一堆 bug，反而耽误时间。

正确做法：自测至少覆盖——正常流程、参数为空/非法、权限不足、数据不存在等常见异常场景。

2）不看现有代码就动手改

拿到需求直接写新代码，不先了解现有逻辑，结果改出新 bug 或者重复造轮子。

正确做法：先通读相关代码，理解现有逻辑和设计思路，再动手。不懂的地方问同事。

3）上线完就不管了

代码部署到生产环境后就去做别的事，不看监控、不看日志，出了问题都不知道。

正确做法：上线后至少观察15-30分钟，关注错误日志、监控告警、接口响应时间，确认服务稳定运行。

4）估时只算写代码的时间

排期时只算了编码时间，漏掉了自测、联调、修 bug、写文档的时间，导致实际交付时间远超预期。

正确做法：排期时按”编码占40%-50%“来估算，留出自测、联调、修 bug、 buffer 的时间。

浏览器控制台：怎么看？看什么？

Sat, 01 Aug 2026 00:00:00 GMT

浏览器控制台：怎么看？看什么？#

vx: nb887722 可进自学交流群微信公众号: 拙野学习平台：zystudy.cn csdn: 拙野

一、怎么看？#

先说怎么打开。 最快的方式是按 F12，Chrome、Edge、Firefox 都通用。如果 F12 不灵（比如被输入法占了快捷键），还有两个备选：在页面任意位置右键选「检查」；或者按 Ctrl + Shift + I（Mac 是 Cmd + Option + I）。记住 F12 就够了，其他是兜底。

打开以后，顶部一排标签页就是各种”面板”。

Elements（元素）：页面的 HTML 结构，前端调样式用的，后端基本不碰。
Console（控制台）：前端 JS 打印的日志和报错都堆这里，页面白屏、按钮没反应，先来这里找红色错误。
Network（网络）：所有接口请求都在这——请求地址、参数、状态码、返回内容，这是后端用得最多的面板。
Application（应用）：Cookie、LocalStorage、SessionStorage 存放的地方，后端偶尔看，排查登录态问题时可能用到。
Sources（源代码）：用来调试 JS 源码的，后端不用管。

F12控制台

二、看什么？#

1、每个面板看什么信息#

Network：一条请求点开后，重点看三样东西。

状态码（Status）：200 是正常；4xx 是请求有问题，常见 400（参数格式错）、401（没登录）、403（没权限）；5xx 是服务端的问题，500 是代码报错，502/503 是服务没起来或网关有问题。记住一个大概规律：4xx 多半是前端的事，5xx 多半是后端的事。
请求参数（Payload）：前端到底传了什么给你。这是排查必看的——很多时候接口返回空或报错，不是你代码错了，是前端传的参数本身就不对。
响应内容（Response）：接口返回了什么。是空数组 []，还是报错信息，还是一坨 HTML（说明请求被拦截跳到登录页了）。

点开请求后会有几个子标签：Headers 是请求头，Payload 是请求参数，Response 是原始返回内容，Preview 是格式化后的预览。后端排查主要看 Payload 和 Response 这两个。

Console：看红色报错。

Console 里前端 JS 打印的日志和报错都堆这里。红色的就是报错，一般会写哪个 JS 文件第几行出了什么错。后端不用看懂 JS，但你要知道：红色报错 = 前端代码出了问题，不是你的锅，截图发给前端就行。偶尔也有黄色的警告（Warning），那些一般不影响功能，可以忽略。

2、遇到 bug 看什么信息#

F12控制台-3

排查的顺序就一条原则：先确认接口发没发、对不对，再回头看前端报没报错。 因为后端的职责到接口为止，接口没问题，大概率就不是你的事。

第一步：先开 F12，再去操作页面触发请求。

如果先操作再开 F12，那之前的请求 Network 是抓不到的，你只能看到一个空列表干瞪眼。所以排查问题第一件事就是先按 F12，然后再去复现问题。

怎么触发请求，取决于问题出在哪个操作上：

列表页空白 → 直接 F5 刷新当前页面，列表查询接口就会重新发一次
点某个按钮没反应 → 重新点那个按钮
提交表单报错 → 重新填一遍提交

如果怀疑是缓存导致的问题（比如代码改了但页面还是老样子），普通刷新可能不灵，得按 Ctrl + F5 或 Ctrl + Shift + R 强制刷新，绕过浏览器缓存重新加载。

第二步：在 Network 里找到那个接口，对照状态码判断。

请求发出去后，Network 里就会列出所有请求。怎么从一堆请求里找到你要的那个？先点 Network 左上角的 🚫（清除）按钮，把之前的旧请求全清掉，然后再去操作页面触发接口。这样 Network 里只剩下刚刚触发的几个请求，找起来干净多了。如果清完还是很多，分两种情况：知道接口名关键词，就在筛选框里输入（比如 user）直接搜；不知道接口名，就逐个点开看 Payload，哪个的传参是你刚才操作时填的内容，那个就是你要找的接口。

F12控制台-2

找到接口后，根据状态码会有三种结果：

结果一：状态码 200，但返回的是空数据。 这时候不是接口报错，是查询逻辑或数据的问题。在控制台能做的只有一件事：看 Payload 里前端传的参数对不对——比如分页参数是不是传了 pageSize=0，查询条件是不是传了不存在的值。入参不对，先用 Postman 把参数传对了再调一次接口：结果对了，说明是前端传错参数，前端的锅；结果还是不对，那后端也有问题，回后端查日志里的 SQL、条件拼得对不对、库里确实有没有这条数据。入参没问题，控制台的任务就完成了，直接回后端查。

结果二：状态码是 4xx 或 5xx。 这才是接口真的有问题。但别急着查自己的代码，同样先看 Payload 里前端传的参数对不对——参数格式错、必填项没传、类型不对，都会导致 400。入参不对，按结果一的办法用 Postman 传对参数再验一次，判断锅归谁。入参没问题，再点开 Response 看错误信息，4xx 的往参数和权限上查，5xx 的往代码报错和服务状态上查，拿到具体信息再去查日志或代码。

结果三：Network 里压根没有这个请求。 页面空白，但接口根本没被调用——说明问题出在前端，请求就没发出来。这种情况切到 Console 看红色报错，截图发给前端处理就行。

还有个坑要注意：Network 默认会在页面跳转时清空。如果你点了某个按钮页面刷新了，之前的请求就没了，你可能以为”接口没发”，其实是被清掉了。勾选 Network 顶部的「Preserve log」（保留日志），请求就不会被清掉，方便你回头对比。

第三步：遇到 401/403，回到 Network 看请求头。

如果接口返回了 401 或 403，说明登录态出了问题——要么 Token 没带、要么 Token 过期了。这时候不用切别的面板，直接点开那个 401 的请求，看 Headers 里的 Request Headers，找 Authorization 或 Cookie 字段——这才是请求实际发出去时带的，最准。

判断逻辑：

请求头里没带 Token → 前端没把登录态塞进请求，是前端的锅，让前端处理登录态。
请求头里带了 Token、接口还是返回 401 → Token 过期或后端鉴权逻辑有问题，这才是你的锅，得查你的拦截器或权限校验代码。

拿到接口地址，如何找到对应代码

Sat, 01 Aug 2026 00:00:00 GMT

拿到接口地址，如何找到对应代码？#

vx: nb887722 可进自学交流群微信公众号: 拙野学习平台：zystudy.cn

一、单体项目#

单体项目里所有代码都在一个工程里，接口地址和代码之间没有中间层，搜起来最直接。

例如搜索如下接口：

1
/api/admin/feedback/leaderboard

方法一：IDE 全局搜索（最快）

在 IDEA 里按 Ctrl + Shift + R（Mac 是 Cmd + Shift + R），打开全局搜索。搜路径里有辨识度的那一段，比如接口地址是 /api/order/pageList，就搜 pageList"（带个引号，能直接匹配注解里的字符串字面量，过滤掉无关结果），不要搜完整的 /api/order/pageList——因为类上面的 @RequestMapping 和方法上面的 @PostMapping 是分开写的，搜完整路径反而搜不到。

搜到之后，看哪个是 @GetMapping、@PostMapping、@RequestMapping 这类注解修饰的方法，那就是你要找的接口。

接口定位代码-1

方法二：通过 ApiFox 插件搜索（推荐，但需要外网）

IDEA 可以安装 ApiFox 插件，装好之后直接把接口路径贴进去搜索，它能直接定位到对应的 Controller 方法，比全局搜索更快更准。如果公司网络环境允许访问外网、且能装插件，推荐优先用这种方式。

但很多公司是内网开发，IDEA 装不了插件、也访问不了外网，这种情况下就只能用方法一的全局搜索。

接口定位代码-2

方法三：顺着项目结构找

如果你对项目结构已经有点了解，可以不搜，直接按包结构找。大部分 Java 项目的 Controller 放在固定的包下（比如 com.xxx.controller 或 com.xxx.web），打开对应的包，根据接口路径里的关键词（比如 order）找到对应的 Controller 类（OrderController），再在里面找具体方法。这个方法适合你已经熟悉项目之后日常使用，比每次全局搜索效率更高。

二、微服务项目#

微服务项目里，接口路径和代码之间隔了一层——请求先到网关，网关根据规则转发到对应的服务，服务里才有 Controller 代码。所以找接口代码要分两步：先定位是哪个服务，再在服务里找方法。

第一步：根据路径定位是哪个服务。

请求到了网关之后，网关会根据配置把路径转发到对应的服务。所以你要看网关的路由配置，看哪个服务负责处理这个路径。常见的网关配置方式有三种：

配置一般在网关服务的 application.yml 里，长这样：

1
spring:
2
  cloud:
3
    gateway:
4
      routes:
5
        - id: order-service
6
          uri: lb://order-service
7
          predicates:
8
            - Path=/api/order/**
9
        - id: user-service
10
          uri: lb://user-service
11
          predicates:
12
            - Path=/api/user/**

接口地址是 /api/order/pageList，匹配到 Path=/api/order/**，对应的 uri 是 lb://order-service，所以这个接口在 order-service 这个服务里。

第二步：定位到服务之后，找接口方法就跟单体项目一样了。

找到服务之后，去那个服务的代码工程里，用单体项目的三种方法找接口：Ctrl + Shift + R 搜路径关键词、通过 ApiFox 插件搜索、或者顺着项目包结构直接找。

拿到需求该干什么

Sat, 01 Aug 2026 00:00:00 GMT

一、理解需求#

1、理解需求的注意事项#

拿到需求后，不要急着开始开发。如果一个需求分到你手里，你几乎没有任何疑问就直接开始做，结果做完之后发现和真实需求不一致，那返工几乎是必然的。

开发过程中要建立一个很重要的意识：

需求来了，没有问题，不代表你很厉害；很多时候，反而说明你还没有真正理解清楚。

对于需求中的疑问，一定要敢问，也必须要问。因为理解需求，是后续开发不偏离方向的前提，也是避免后续返工和背锅的前提。

对于产品描述不清楚、原型图表达不明确、边界不完整的地方，都要及时确认清楚，最好拿到明确答复。这样做的目的，一方面是为了保证自己理解正确，另一方面也是为了避免后续出现“当时大家理解不一致”的扯皮情况。

另外还要有一个意识：

需求文档和原型图并不一定完全正确。

这些内容通常是由产品经理整理和输出的，而产品经理本身的经验和能力也存在差异。有些需求文档或原型图本身就可能存在问题，例如：

描述不完整
逻辑不严谨
前后不一致
边界情况遗漏
字段定义不明确

所以，不要一看到自己没看懂，就立刻怀疑是自己能力不行。很多时候，不是你理解能力有问题，而是文档本身就存在问题。

正确的做法是：

先认真看需求文档和原型图
把不清楚的地方整理出来
主动去确认
把关键结论对齐清楚后再开始开发

2、理解需求时，重点要确认什么？#

2.1 需求目标#

首先要明确，这次需求到底要解决什么问题，以及做完之后要达到什么效果。

重点确认：

这次需求要解决什么问题
这次需求的目标是什么
做完之后，预期效果是什么
这个需求的优先级和紧急程度如何

2.2 需求类型#

拿到需求后，要先判断这次需求属于哪一类。因为不同类型的需求，后续分析方式和影响范围往往不一样。

常见情况包括：

全新需求：和之前业务基本没有关系，需要新增一套功能
关联型新需求：属于新需求，但和现有功能、现有模块存在关联
优化型需求：在原有功能基础上做调整或增强，例如新增字段、增加筛选条件、优化流程等
修复型需求：修复现有功能中的问题或异常

先判断需求类型，有助于你更快判断：

应该从哪里入手
可能会影响哪些地方
是新增为主，还是修改为主

2.3 影响范围#

在明确需求类型之后，要进一步分析这次需求会影响哪些内容。

重点可以从下面几个方面去看：

（1）数据影响#

是否需要新建表
是否需要修改已有表
如果要改表，需要改哪些表
是否需要新增字段、索引或状态值

（2）数据来源#

数据是手动录入
还是由其他系统同步过来
如果是同步数据，是否涉及接口对接或消息通知

（3）接口影响#

是否需要新增接口
还是修改现有接口
如果修改现有接口，需要改哪些参数或返回值
修改后会不会影响前端或其他系统调用

（4）业务流程影响#

是否会影响现有业务流程
是否会影响上下游功能
是否会影响导出、报表、详情页、定时任务、缓存等相关功能

分析影响范围的目的，是避免只盯着当前这一个改动点，结果后面联调或测试时才发现漏改了很多地方。

理解需求，不是只看懂需求文档写了什么，而是要先搞清楚：这个需求属于什么类型、会影响哪些地方、后面应该从哪里开始下手。

2.4 验收标准#

需要明确：

做到什么程度才算完成
页面上最终要展示什么
接口最终要返回什么
筛选条件要支持哪些值
异常情况下如何提示
是否需要兼容历史数据
是否需要支持导出、详情页、报表等联动场景

验收标准不清楚，后面做完了也不一定算完成

2.5 边界条件#

除了主流程，还要重点确认边界情况，例如：

空值怎么处理
历史数据没有这个字段怎么办
非法参数如何提示
没权限时怎么处理
数据异常时怎么展示
同一功能在不同角色下是否有差异
极端情况下是否会影响已有功能

主流程大家通常都会想到，真正容易出问题的，往往是边界情况

2.6 依赖关系#

理解需求时，还要判断这次需求是否依赖其他角色或系统配合，例如：

是否需要前端同步修改
是否需要测试提前准备场景和数据
是否需要 DBA 执行脚本
是否依赖其他系统提供数据或接口支持
是否需要产品进一步确认某些边界

有些需求不是你会写代码就能按时完成，关键在于你有没有提前发现依赖。

二、根据需求进行设计#

根据需求进行设计，主要有两个目的。

第一，进一步加深对需求的理解

很多时候，需求在刚看的时候，好像大概明白了。但真正开始设计的时候，才会发现很多细节还没有想清楚，比如：

这个流程到底怎么走
需要改哪些表
接口参数和返回值应该怎么设计
有没有遗漏的影响点
有没有边界情况需要补充考虑

也就是说，设计的过程，本身也是再次梳理和深化需求理解的过程。 通过设计，可以在正式开发之前，把需求尽可能想得更清楚一些，减少后续返工。

当然，也要有一个意识：

即使前面已经做了设计，真正开发过程中，仍然有可能出现新的疑问。

如果开发过程中发现需求还有不明确的地方，仍然需要及时沟通确认，而不是自己猜着做。

第二，很多公司本身就要求先设计再开发

在不少公司里，需求进入开发前，本身就要求先输出设计方案。设计完成后，可能还需要进行方案评审，确认没有问题之后，才能正式开始开发。

所以，无论是从个人开发效率，还是从公司流程要求来看，根据需求先做设计，都是非常有必要的。

建议

对于那种一眼就能看出来怎么做、影响范围也非常小的需求，例如：

新增一个普通字段
增加一个简单筛选条件

这类需求可以不一定单独写完整设计文档。

但是对于稍微复杂一点的需求，例如：

涉及多个接口或多个表
涉及业务流程调整
涉及上下游联动
涉及老逻辑兼容
涉及风险点较多

都建议先整理一版设计方案。如果公司有要求，就按公司的规范来写；如果不知道怎么写，可以先找同事要一份模板参考。如果公司没有强制要求，也建议至少自己写一个简版设计，帮助自己把思路梳理清楚。

1、业务流程梳理#

设计时，首先要梳理这次需求涉及的业务流程。

也就是要先想清楚：

整个流程是怎么走的
用户的操作入口在哪里
请求经过哪些系统或模块
哪一步会新增逻辑
哪一步会修改原有逻辑
最终结果会落到哪里

如果流程稍微复杂，建议直接画一个简单流程图。因为很多时候，流程一画出来，问题就更容易暴露出来。

例如，你可能会发现：

原来某一步漏考虑了
原来还有上下游系统参与
原来状态流转没有想完整
原来某个异常场景没有覆盖到

所以，业务流程梳理的目的，不只是为了“画图”，而是为了让自己真正把主流程和关键节点想清楚。

2、表设计#

如果需求涉及数据库设计，就需要先根据业务场景分析：这次需求会涉及哪些核心业务对象，这些对象之间是什么关系，最终应该如何落到数据库表中。

需要注意的是，业务对象并不一定都必须单独设计成一张表。是否需要单独建表，要结合实际业务场景、数据存储需求、查询方式以及后续扩展性综合判断。

2.1 先分析业务对象之间的关系#

在表设计之前，先要搞清楚业务对象之间是什么关系，常见关系包括：

一对一
一对多
多对多

例如：

一个用户可以有多个订单，这通常是一对多
一个订单可以包含多个商品，一个商品也可以出现在多个订单中，这通常是多对多

对于多对多关系，通常需要增加一张中间关系表来维护两边的关联关系。

2.2 表与表之间通过关联字段建立关系#

在设计表结构时，如果一张表需要关联另一张表，通常通过：

主键
业务唯一标识字段

来建立关系。

一般情况下，一张表中只需要保存另一张表的关联字段，而不需要重复存储另一张表的所有信息。需要使用对方信息时，可以通过关联字段进行查询。

这样设计的好处是：

避免数据冗余
减少数据不一致问题
后续维护更方便

当然，如果某些场景对查询性能要求较高，或者出于业务快照的考虑，也可能会适当做冗余字段设计，这要结合具体业务判断。

2.3 表设计时需要重点注意的内容#

（1）优先遵循公司已有的建表规范

在正式设计表之前，首先要了解公司内部是否有统一的建表规范。如果有，就必须优先按照公司规范来设计表名、字段名、注释、公共字段等内容。

例如，有些公司会要求每张表都必须包含公共字段：

cr_time
cr_id
up_time
up_id
rm_time
rm_id
removed

属于建表时最基础的规范，必须掌握：

每张表必须有主键
主键放在第一列
表名和字段名使用小写字母
多个英文单词之间使用下划线分隔

（2）字段不要无节制堆积

一张表的字段不宜过多。如果字段过多，通常说明：

表职责可能不够单一
数据结构可能拆分得不合理
后续维护成本会变高

如果确实字段很多，可以结合业务场景考虑是否拆成：

主表 + 扩展表
主表 + 明细表

但是否拆表，也不能只看字段数量，还要结合查询方式、更新频率和业务职责一起判断。

（3）字段类型要选择合适

字段类型设计要尽量合理，不要随意选择。

例如：

能用整型表示的，通常不要直接用字符串
能明确长度的字段，尽量设置合理长度
金额类字段要考虑精度
时间类字段要统一规范

不过也要注意：如果某个字段的数据类型在当前阶段不够稳定，或者后续扩展可能较大，可以在合理范围内选择兼容性更强的类型，但不要为了“省事”全部都用字符串。

（4）表注释和字段注释尽量补齐

建表时，最好同时补上：

表注释
字段注释

因为后续无论是你自己看表，还是别人接手项目，注释都能明显降低理解成本。尤其是状态字段、业务标识字段、枚举值字段，如果没有注释，后面维护起来会非常痛苦。

（5）索引要结合查询场景来设计

建表时，不建议一上来就给很多字段随意加索引，但也不能完全不考虑索引。

更合理的做法是：

先结合业务查询场景分析哪些字段会被高频查询
再考虑是否需要建立单列索引或联合索引
数据量较小、查询场景不明确时，可以先不急着加很多索引
数据量上来后，再结合实际 SQL 和执行情况优化索引

也就是说：

索引不是越多越好，而是要根据实际查询场景来设计。

2.4 表设计的核心目标#

表设计最终要达到的目标，不只是“能存数据”，还要尽量做到：

结构清晰
命名规范
关系合理
方便查询
方便扩展
方便维护

表设计不是简单地把需求字段堆到数据库里，而是要先理清业务对象、对象关系和数据存储方式，再结合公司规范、字段类型、注释和索引等因素，设计出合理、可维护的表结构。

3、接口设计#

如果需求涉及接口，就要考虑接口设计。

接口设计时，也要优先遵循项目现有的接口规范，而不是自己随意发挥。因为你后面真正写接口时，最重要的不是“写出来”，而是要和项目现有风格保持一致。

设计接口时，建议重点考虑这些内容：

接口地址如何命名
是否遵循 RESTful 风格
请求方式使用 GET、POST、PUT 还是 DELETE
请求参数如何封装
返回值是否使用统一响应类
错误码是否有统一规范
分页参数和分页返回结构是否统一
参数校验怎么处理
异常处理方式是否和现有项目一致

这时候，就可以结合你前面在“熟悉项目”时总结出来的内容来看：

别人之前的接口是怎么写的，这个项目平时的接口风格是什么。

然后尽量按照现有规范来设计和实现，而不是自己重新搞一套风格。

一句话总结

根据需求进行设计，不只是为了画一份文档，更重要的是在正式开发之前，把业务流程、表设计、接口设计和风险点尽可能想清楚。

三、评估工时#

在需求理解清楚、设计思路也基本明确之后，下一步通常就需要进行工时评估。

工时评估，说白了，就是判断：

这个需求大概要花多久
哪些部分最耗时间
是否依赖别人配合
是否存在会影响进度的风险点

很多新人在这一步最容易犯的错，就是只算写代码的时间。但真实工作里，一个需求真正完成，远远不只是“把代码写完”这么简单。

一个需求的工时，通常至少要包括下面这些部分：

理解需求
梳理方案
编码实现
自测
联调
修 bug
提测和沟通成本

也就是说，工时评估不能只看开发时间，还要看整个交付过程。

工时评估时，重点看什么？#

（1）需求本身复杂度#

先判断这个需求本身复杂不复杂，例如：

是简单字段新增
还是涉及多个接口和多个表
是只改一个模块
还是会影响多个模块和上下游系统

需求越复杂，工时自然越长。

（2）改动范围#

要看这次需求具体会改哪些地方，例如：

改几个接口
改几张表
改多少业务逻辑
是否影响导出、报表、详情页、缓存、定时任务等联动功能

改动范围越大，评估时间时越要保守一些。

（3）自己对项目的熟悉程度#

同样一个需求，不同人做，时间可能差很多。

比如：

对项目很熟的人，定位代码和改动点会很快
刚接手项目的人，可能花很多时间在找代码、看表、理解流程上

所以评估工时时，也要客观考虑自己当前对项目的熟悉程度，不要按照“理想状态”去估。

（4）是否依赖其他人配合#

有些需求，不是你一个人把代码写完就结束了，还可能依赖：

前端联调
测试准备数据
产品确认边界
其他系统同步改动
调用其他系统接口

如果有这些依赖，就要考虑进去，不然很容易出现：代码写完了，但整体推进不了。

（5）是否存在风险点#

如果需求里存在这些情况，评估时间时就要适当留余量：

历史数据处理不确定
老逻辑兼容复杂
影响范围还没完全确认
接口联动较多
可能有性能问题
可能牵扯缓存、MQ、第三方系统

有风险点的需求，不适合估得太满。

工时评估时，不要只给一个“拍脑袋时间”#

更推荐的做法是：拆开估。

例如，可以拆成这样：

需求确认：0.5h
方案梳理：1h
编码实现：3h
自测：1h
联调：1h
修 bug + 提测：1h

这样比直接说“我估计一天”要更专业，也更方便后面解释为什么需要这些时间。

如果项目经理马上问你多久能做完，怎么回答更稳妥？#

如果你刚拿到需求，还没把改动点和影响面想清楚，这时候不要急着直接报时间。

更稳妥的表达方式是：

我先把需求理解清楚，把改动点和方案梳理一下，再给你一个更准确的时间。

这句话的好处是：

不会因为估时太随意，后面自己被动
显得你是在认真评估，而不是拖延
给自己争取一点时间，把需求想清楚

工时评估的注意事项#

不要只算写代码时间
不要忽略自测、联调、修 bug 的时间
不要在需求没理解清楚前随口报时间
不要按“最理想情况”估时
有依赖和风险的需求，要适当留余量

工时评估，不是简单地猜一个时间，而是根据需求复杂度、改动范围、项目熟悉程度、依赖关系和风险点，对整个交付过程做一个相对合理的预估。

如何进行前后端联调

Sat, 01 Aug 2026 00:00:00 GMT

一、新人必看#

很多新人会问：“接口我不是写好了吗？为什么还要联调？”

因为你的接口写好了，不代表前端能正常调用。可能字段名对不上、数据格式不对、返回值有问题……

联调就是让前端调你的接口，发现问题后一起解决的过程。

1、什么是前后端联调？#

简单说就是：

后端写好接口
前端来调接口
发现问题，后端改
再调，再改，直到没问题

2、联调流程图#

前后端联调流程图

二、联调前的准备#

1、一定要先自测！（重要！）#

新人最容易犯的错：接口写完直接给前端调，结果一堆问题。

自测要测什么？

检查项	说明
接口能不能通	用Postman调一下，不报错再说
参数对不对	必填参数传了没，格式对不对
返回值对不对	数据格式、字段名是否符合预期
Token传了没	需要登录的接口要传Token
异常情况测了没	参数为空、参数错误会怎样

自测工具：

Postman
Apifox
Swagger

2、准备接口文档#

接口文档是给前端看的，要包含这些内容：

信息项	示例
接口用途	查询用户列表
接口地址	GET /api/user/list
请求参数	userName(可选)、pageNum(默认1)、pageSize(默认10)
返回参数	code、message、data(列表+总数)
枚举说明	status: 0-禁用, 1-启用

接口文档工具：

Word文档（简单粗暴）
Swagger/Knife4j（自动生成）
Apifox（在线协作）

三、部署后端服务#

前端要调你的接口，你得把服务部署起来。

1、方式一：本地部署#

就是把你本地的IDEA启动，让前端来连你电脑。

前提条件：

前后端在同一个局域网（同一个WiFi）
电脑防火墙要关闭
端口没有被占用

操作步骤：

查看自己的IP地址

Terminal window

1
# Windows
2
ipconfig
3

4
# 找到 IPv4 地址，比如 192.168.3.10 ,可以让前端Ping一下，能够Ping通就没问题

前后端联调-2

关闭防火墙

1
控制面板 → Windows Defender 防火墙 → 启用或关闭Windows Defender防火墙 → 关闭

告诉前端你的地址

1
192.168.3.10

2、方式二：测试环境部署#

直接把服务部署到测试服务器上，前端访问测试环境。

常见部署方式：

Jenkins自动部署
手动打包上传
Docker部署

问同事： “我们项目怎么部署到测试环境？“

3、验证服务是否正常#

Terminal window

1
# 本地测试
2
curl http://localhost:8080/api/test

四、联调过程中常见问题#

1、跨域问题#

现象： 前端控制台报错 CORS policy

原因： 前端和后端域名/端口不同，浏览器拦截了

解决方案：

后端添加跨域配置：

1
@Configuration
2
public class CorsConfig {
3
    @Bean
4
    public CorsFilter corsFilter() {
5
        CorsConfiguration config = new CorsConfiguration();
6
        config.addAllowedOriginPattern("*");
7
        config.addAllowedMethod("*");
8
        config.addAllowedHeader("*");
9
        config.setAllowCredentials(true);
10

11
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
12
        source.registerCorsConfiguration("/**", config);
13
        return new CorsFilter(source);
14
    }
15
}

展开收起

2、前端收不到参数#

现象： 前端传了参数，后端收到是null

排查步骤：

检查项	说明
请求方式	GET用@RequestParam，POST用@RequestBody
Content-Type	POST请求要设置 application/json
参数名称	前后端参数名要一致
参数位置	Query参数在URL里，Body参数在请求体里

常见错误：

1
// 错误：POST请求用了@RequestParam
2
@PostMapping("/add")
3
public Result add(@RequestParam String name) {  // 收不到！
4

5
// 正确：POST请求用@RequestBody
6
@PostMapping("/add")
7
public Result add(@RequestBody UserDto dto) {  // 正确

3、返回字段名不对#

现象： 前端要userName，你返回的是user_name

解决方案：

1
@Data
2
public class UserVo {
3
    @JsonProperty("userName")  // 指定返回的字段名
4
    private String userName;
5
}

4、日期格式问题#

现象： 日期返回的是时间戳或格式不对

解决方案：

1
@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")
2
private Date createTime;

5、Token失效#

现象： 接口返回401

排查：

Token有没有传
Token格式对不对（Bearer xxx）
Token有没有过期

五、联调的正确姿势#

1、与前端沟通的技巧#

不要这样说：

“接口没问题啊，你自己检查下”

应该这样说：

“我这边用Postman测是正常的，我们一起看看是什么问题，你把请求参数和返回结果发我一下”

2、问题定位方法#

1
1. 让前端把请求参数发给你
2
2. 你用同样的参数在Postman测试
3
3. 如果Postman正常，说明可能是跨域或前端问题
4
4. 如果Postman也有问题，那就是后端问题

3、改接口要注意#

改动	风险	建议
新增字段	低	随便加
修改字段名	高	先和前端确认
删除字段	很高	确认前端没用再删
修改返回结构	很高	可能影响很多地方

六、联调完成的标准#

检查项	说明
✅ 所有接口都能正常调用	没有报错
✅ 返回数据格式正确	字段名、类型都对
✅ 业务流程能跑通	从头到尾没卡点
✅ 异常情况处理正确	参数错误有提示
✅ 接口文档已更新	改动都记录了

七、新人避坑指南#

坑	正确做法
接口写完直接给前端	先自己用Postman测一遍
不写接口文档	至少写个简单的Word文档
改了接口不告诉前端	接口改动要及时同步
前端报错就说是前端问题	先排查确认是谁的问题
联调时间不够就匆忙交付	宁可加班也要保证质量

八、常见问题#

Q：前端说接口调不通怎么办？

A：让前端把报错截图发你，看是跨域问题还是接口问题。自己用Postman再测一遍确认。

Q：前端说字段名不对要改怎么办？

A：如果只是改字段名，加个@JsonProperty注解就行，不影响数据库字段。

Q：联调时前端不在怎么办？

A：先把接口文档给前端，让前端先看着，等都在了再联调。

Q：一个接口前端调了一直有问题怎么办？

A：和前端一起看，打开F12看请求和响应，一起分析问题在哪。

九、注意事项#

及时沟通：发现问题马上沟通，不要积累
保持耐心：联调遇到问题很正常，不要急躁
记录问题：把遇到的问题记下来，下次就不会踩坑
先自测再联调：自己都没测就给前端，很不专业
接口文档要同步：改了接口要更新文档

如何看线上日志

Sat, 01 Aug 2026 00:00:00 GMT

一、日志路径怎么找#

方法一：看配置文件

Java 项目的日志路径通常写在日志框架的配置文件里。打开你项目的 src/main/resources 目录，找这几个文件：

logback-spring.xml（最常见）
logback.xml
log4j2.xml

打开之后搜 file 或 path 关键字，一般能找到类似这样的配置：

1
<property name="LOG_PATH" value="/var/log/order-service"/>

这个路径就是日志输出的位置。这是最准的方式，因为它告诉你的是项目实际配置的路径，不是猜的。

方法二：看启动脚本

如果项目是用 nohup java -jar xxx.jar 启动的，那 nohup 会把控制台输出重定向到一个文件。看一下启动脚本（通常是 start.sh 或部署平台的命令），找类似这样的写法：

Terminal window

1
nohup java -jar order-service.jar > /var/log/order-service/startup.log 2>&1 &

> 后面跟的就是启动日志的路径。这个日志里会有应用启动时的输出，包括 Spring 的启动信息和一些早期报错。

方法三：问 AI

如果项目能访问外网，可以用 Claude Code、CodeX 这类 AI 工具直接读你的项目代码，它会帮你找到日志配置文件并告诉你路径在哪。

方法四：看文档或问同事

有些团队会有部署文档或运维文档，里面会写各个服务的日志路径，入职的时候留意一下有没有这种文档。有文档就先看文档，没有再问同事。

直接问同事：“咱们这个服务的日志在服务器哪个目录下？“。

二、找到了一堆文件，看哪个#

假设你已经知道日志在 /var/log/order-service/ 目录下，SSH 上去 ls 一看，可能长这样：

1
zcloud-learning.log
2
zcloud-learning.log.2026-07-03
3
zcloud-learning.log.2026-07-02
4
zcloud-learning-error.log
5
zcloud-learning.log.2026-07-03
6
startup.log

看哪个文件，取决于你要解决什么问题：

你想解决的问题	看哪个文件
刚刚调接口报错了	zcloud-learning.log（当天的主日志）
想只看报错信息	order-service-error.log（错误专用日志）
服务启动失败	startup.log 或主日志的最开头部分
昨天的问题，今天的日志已经滚动了	zcloud-learning.log.2026-07-02（按日期命名的历史日志）

大部分时候你需要看的是当天的主日志文件，文件名没有日期后缀的那个（比如 zcloud-learning.log）。如果配置了 error 日志单独输出，排查报错的时候先看 error 日志会更快，因为它只记录错误，不用在一堆 info 日志里翻。

找历史日志的要点

有一种场景更常见：测试同学反馈”昨天下午某个功能报错了”，你去复现发现是好的。这种问题没法重现，只能去翻对应那天的历史日志。操作步骤：

先确认问题发生的时间点。越精确越好，“昨天下午”和”昨天下午3点到4点之间”差别很大。
根据时间找到对应的日志文件。如果日志按天分割，直接看文件名日期就行，比如 zcloud-learning.log.2026-07-02。有些项目配置了按小时分割，文件名会带小时后缀，比如 zcloud-learning.log.2026-07-02-15 表示 14 号下午 3 点到 4 点的日志。
打开文件后，用时间关键字缩小范围，再用错误关键字定位。

Terminal window

1
# 在历史日志里搜某个时间段的报错
2
grep "2026-07-02 15:" zcloud-learning.log.2026-07-02 | grep "ERROR"

还有一个坑要注意：日志不会永远保留。服务器磁盘空间有限，运维一般会配置日志保留策略，比如只保留 7 天或 15 天。如果问题发生在一个月前，对应的日志文件大概率已经被清理了。所以遇到需要翻历史日志的问题，尽快去看，拖久了日志可能就没了。

三、找到日志了，怎么看#

情况一：问题可以复现，想实时看

用 tail -f，它会持续输出文件末尾新增的内容。先打开 tail -f，然后去调接口，日志会实时滚出来，按 Ctrl+C 停止。

Terminal window

1
tail -f zcloud-learning.log

如果日志刷得很快（比如有定时任务在跑），你触发的日志一下子就被刷过去了，这时候加过滤：

问题是报错 → 过滤 ERROR：
Terminal window
```
1
tail -f zcloud-learning.log | grep "ERROR"
```
问题是业务逻辑异常 → 过滤业务关键词，比如订单号：
Terminal window
```
1
tail -f zcloud-learning.log | grep "10086"
```

想看匹配行的上下文（比如报错那行的前后 5 行），加 -C 参数：

Terminal window

1
tail -f zcloud-learning.log | grep -C 5 "ERROR"

情况二：问题已经发生过了，事后搜索

这种场景用 grep 直接在日志文件里搜。搜什么取决于你知道什么：

知道报错类型 → 搜异常名：
Terminal window
```
1
grep "NullPointerException" zcloud-learning.log
```
知道业务参数 → 搜订单号、用户ID等：
Terminal window
```
1
grep "10086" zcloud-learning.log
```
知道大致时间段 → 用两个 grep 组合，先缩小范围再定位：
Terminal window
```
1
grep "2026-07-03 14:" zcloud-learning.log | grep "ERROR"
```

如果你的项目日志格式规范，每条日志都带订单号或 requestId，用业务关键词能把同一个请求的所有日志串起来。前提是日志里确实打了这个字段——这也是为什么写代码时要在关键节点打印业务标识。

除了 grep，事后搜索还有两种方式：

文件太大，想边翻边看上下文 → 用 less：
Terminal window
```
1
less zcloud-learning.log
```
less 会分页打开文件，用方向键翻页，按 / 输入关键字搜索，按 n 跳到下一个匹配项，按 q 退出。
想用编辑器的搜索功能 → 下载到本地：

用 VS Code 或 Notepad++ 打开，支持高亮、正则、多文件搜索，适合需要反复翻阅的场景。前提是公司允许把日志下载到本地——有些安全要求高的团队会限制这个操作，不确定的话先问一下。

如何快速熟悉项目

Sat, 01 Aug 2026 00:00:00 GMT

一、为什么要学会快速熟悉项目？#

1、什么叫熟悉项目？#

很多人理解的“熟悉项目”，就是把项目代码从头到尾看一遍。但实际上，熟悉项目并不是把所有代码都看完，而是先建立对项目的整体认知。

简单来说，熟悉项目，就是让你尽快搞清楚下面这些问题：

这个项目是干什么的
这个项目用了哪些技术栈
这个项目的整体技术架构是什么
这个项目怎么启动、怎么运行
这个项目有哪些核心模块
核心业务流程是什么
关键数据存在哪些表里
功能是通过哪些接口完成的
一条业务链路大概是怎么走的
出问题的时候，应该先去哪里找

也就是说，熟悉项目的本质，是先在脑子里建立一张“项目地图”。

这张“项目地图”里，不只是代码，还包括：

业务地图
模块地图
数据地图
接口地图
技术栈地图
技术架构地图
启动与运行地图

2、为什么要熟悉项目？#

因为你入职之后，不可能一直停留在“把项目跑起来”这个阶段。你很快就会碰到这些事情：

改需求
修 bug
联调接口
排查问题
写新接口
改老接口
查日志
跟前端、测试、产品沟通

如果你对项目没有整体认知，就很容易出现这些情况：

不知道从哪里开始改
不知道改完会影响哪里
不知道一个请求会走到哪些地方
不知道问题到底出在代码、配置、表、接口，还是中间件
不知道这个公司平时是怎么写接口、怎么组织代码的
看见 Redis、MQ、ES、注册中心、网关就发虚

所以，熟悉项目，不是为了学习而学习，而是为了后续真正开始干活。熟悉项目，最好有个文档输出，方便后续查询

二、熟悉项目的正确思路是什么？#

很多新人一开始最容易犯的错，就是：

一上来就看代码
一看就是一大堆类
越看越乱
最后什么都没记住

更推荐的思路应该是：

1
先了解业务
2
    ↓
3
再了解技术栈
4
    ↓
5
再看整体技术架构
6
    ↓
7
再看项目启动和运行方式
8
    ↓
9
再看模块划分
10
    ↓
11
再看核心表
12
    ↓
13
再看核心接口
14
    ↓
15
再顺着接口去看代码
16
    ↓
17
最后通过日志、调试、真实需求和 bug 来验证理解

展开收起

为什么推荐这个顺序？

1）先业务，再代码

因为代码是为业务服务的。如果你连这个系统是干什么的都没搞清楚，直接看代码，很容易迷路。

2）先技术栈和架构，再看实现细节

因为你后面看代码时，一定会不断碰到 Redis、MQ、ES、注册中心、网关、定时任务这些东西。如果你连这些技术是干什么的、项目里怎么用的都不知道，读代码会很慌。

3）先整体，再细节

先知道项目有哪些模块、哪些是核心模块，再决定先看哪里，不然很容易在边缘代码里浪费时间。

4）先看“做什么”，再看“怎么做”

接口、数据表、页面流程，往往比代码更容易帮助你理解业务。

5）先抓主线，再补细节

一开始不需要把所有地方都看懂，先抓住一两条核心链路，把主线搞明白，比零零散散看很多代码更有效。

三、快速熟悉项目，应该先看什么？#

很多新人熟悉项目时，容易只盯着业务和代码。但实际上，想要真正快速上手一个项目，至少要从下面几个方面一起看：

这个项目是做什么的
这个项目用了哪些技术栈
项目的整体技术架构是什么
项目怎么启动、怎么运行
项目有哪些模块
核心表和核心接口有哪些
核心业务链路是怎么走的

也就是说，熟悉项目，不只是熟悉业务和代码，还要熟悉这个项目的技术实现方式。

1、先看项目是做什么的#

先回答下面几个问题：

这个系统是干什么的？
谁在使用这个系统？
核心业务流程是什么？
这个系统和其他系统是什么关系？
这个系统在整个业务链路里扮演什么角色？

常见了解方式

看 README
看 PRD / 需求文档
看原型图
让同事或导师先简单讲一遍业务流程

注意

不要觉得这些“不是代码，没啥用”。很多时候，业务背景没搞清楚，后面你看接口、看表、看代码都会觉得每个字都认识，但不知道在干嘛。

2、再看项目用了哪些技术栈#

这一点非常重要，但很多新人容易忽略。

因为你后面能不能快速上手，很大程度上取决于你知不知道：

这个项目用了哪些技术
这些技术分别是做什么的
哪些技术你熟悉，哪些技术你不熟悉
这些技术在项目里分别是怎么用的

你要重点关注什么？

例如，一个项目里常见的技术栈可能有：

Spring Boot
Spring Cloud / Dubbo
MyBatis / JPA
MySQL
Redis
Kafka / RabbitMQ / RocketMQ
Elasticsearch
Nacos / Apollo
XXL-Job / Quartz
Docker
Nginx
工作流引擎
对象存储
第三方支付 / 短信 / 邮件服务

你要先搞清楚：

这些技术分别是做什么的
项目里哪些地方在用
自己对哪些熟，哪些不熟

如果有不熟悉的技术栈怎么办？

不用一开始就把所有技术都学得很深，但至少要做到下面三点：

第一：知道它是干什么的

比如：

Redis 是缓存
MQ 是异步解耦
ES 是搜索
Nacos 是注册中心/配置中心
XXL-Job 是定时任务调度

第二：知道项目里是怎么用它的

例如：

Redis 缓存了什么数据
MQ 在什么业务场景下发消息
ES 搜索的是哪些内容
配置中心管理了哪些配置
定时任务在什么时候跑

第三：先参考现有代码，不要自己硬猜

如果你不熟某个技术栈，最实用的方法通常不是先啃一堆理论，而是：

先看项目里别人是怎么使用这个技术栈的。

这样你后面真正需要改或者写的时候，就不会太心虚。

你要建立一个意识

熟悉项目里的技术栈，不是为了炫技，而是为了后续需要改到这些地方时，能快速看懂、快速参考、快速上手。

3、再看项目的整体技术架构#

除了知道用了哪些技术栈，还要知道这些技术栈是怎么组合起来的。

也就是要搞清楚：

这是单体项目还是微服务项目
请求是怎么进来的
服务之间怎么调用
数据库、缓存、MQ、搜索、中间件分别放在什么位置
网关、注册中心、配置中心有没有用
系统的主要链路是什么

你可以从这些角度去看

项目目录结构
服务拆分情况
系统架构图
部署文档
Nacos / 注册中心里的服务列表
网关配置
README / Wiki 里的架构说明

你至少要搞清楚这些问题

用户请求先到哪里？
是直接进应用，还是先过网关 / Nginx？
服务之间是 HTTP 调用还是 RPC 调用？
数据是落 MySQL、Redis 还是 ES？
异步流程是不是通过 MQ 处理？
定时任务有没有参与业务流程？

为什么这一步重要？

因为很多时候你不是不会写代码，而是你根本不知道：

这个功能在系统整体链路里是怎么流转的。

技术架构一旦看不清，你后面就很容易出现：

只看到自己眼前这一个服务
不知道为什么改了这里，别的系统也受影响
不知道问题到底出在网关、服务、缓存、消息还是数据库

4、再看项目怎么启动、怎么运行#

这一点也非常关键。因为“项目怎么启动”，其实直接决定了你能不能开始真正熟悉项目。

你至少要搞清楚这些：

启动类在哪
项目是单服务启动，还是多个服务配合启动
本地启动需要哪些依赖
依赖哪些中间件（MySQL、Redis、MQ、ES、Nacos 等）
配置文件在哪
不同环境配置怎么区分
启动失败时日志在哪看
启动之后怎么验证服务是正常的

你要重点看什么？

1）启动方式

比如：

直接运行 Spring Boot 启动类
先启动注册中心/配置中心，再启动服务
需要先启动数据库、Redis、MQ
需要 Docker / docker-compose 辅助启动部分依赖

2）运行依赖

比如项目启动前，是否依赖：

MySQL
Redis
Nacos
Kafka / RabbitMQ
Elasticsearch
第三方接口配置

3）环境配置

比如：

application.yml
application-dev.yml
bootstrap.yml
Nacos / Apollo 配置

你要知道：

本地启动读哪个环境
测试环境和本地环境有什么区别
哪些配置改错了会导致项目根本跑不起来

为什么这一步重要？

因为很多新人虽然能“勉强把项目跑起来”，但其实并不知道：

为什么要先启动这些依赖
为什么这个配置放在这里
为什么这个服务必须连到那个中间件
为什么本地跑得起来，测试环境不一定跑得起来

所以，熟悉启动方式，本质上也是在熟悉项目的运行机制。

5、再看项目有哪些模块#

你要先搞清楚这个项目是怎么拆分的。

比如一个项目里可能有：

用户模块
订单模块
商品模块
支付模块
权限模块
公共模块

你至少要先知道：

项目有哪些模块
每个模块是干什么的
哪些是核心模块
哪些是边缘模块
模块之间大概怎么调用

常见查看方式

看项目目录结构
看 Maven / Gradle 多模块配置
看服务注册中心（如果是微服务）
问同事“平时最常改的是哪些模块”

建议

一开始先重点熟悉 最核心的 1~2 个模块，不要想着一下把所有模块都吃透。

6、再看核心表#

对于后端来说，数据表是非常重要的切入口。因为：

数据是业务在系统中的投影。

有时候你先看表，比先看代码更容易理解业务。

看表时重点看什么？

表名
主键
业务字段
状态字段
关联字段
时间字段
索引字段

推荐做法

先找 3~5 张核心表
理清这些表之间的关系
查几条真实数据看看
再去对照代码中的 Entity、Mapper、Service

举例

假设你在看订单系统：

user
order
order_item
product
payment_record

你只要把这几张表的大概关系看明白，对业务整体就会有一个比较直观的理解。

7、再看核心接口#

很多新人熟悉项目的时候，会忽略接口这一层，直接看代码。其实，接口是后端开发最重要的业务入口之一。

因为大多数业务流程，本质上都是：

1
前端/其他系统发请求
2
        ↓
3
接口接收参数
4
        ↓
5
后端处理业务逻辑
6
        ↓
7
查询/修改数据库
8
        ↓
9
返回结果

所以，熟悉接口有两个目的：

第一个目的：了解系统有哪些功能入口

通过接口，你可以更快看懂：

系统提供了哪些功能
一个功能通常是通过哪个接口完成的
接口和表、代码、业务逻辑是怎么对应起来的

第二个目的：了解这个项目平时怎么写接口

这个非常重要。因为你后面自己写接口时，不是随便按自己习惯写，而是要按照项目现有规范来写。

你要通过熟悉接口，总结出这个项目的接口风格，比如：

URL 怎么命名
GET / POST / PUT / DELETE 怎么用
请求参数怎么封装
返回结构怎么统一
错误码怎么定义
分页怎么写
模糊查询怎么做
参数校验怎么做
鉴权怎么做
接口文档/注释怎么写
异常处理怎么做

也就是说：

熟悉接口，不只是为了知道系统有哪些功能，更是为了总结这个项目写接口的规范和风格，方便后续自己按照统一方式开发接口。

看接口时重点看什么？

接口路径
请求方式
请求参数
响应结构
错误码
分页参数
是否需要登录态/鉴权
这个接口会影响哪些表
这个接口最终会走到哪个 Controller / Service

建议

先看 3~5 个核心接口，例如：

登录接口
列表查询接口
详情接口
创建接口
修改接口
提交 / 审核 / 支付这类关键动作接口

最推荐的方式

先看 Swagger / Knife4j / Postman
再实际调一次接口
最后顺着接口去看代码

四、如何从接口顺着去看代码？#

代码当然要看，但不要通读，要带着入口去看。

最推荐的方式是：

从一个真实入口开始追。

这个入口可以是：

一个接口
一个需求
一个 bug
一条日志
一个表字段

1、最常见的看法：从接口开始追#

以一个创建订单接口为例：

1
OrderController.createOrder()
2
        ↓
3
OrderService.createOrder()
4
        ↓
5
参数校验 / 业务校验 / 库存校验
6
        ↓
7
OrderMapper.insert()
8
        ↓
9
写订单表、订单明细表
10
        ↓
11
返回结果

你要顺着这条线去看：

Controller 做了什么
Service 做了什么
Mapper / DAO 做了什么
哪些表被查了、被改了
日志打印在哪
异常是怎么处理的

2、看代码时先看主干，再看细节#

推荐顺序：

先看 Controller
再看 Service
再看 Mapper / DAO
最后再看工具类、异常处理、事务、边界逻辑

注意

一开始不要太纠结这些内容：

很底层的工具类
很复杂的公共封装
各种配置细节
边缘功能代码

先把主流程搞懂更重要。

3、看代码时重点关注什么？#

优先看这些：

主流程
参数校验
业务校验
状态流转
异常处理
日志打印
事务边界

4、善用 IDE#

熟悉项目时，IDE 是你的导航工具。

重点会用这些能力：

跳转到定义
查找引用
查看调用层次
全局搜索接口路径、类名、字段名
打断点调试

五、熟悉项目时的常见误区#

1、一上来就通读全部代码#

这是最容易把自己看崩的方式。正确做法是：先抓主线，再按需深入。

2、总想一次性全懂#

这基本是不现实的。项目的理解一定是循序渐进的，不可能刚接触就把所有内容全部吃透。实际上，很多在公司待了两三年的同事，也未必对整个项目的每一个模块、每一个细节都完全了解。

3、只看代码，不看业务#

会导致你“看得懂代码，不知道为什么这么写”。

4、只看业务，不看技术栈#

这样后面一遇到 Redis、MQ、ES、注册中心、网关，就很容易发虚。

5、只看文档，不动手#

不调接口、不打断点、不看日志，很难真正建立理解。

6、不敢问#

新人最大的问题往往不是不会，而是不好意思问。实际上，很多项目里的命名、流程、历史包袱，不问根本猜不出来。

如何写一个接口

Sat, 01 Aug 2026 00:00:00 GMT

一、什么是接口？#

1、先理解MVC分层架构#

很多新人刚进公司，听到”写个接口”这个词会一脸懵。别慌，我们先搞清楚项目是怎么分层的。

1
用户（浏览器/APP）
2
      ↓
3
  Controller层（接口层）  ← 你写的接口就在这里！
4
      ↓
5
  Service层（业务逻辑层）
6
      ↓
7
  Mapper/DAO层（数据访问层）
8
      ↓
9
  数据库

每一层的职责：

层	职责	你要做什么
Controller层	接收请求、返回响应	定义接口地址、接收参数、调用Service、返回结果
Service层	处理业务逻辑	写业务代码、事务控制
Mapper/DAO层	操作数据库	写SQL、增删改查

2、“接口”到底是什么？#

此接口非彼接口（Java里的interface）。在工作中，我们说的”接口”通常指的是：

Controller层里的一个方法，能够接收前端的请求，处理后将结果返回。

一个接口就是一个URL地址 + 对应的处理方法。

比如：

GET /api/user/list - 查询用户列表
POST /api/user/add - 新增用户
PUT /api/user/update - 修改用户
DELETE /api/user/delete - 删除用户

3、新人常见的误区#

误区	正确理解
”接口就是Java的interface”	工作中说的接口通常指Controller里的方法
”接口一定要很复杂”	大部分接口就是简单的增删改查
”我要从零开始写”	先看项目里已有的接口，照葫芦画瓢

二、写接口的正确姿势#

1、写接口前先想清楚这几件事#

问题	说明
接口地址是什么？	如 /api/user/list
请求方式是什么？	GET查询、POST新增、PUT修改、DELETE删除
接收哪些参数？	查询条件、分页参数等
返回什么数据？	列表数据、详情数据、操作结果
要不要登录？	是否需要Token验证

2、写接口的基本步骤#

1
第一步：看项目中已有的接口是怎么写的（最重要！）
2
第二步：在Controller里写方法，定义接口地址和参数
3
第三步：在Service里写业务逻辑
4
第四步：在Mapper里写SQL
5
第五步：用Postman测试

新人必看：不要一上来就自己写，先找项目中类似的接口，复制粘贴然后改！

重要习惯：边写边测试！ 不要一口气把5个接口全写完再一起测。写完查询接口就测查询，写完新增就测新增。写一个、测一个、通一个，有问题立即发现立即修。不把问题带到后续接口的开发中！

三、常见接口类型示例#

提醒：下面的示例只是一般写法，不同项目的规范可能不同。实际开发时一定要参考项目中已有接口的写法来写，以项目现有规范为准！

1、分页查询接口（最常用）#

Controller层：

1
@RestController
2
@RequestMapping("/api/user")
3
public class UserController {
4

5
    @Autowired
6
    private UserService userService;
7

8
    /**
9
     * 查询用户列表（分页）
10
     * 请求方式：GET
11
     * 接口地址：/api/user/list
12
     */
13
    @GetMapping("/list")
14
    public Result list(
15
            @RequestParam(value = "userName", required = false) String userName,  // 用户名（可选）
16
            @RequestParam(value = "phone", required = false) String phone,        // 手机号（可选）
17
            @RequestParam(value = "pageNum", defaultValue = "1") Integer pageNum,  // 页码，默认第1页
18
            @RequestParam(value = "pageSize", defaultValue = "10") Integer pageSize // 每页条数，默认10条
19
    ) {
20
        // Controller只负责接收参数、调用Service、返回结果，不写业务逻辑
21
        PageInfo<UserVo> pageInfo = userService.list(userName, phone, pageNum, pageSize);
22
        return Result.success(pageInfo);
23
    }
24
}

展开收起

Service层：

1
@Service
2
public class UserServiceImpl implements UserService {
3

4
    @Autowired
5
    private UserMapper userMapper;
6

7
    @Override
8
    public PageInfo<UserVo> list(String userName, String phone, Integer pageNum, Integer pageSize) {
9
        // 开启分页
10
        PageHelper.startPage(pageNum, pageSize);
11
        // 查询数据
12
        List<UserVo> list = userMapper.selectList(userName, phone);
13
        // 封装分页结果
14
        return new PageInfo<>(list);
15
    }
16
}

展开收起

Mapper接口：

1
@Mapper
2
public interface UserMapper {
3

4
    // 分页查询用户列表
5
    List<UserVo> selectList(
6
        @Param("userName") String userName,
7
        @Param("phone") String phone
8
    );
9
}

Mapper XML（SQL）：

UserMapper.xml

1
<select id="selectList" resultType="com.example.vo.UserVo">
2
    SELECT
3
        id, user_name, phone, email, create_time
4
    FROM sys_user
5
    WHERE deleted = 0
6
    <if test="userName != null and userName != ''">
7
        AND user_name LIKE CONCAT('%', #{userName}, '%')
8
    </if>
9
    <if test="phone != null and phone != ''">
10
        AND phone = #{phone}
11
    </if>
12
    ORDER BY create_time DESC
13
</select>

新人注意：<if> 标签用于动态SQL，参数为空时不会拼接该条件，这样查询就是”查全部”。

参数说明：

参数	说明
@RequestParam	接收URL后面的参数，如 /list?userName=张三
required = false	表示这个参数可以不传
defaultValue = “1”	不传参数时的默认值
@Param	Mapper接口中用@Param给参数起别名，XML里才能用#{userName}引用
resultType	指定返回结果的类型，指向你的Vo类的全限定名

参数太多怎么办？用实体类接收：

1
@PostMapping("/list")
2
public Result list(@RequestBody UserQueryVo query) {
3
    PageHelper.startPage(query.getPageNum(), query.getPageSize());
4
    List<UserVo> list = userService.list(query);
5
    PageInfo<UserVo> pageInfo = new PageInfo<>(list);
6
    return Result.success(pageInfo);
7
}

接收参数的实体类：

1
@Data
2
public class UserQueryVo {
3
    private String userName;     // 用户名
4
    private String phone;        // 手机号
5
    private Integer pageNum = 1;  // 页码，默认1
6
    private Integer pageSize = 10; // 每页条数，默认10
7
}

2、新增接口#

2.1 单表新增（简单场景）#

Controller层：

1
/**
2
 * 新增用户
3
 * 请求方式：POST
4
 * 接口地址：/api/user/add
5
 */
6
@PostMapping("/add")
7
public Result add(@RequestBody UserDto userDto) {
8
    userService.add(userDto);
9
    return Result.success("新增成功");
10
}

Service层：

1
@Service
2
public class UserServiceImpl implements UserService {
3

4
    @Autowired
5
    private UserMapper userMapper;
6

7
    @Override
8
    @Transactional  // 加事务，保证数据一致性
9
    public void add(UserDto userDto) {
10
        // 1. 参数校验
11
        if (StringUtils.isEmpty(userDto.getUserName())) {
12
            throw new BusinessException("用户名不能为空");
13
        }
14

15
        // 2. 检查用户名是否已存在
16
        User existUser = userMapper.selectByUserName(userDto.getUserName());
17
        if (existUser != null) {
18
            throw new BusinessException("用户名已存在");
19
        }
20

21
        // 3. 设置创建时间等默认值
22
        userDto.setCreateTime(new Date());
23
        userDto.setDeleted(0);
24

25
        // 4. 保存到数据库
26
        userMapper.insert(userDto);
27
    }
28
}

展开收起

Mapper接口：

1
@Mapper
2
public interface UserMapper {
3

4
    // 根据用户名查询（用于检查用户名是否已存在）
5
    User selectByUserName(@Param("userName") String userName);
6

7
    // 新增用户
8
    int insert(UserDto userDto);
9
}

Mapper XML（SQL）：

1
<select id="selectByUserName" resultType="com.example.entity.User">
2
    SELECT id, user_name, phone, email
3
    FROM sys_user
4
    WHERE user_name = #{userName}
5
    AND deleted = 0
6
</select>
7

8
<insert id="insert" parameterType="com.example.dto.UserDto" useGeneratedKeys="true" keyProperty="id">
9
    INSERT INTO sys_user (user_name, phone, email, create_time, deleted)
10
    VALUES (#{userName}, #{phone}, #{email}, #{createTime}, #{deleted})
11
</insert>

新人注意：useGeneratedKeys="true" keyProperty="id" 表示插入后MyBatis会自动把数据库生成的主键id回写到userDto的id属性中，后续可以直接用userDto.getId()获取。需要注意的是，如果表没有设置主键自增，则需要手动设置主键值，此时不需要配置useGeneratedKeys。

2.2 主子表新增（进阶场景）#

实际项目中经常会遇到主子表的情况，比如：订单（主表）+ 订单明细（子表）。新增时需要先插主表拿到主键id，再把主键id设置到子表的关联字段上，然后插入子表。

场景：新增订单，同时新增订单下的多个商品明细

1
订单表（主表）order_info          订单明细表（子表）order_item
2
┌────┬──────────┐                ┌────┬──────────┬──────────────┐
3
│ id │ order_no │                │ id │ order_id │ product_name │
4
├────┼──────────┤                ├────┼──────────┼──────────────┤
5
│ 1  │ OD001    │  ←────关联────  │ 1  │ 1        │ 手机         │
6
│    │          │                │ 2  │ 1        │ 耳机         │
7
└────┴──────────┘                └────┴──────────┴──────────────┘
8
                                    order_id关联主表的id

接收参数的DTO：

1
@Data
2
public class OrderDto {
3
    private String orderNo;                 // 订单号
4
    private BigDecimal totalPrice;          // 总金额
5
    private List<OrderItemDto> itemList;    // 订单明细列表（子表数据）
6
}
7

8
@Data
9
public class OrderItemDto {
10
    private String productName;  // 商品名称
11
    private Integer quantity;    // 数量
12
    private BigDecimal price;    // 单价
13
}

前端传入的JSON示例：

1
{
2
    "orderNo": "OD001",
3
    "totalPrice": 5999.00,
4
    "itemList": [
5
        {"productName": "手机", "quantity": 1, "price": 4999.00},
6
        {"productName": "耳机", "quantity": 2, "price": 500.00}
7
    ]
8
}

Service层（核心逻辑）：

1
@Service
2
public class OrderServiceImpl implements OrderService {
3

4
    @Autowired
5
    private OrderMapper orderMapper;
6

7
    @Autowired
8
    private OrderItemMapper orderItemMapper;
9

10
    @Override
11
    @Transactional
12
    public void add(OrderDto orderDto) {
13
        // 1. 参数校验
14
        if (StringUtils.isEmpty(orderDto.getOrderNo())) {
15
            throw new BusinessException("订单号不能为空");
16
        }
17
        if (CollectionUtils.isEmpty(orderDto.getItemList())) {
18
            throw new BusinessException("订单明细不能为空");
19
        }
20

21
        // 2. 设置默认值
22
        orderDto.setCreateTime(new Date());
23

24
        // 3. 先插入主表（订单）
25
        orderMapper.insert(orderDto);
26
        // 插入后 orderDto.getId() 就有值了（因为配置了 useGeneratedKeys）
27

28
        // 4. 遍历子表数据，设置主表id后插入子表
29
        for (OrderItemDto item : orderDto.getItemList()) {
30
            item.setOrderId(orderDto.getId());  // 关键：把主表id设到子表
31
            item.setCreateTime(new Date());
32
            orderItemMapper.insert(item);
33
        }
34
    }
35
}

展开收起

Mapper接口：

1
@Mapper
2
public interface OrderMapper {
3
    int insert(OrderDto orderDto);
4
}
5

6
@Mapper
7
public interface OrderItemMapper {
8
    int insert(OrderItemDto itemDto);
9
}

Mapper XML（SQL）：

OrderMapper.xml

1
<insert id="insert" parameterType="com.example.dto.OrderDto"
2
        useGeneratedKeys="true" keyProperty="id">
3
    INSERT INTO order_info (order_no, total_price, create_time)
4
    VALUES (#{orderNo}, #{totalPrice}, #{createTime})
5
</insert>
6

7
<!-- OrderItemMapper.xml -->
8
<insert id="insert" parameterType="com.example.dto.OrderItemDto"
9
        useGeneratedKeys="true" keyProperty="id">
10
    INSERT INTO order_item (order_id, product_name, quantity, price, create_time)
11
    VALUES (#{orderId}, #{productName}, #{quantity}, #{price}, #{createTime})
12
</insert>

新人注意：主子表新增的关键点：

主表的insert必须配置 useGeneratedKeys="true" keyProperty="id"，插入后主键id会自动回写

循环子表数据时，用 主表对象.getId() 设置子表的关联字段

必须加 @Transactional，主表和子表要么全成功要么全回滚，不然会出现主表有数据但子表没数据的情况

3、修改接口#

Controller层：

1
/**
2
 * 修改用户
3
 * 请求方式：PUT
4
 * 接口地址：/api/user/update
5
 */
6
@PutMapping("/update")
7
public Result update(@RequestBody UserDto userDto) {
8
    userService.update(userDto);
9
    return Result.success("修改成功");
10
}

Service层：

1
@Override
2
public void update(UserDto userDto) {
3
    // 1. 检查用户是否存在
4
    User user = userMapper.selectById(userDto.getId());
5
    if (user == null) {
6
        throw new BusinessException("用户不存在");
7
    }
8

9
    // 2. 更新数据
10
    userDto.setUpdateTime(new Date());
11
    userMapper.updateById(userDto);
12
}

Mapper接口：

1
// 在UserMapper中添加
2
User selectById(@Param("id") Integer id);
3
int updateById(UserDto userDto);

Mapper XML（SQL）：

1
<select id="selectById" resultType="com.example.entity.User">
2
    SELECT id, user_name, phone, email
3
    FROM sys_user
4
    WHERE id = #{id}
5
    AND deleted = 0
6
</select>
7

8
<update id="updateById" parameterType="com.example.dto.UserDto">
9
    UPDATE sys_user
10
    <set>
11
        <if test="userName != null and userName != ''">
12
            user_name = #{userName},
13
        </if>
14
        <if test="phone != null and phone != ''">
15
            phone = #{phone},
16
        </if>
17
        <if test="email != null and email != ''">
18
            email = #{email},
19
        </if>
20
        update_time = #{updateTime},
21
    </set>
22
    WHERE id = #{id}
23
    AND deleted = 0
24
</update>

展开收起

新人注意：<set> 标签会自动去掉最后一个多余的逗号，比手动拼SET语句更安全，且只更新非空的字段。

4、删除接口#

单个删除：

1
/**
2
 * 删除用户
3
 * 请求方式：DELETE
4
 * 接口地址：/api/user/delete/{id}
5
 */
6
@DeleteMapping("/delete/{id}")
7
public Result delete(@PathVariable("id") Integer id) {
8
    userService.deleteById(id);
9
    return Result.success("删除成功");
10
}

批量删除（更常用）：

1
/**
2
 * 批量删除用户
3
 * 请求方式：DELETE
4
 * 接口地址：/api/user/delete?ids=1,2,3
5
 */
6
@DeleteMapping("/delete")
7
public Result delete(@RequestParam("ids") String ids) {
8
    // ids = "1,2,3" 需要转成列表
9
    List<Integer> idList = Arrays.stream(ids.split(","))
10
            .map(String::trim)
11
            .map(Integer::parseInt)
12
            .collect(Collectors.toList());
13
    userService.deleteByIds(idList);
14
    return Result.success("删除成功");
15
}

展开收起

Service层（删除相关方法）：

1
@Override
2
public void deleteById(Integer id) {
3
    // 建议用逻辑删除，而不是物理删除
4
    userMapper.logicDeleteById(id);
5
}
6

7
@Override
8
public void deleteByIds(List<Integer> idList) {
9
    userMapper.logicDeleteByIds(idList);
10
}

Mapper接口：

1
// 在UserMapper中添加
2
int logicDeleteById(@Param("id") Integer id);
3
int logicDeleteByIds(@Param("idList") List<Integer> idList);

Mapper XML（SQL）：

1
<update id="logicDeleteById">
2
    UPDATE sys_user
3
    SET deleted = 1
4
    WHERE id = #{id}
5
</update>
6

7
<update id="logicDeleteByIds">
8
    UPDATE sys_user
9
    SET deleted = 1
10
    WHERE id IN
11
    <foreach collection="idList" item="id" open="(" separator="," close=")">
12
        #{id}
13
    </foreach>
14
</update>

注意：
1）正式项目中推荐使用逻辑删除**（把deleted字段设为1），而不是DELETE FROM物理删除。逻辑删除的数据可以恢复，也不会影响关联数据。<foreach> 标签用于遍历集合，自动拼接IN (1, 2, 3)。

2）DELETE请求在某些服务器或Nginx配置下可能会被禁用（出于安全考虑）。如果遇到DELETE请求返回405或被拦截，可以改成用POST请求来代替删除操作，具体以项目现有规范为准。

5、详情查询接口（一对多关联查询）#

实际项目中，详情查询经常需要关联查询子表数据。比如：查订单详情，需要同时返回订单基本信息和订单下的商品明细列表。下面用MyBatis的<resultMap> + <collection>实现一对多映射，一条SQL搞定。

场景：根据订单id查询订单详情，包含订单基本信息 + 商品明细列表

1
数据库字段（下划线命名）            Java实体类字段（驼峰命名）
2
─────────────────────            ─────────────────────
3
order_info表：                    OrderDetailVo：
4
  order_no        ──映射──→         orderNo
5
  total_price     ──映射──→         totalPrice
6
  create_time     ──映射──→         createTime
7

8
order_item表：                    OrderItemVo：
9
  order_id        ──映射──→         orderId
10
  product_name    ──映射──→         productName

数据库字段用下划线命名（如 order_no），Java实体类用驼峰命名（如 orderNo），需要在<resultMap>中用<result>标签做映射，或者在application.yml中配置map-underscore-to-camel-case: true开启全局自动驼峰转换。下面演示手动映射的方式，让你清楚了解映射关系。

返回的Vo：

1
@Data
2
public class OrderDetailVo {
3
    private Integer id;                      // 订单id
4
    private String orderNo;                  // 订单号
5
    private BigDecimal totalPrice;           // 总金额
6
    private Date createTime;                 // 下单时间
7
    private List<OrderItemVo> itemList;      // 订单明细列表（一对多）
8
}
9

10
@Data
11
public class OrderItemVo {
12
    private Integer id;              // 明细id
13
    private Integer orderId;         // 关联的订单id
14
    private String productName;      // 商品名称
15
    private Integer quantity;        // 数量
16
    private BigDecimal price;        // 单价
17
}

展开收起

返回数据示例：

1
{
2
    "code": 200,
3
    "message": "操作成功",
4
    "data": {
5
        "id": 1,
6
        "orderNo": "OD001",
7
        "totalPrice": 5999.00,
8
        "createTime": "2026-05-07 10:30:00",
9
        "itemList": [
10
            {"id": 1, "orderId": 1, "productName": "手机", "quantity": 1, "price": 4999.00},
11
            {"id": 2, "orderId": 1, "productName": "耳机", "quantity": 2, "price": 500.00}
12
        ]
13
    }
14
}

Controller层：

1
/**
2
 * 查询订单详情
3
 * 请求方式：GET
4
 * 接口地址：/api/order/detail/{id}
5
 */
6
@GetMapping("/detail/{id}")
7
public Result detail(@PathVariable("id") Integer id) {
8
    OrderDetailVo order = orderService.getDetailById(id);
9
    return Result.success(order);
10
}

Service层：

1
@Service
2
public class OrderServiceImpl implements OrderService {
3

4
    @Autowired
5
    private OrderMapper orderMapper;
6

7
    @Override
8
    public OrderDetailVo getDetailById(Integer id) {
9
        OrderDetailVo order = orderMapper.selectDetailById(id);
10
        if (order == null) {
11
            throw new BusinessException("订单不存在");
12
        }
13
        return order;
14
    }
15
}

展开收起

Mapper接口：

1
@Mapper
2
public interface OrderMapper {
3
    // 一条SQL查询订单详情（主表+子表），MyBatis自动通过resultMap组装
4
    OrderDetailVo selectDetailById(@Param("id") Integer id);
5
}

Mapper XML（SQL）—— 重点：

OrderMapper.xml展开收起

1
<!-- 1. 先定义主表的resultMap -->
2
<resultMap id="OrderDetailResultMap" type="com.example.vo.OrderDetailVo">
3

4
    <!-- 主表字段映射：column=数据库字段名，property=Vo属性名 -->
5
    <id column="id" property="id"/>
6
    <result column="order_no" property="orderNo"/>
7
    <result column="total_price" property="totalPrice"/>
8
    <result column="create_time" property="createTime"/>
9

10
    <!-- 一对多映射：用collection标签关联子表数据 -->
11
    <collection property="itemList" ofType="com.example.vo.OrderItemVo">
12
        <!-- 子表字段映射 -->
13
        <id column="item_id" property="id"/>
14
        <result column="order_id" property="orderId"/>
15
        <result column="product_name" property="productName"/>
16
        <result column="quantity" property="quantity"/>
17
        <result column="price" property="price"/>
18
    </collection>
19

20
</resultMap>
21

22
<!-- 2. 查询语句：主表LEFT JOIN子表，一条SQL查出所有数据 -->
23
<select id="selectDetailById" resultMap="OrderDetailResultMap">
24
    SELECT
25
        o.id,
26
        o.order_no,
27
        o.total_price,
28
        o.create_time,
29
        i.id          AS item_id,       -- 子表id取别名，避免和主表id冲突
30
        i.order_id,
31
        i.product_name,
32
        i.quantity,
33
        i.price
34
    FROM order_info o
35
    LEFT JOIN order_item i ON o.id = i.order_id
36
    WHERE o.id = #{id}
37
    ORDER BY i.id ASC
38
</select>

展开收起

注意：

<resultMap> 中的 column 是数据库字段名（下划线），property 是Java属性名（驼峰），MyBatis会自动按这个规则映射，不需要你手动转换

<collection> 标签用来映射一对多关系，property 对应Vo中的List字段名，ofType 指定List中每个元素的类型

主表和子表都有id字段时，子表的id必须取别名（如 AS item_id），否则<resultMap>会分不清哪个是主表的、哪个是子表的，导致数据错乱

使用 LEFT JOIN 而不是 INNER JOIN，这样即使订单没有明细也能返回订单基本信息

如果项目配置了 map-underscore-to-camel-case: true，可以不用写<result>标签，但主子表id冲突的问题仍然需要取别名处理

四、Mapper层核心知识#

1、Mapper接口和XML的关系#

1
Mapper接口（Java）          Mapper XML（SQL）
2
┌──────────────────┐      ┌──────────────────────┐
3
│ selectById(id)   │ ──→  │ <select id="selectById"> │
4
│ insert(user)     │ ──→  │ <insert id="insert">     │
5
│ updateById(user) │ ──→  │ <update id="updateById">  │
6
│ deleteById(id)   │ ──→  │ <delete id="deleteById">  │
7
└──────────────────┘      └──────────────────────┘

核心规则：

Mapper接口的方法名必须和XML中的id一致
XML文件放在 resources/mapper/ 目录下
XML的 namespace 必须指向Mapper接口的全限定名

1
<!-- UserMapper.xml 头部 -->
2
<?xml version="1.0" encoding="UTF-8"?>
3
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
4
    "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
5
<mapper namespace="com.example.mapper.UserMapper">
6

7
    <!-- 你的SQL写在这里 -->
8

9
</mapper>

2、常用MyBatis动态SQL标签#

标签	作用	示例场景
	条件判断，满足才拼接	参数不为空时加WHERE条件
	更新字段，自动去尾逗号	只更新非空字段
	自动处理WHERE和AND	动态拼接查询条件
	遍历集合，拼IN语句	批量删除 IN (1,2,3)
	多条件分支（类似if-else）	多种排序方式

3、`#{}` 和 `${}` 的区别（面试常考）#

1
<!-- #{} 推荐！预编译处理，防SQL注入 -->
2
WHERE user_name = #{userName}
3
-- 实际执行：WHERE user_name = ?
4

5
<!-- ${} 字符串拼接，有SQL注入风险，尽量少用 -->
6
WHERE user_name = '${userName}'
7
-- 实际执行：WHERE user_name = '张三'
8

9
<!-- ${} 的使用场景：动态表名、动态列名（不能用#{}的情况） -->
10
ORDER BY ${orderColumn} ${orderDir}

新人记住：99%的情况用 #{} 就对了，只有动态表名/列名才用 ${}。

五、参数接收方式详解#

1、@RequestParam - 接收URL参数#

1
// 请求：GET /api/user/list?name=张三&pageNum=1
2
@GetMapping("/list")
3
public Result list(
4
    @RequestParam("name") String name,
5
    @RequestParam(value = "pageNum", defaultValue = "1") Integer pageNum
6
) {
7
    // ...
8
}

2、@PathVariable - 接收路径参数#

1
// 请求：GET /api/user/detail/123
2
@GetMapping("/detail/{id}")
3
public Result detail(@PathVariable("id") Integer id) {
4
    // id = 123
5
}

3、@RequestBody - 接收JSON格式参数#

1
// 请求：POST /api/user/add
2
// Body: {"userName":"张三","phone":"13800138000"}
3
@PostMapping("/add")
4
public Result add(@RequestBody UserDto userDto) {
5
    // userDto.getUserName() = "张三"
6
}

六、返回结果封装#

1、统一的返回格式#

1
@Data
2
public class Result<T> {
3
    private Integer code;    // 状态码
4
    private String message;  // 提示信息
5
    private T data;          // 返回数据
6

7
    // 成功
8
    public static <T> Result<T> success(T data) {
9
        Result<T> result = new Result<>();
10
        result.setCode(200);
11
        result.setMessage("操作成功");
12
        result.setData(data);
13
        return result;
14
    }
15

16
    // 失败
17
    public static <T> Result<T> error(String message) {
18
        Result<T> result = new Result<>();
19
        result.setCode(500);
20
        result.setMessage(message);
21
        return result;
22
    }
23
}

展开收起

2、返回示例#

成功：

1
{
2
    "code": 200,
3
    "message": "操作成功",
4
    "data": {
5
        "userId": 1,
6
        "userName": "张三"
7
    }
8
}

失败：

1
{
2
    "code": 500,
3
    "message": "用户名已存在",
4
    "data": null
5
}

七、新人避坑指南#

1、常见错误#

错误	正确做法
接口地址写错	按项目规范来，参考已有接口
请求方式用错	查询用GET、新增用POST、修改用PUT、删除用DELETE
参数接收不到	检查注解是否正确：@RequestParam、@RequestBody、@PathVariable
没加事务	多表操作一定要加 @Transactional
没做参数校验	必填参数要判空

2、Integer类型判空的坑#

1
// 错误：Integer类型不能用 != "" 判断
2
if (userId != null && userId != "") {  // 编译报错！
3

4
// 正确：Integer只判断是否为null
5
if (userId != null) {
6

7
// 字符串才需要判断空
8
if (StringUtils.isNotEmpty(userName)) {

3、批量插入性能问题#

1
// 错误：循环调用单条插入，效率很低
2
for (User user : userList) {
3
    userMapper.insert(user);
4
}
5

6
// 正确：使用批量插入
7
userMapper.insertBatch(userList);

八、终极大法#

不会写？看项目里已有的接口是怎么写的，Ctrl+C、Ctrl+V，然后改一改！

步骤：#

找一个类似的接口（比如要写用户查询，就找其他查询接口）
复制Controller、Service、Mapper的代码
改接口地址、改参数、改业务逻辑
用Postman测试
没问题就提交

记住：工作中的代码，大部分是”改”出来的，不是”写”出来的。

九、写完接口后要做什么？#

自己先测试：用Postman或Apifox测试接口是否正常
测试正常流程：输入正确参数，看返回结果
测试异常情况：参数为空、参数错误等情况
看日志：检查是否有异常日志
更新接口文档：如果有要求，更新Swagger或接口文档

十、注意事项#

参考项目中已有的接口写法，不要自己创造新风格
多表操作要加事务 @Transactional
批量插入不要超过5000条，太多要分批处理
Integer类型判空不要加非空字符串判断
先自测再联调，不要一写完就扔给前端
重要操作要打日志，方便排查问题

十一、常见报错及解决方法#

写接口时报错了别慌，大部分都是常见问题，对照下面的表排查就行，也可以直接百度或者交给ai分析。

报错信息	原因	解决方法
Required request body is missing	Controller方法的参数没加@RequestBody	POST/PUT请求用JSON传参时，参数前必须加@RequestBody
Parameter ‘id’ not found	@PathVariable的名字和路径里的占位符不一致	路径是{id}，注解就写@PathVariable(“id”)，两边名字要一样
Invalid bound statement (not found)	Mapper XML没被扫描到	1. 检查XML的namespace是否和Mapper接口全限定名一致 2. 检查XML的id是否和接口方法名一致 3. 检查XML文件是否放在正确的目录下（如resources/mapper/） 4. 检查application.yml中mybatis.mapper-locations配置路径是否正确
Unknown column ‘xxx’	SQL里写的字段名在数据库表中不存在	检查数据库表结构，确认字段名是否正确，注意下划线命名和驼峰命名的对应
Bad SQL Grammar	SQL语法写错了	打开控制台看完整的SQL语句，复制到Navicat里执行排查
No serializer found for class	返回的对象没有getter方法	实体类加上@Data注解（Lombok）或者手动写getter/setter
Request method ‘POST’ not supported	请求方式和Controller定义的不匹配	Controller用的是@GetMapping，前端却用了POST请求，改成一致的就行
Ambiguous mapping	接口地址重复了	两个方法用了相同的URL和请求方式，改掉其中一个的地址
NullPointerException	空指针，某个对象是null却调用了它的方法	重点检查：①Service有没有加@Service ②@Autowired有没有加 ③Mapper查询结果是否为null但没有判空
HttpMessageNotReadableException	前端传的JSON格式不对	检查JSON的字段名是否和DTO的属性名一致，JSON格式是否合法（多余逗号、缺少引号等）

入职后初次写代码该注意什么

Sat, 01 Aug 2026 00:00:00 GMT

一、务必在正确的 Git 分支上开发#

开始编码前，第一件事是确认你所在的分支。

切勿直接在默认主分支（如 main/master）上修改代码。

要问清楚：该在什么分支开发、是否需要新建分支、如果需要新建分支基于哪个分支新建。如果不确认就写代码，后面可能要返工甚至造成代码冲突。

二、务必确保需求已经理解清楚#

在动手写任何代码之前，确保你对需求的理解与产品、测试、导师的理解完全一致。

具体做法：

主动沟通不清楚的点：对模糊不清的需求点，立即提问。使用”确认一下…”的口吻，来复述你的理解，确认你的理解是没有问题的。
输出技术方案（可选但推荐）：对于稍复杂的功能，在编码前用简短的文档或注释梳理核心逻辑、关键数据结构、接口设计及潜在风险点。这能极大地减少返工，并培养你的设计思维。

不要没搞清楚需求就开始写代码，这样很容易返工。

三、边写边测，不要一次性写完再去测试#

如果一项功能需要开发 10 个接口，切忌全部写完再统一测试。

每完成一个接口，就立即进行自测（使用 Postman、Swagger 或单元测试）。这样可以把问题提前暴露出来，避免把问题带到后面的接口开发中。

一次性写完再测，如果出了问题，排查起来会非常痛苦。

四、推荐采用”自上而下”的编写顺序#

建议从**接口层（Controller）开始写，明确接口的入参、出参。再到业务层（Service）编写逻辑，此时仅定义你真正需要的实体类和 DAO 方法。最后才到数据层（Mapper/DAO）**实现具体数据库操作。

这种方式能有效避免提前过度设计，确保每一行代码都服务于明确的业务需求。

如果从 DAO 层开始写，可能会定义很多没有用的方法和实体类，浪费过多的时间。

五、合理使用 AI，让它成为你的”副驾驶”而非”代驾”#

对于刚入行的同学，在使用 AI 辅助编程时，需注意方法，避免过度依赖。

不要将完整的需求描述直接丢给 AI 并期望它生成最终代码，这容易导致生成的代码结构混乱、不符合业务上下文，且后期调试和修改会异常困难。

建议采用”分段提问，主动把控”的策略：

分解任务：先将复杂功能拆解成清晰的步骤和子问题，再针对具体环节（如”如何实现某个查询”、“这个异常该怎么处理”）进行提问。
理解而非照搬：对 AI 给出的代码，务必逐行理解其逻辑和意图，确保你知其所以然。
手动验证与调试：AI 生成的代码可能存在边界错误或性能隐患，关键部分一定要亲自测试、调试，并将其融入你整体的代码框架中。

**AI 是强大的辅助工具，而非替代你思考的”代驾”。**合理使用能提升效率，过度依赖则会阻碍你真正理解业务、积累解决问题的能力。保持主动思考，让 AI 为你的思路服务，而不是被它的输出牵着走。

六、编码常犯问题#

以下列出入职新人最常犯的几个编码问题，一定要注意避免。

1、for 循环里面不要有数据库操作#

for 循环里面进行数据库操作，循环次数越多，性能下降越严重，最终可能导致接口超时或拖垮数据库。

一般都是用空间换时间：

对于查询操作，提前把需要的数据查询出来
对于修改操作，可以批量进行修改

2、不要使用 System.out.println 打印日志#

这种打印日志只适合本地调试的时候使用。

真正上线或者提交代码到远程仓库的时候，一定要把这种打印日志注释掉。因为它是同步输出到控制台，会阻塞主线程，并且无法按级别过滤、归档或收集到日志中心。

正式项目中应该使用日志框架（如 @Slf4j）来打印日志。

3、不要使用魔法数字/字符串#

直接在代码中写数字或字符串，可读性会很差，修改的时候还需要全局搜索，很容易出错。

错误的写法：

1
// 7 和 "SUCCESS" 是什么，可读性和可维护性都比较差
2
if (order.getStatus() == 7) {
3
    return "SUCCESS";
4
}

正确的写法：

1
// 定义枚举
2
public enum OrderStatus {
3
    COMPLETED(7, "已完成");
4
    // ...
5
}
6
if (order.getStatus() == OrderStatus.COMPLETED.getCode()) {
7
    return ResultEnum.SUCCESS.getMessage();
8
}

4、使用事务注解的方法里用 try-catch 把数据库操作包住了#

Spring 事务注解的回滚是通过捕捉异常来回滚的，如果你使用了 try-catch 把异常捕捉掉了，就无法回滚了。

1
@Transactional
2
public void updateOrder(Order order) {
3
    try {
4
        orderMapper.update(order);     // 数据库操作1
5
        accountService.deductBalance(order.getAmount()); // 数据库操作2，可能抛异常
6
    } catch (Exception e) {
7
        log.error("更新失败", e);
8
        // 异常被捕获，事务标记为成功，即使扣款失败，订单状态也已被更新！
9
    }
10
}

5、忽视空指针异常#

对任何可能为 null 的对象（特别是方法参数、查询返回值）进行判空处理，否则很容易出现空指针异常。

1
public class OrderService {
2
    public OrderDTO getOrderDetail(Long orderId) {
3
        // 直接调用，查询结果可能为 null
4
        Order order = orderRepository.findById(orderId);
5

6
        // 直接转换，可能 NPE
7
        OrderDTO dto = convertToDTO(order);
8

9
        return dto; // 如果 order 为 null，convertToDTO 内部可能 NPE
10
    }
11

12
    private OrderDTO convertToDTO(Order order) {
13
        OrderDTO dto = new OrderDTO();
14
        dto.setOrderId(order.getId()); // 如果 order 为 null，这里 NPE
15
        dto.setAmount(order.getTotalAmount());
16
        dto.setItems(order.getItems().stream() // 如果 getItems() 返回 null，这里 NPE
17
                .map(this::convertItem)
18
                .collect(Collectors.toList()));
19
        return dto;
20
    }
21
}

展开收起

6、集合遍历删除元素方式不对，导致 ConcurrentModificationException#

在对集合进行迭代时，如果直接修改集合（添加或删除元素），会抛出 ConcurrentModificationException。这在单线程环境下也可能发生。

错误的写法：

1
// 遍历时删除元素会抛出异常
2
List<String> list = new ArrayList<>(Arrays.asList("A", "B", "C"));
3
for (String item : list) {
4
    if ("B".equals(item)) {
5
        list.remove(item); // 抛出 ConcurrentModificationException!
6
    }
7
}

正确的写法：

1
Iterator<String> iterator = list.iterator();
2
while (iterator.hasNext()) {
3
    String item = iterator.next();
4
    if ("B".equals(item)) {
5
        iterator.remove(); // 安全删除
6
    }
7
}

入职前需要纠正的认知误区

Sat, 01 Aug 2026 00:00:00 GMT

一、为什么需要转变认知？#

很多新人在入职前，技术不一定是最大的问题。真正容易拖垮一个人的，往往是错误的认知和心态。

因为一旦认知没有转过来，入职之后你很容易出现下面这些状态：

遇到不会的问题，第一反应不是思考，而是怀疑自己不行
卡住一点小问题，就开始焦虑、内耗，越想越乱
不敢提问，怕别人觉得自己太菜
别人说什么就信什么，缺乏基本的判断和验证意识
明明可以通过查资料、看日志、读代码解决的问题，却总觉得这样做“显得自己很弱”
不敢主动推进工作，习惯等别人告诉你下一步该做什么

这些问题表面上看是情绪问题，但本质上，它们会直接影响你的工作表现。

轻一点，你会进入一种持续慌乱、低效、容易否定自己的状态；重一点，你会在试用期里长期没有存在感、没有产出、没有成长，最后很难顺利通过考核。

所以，入职前最先要调整的，不只是技术，而是认知

二、关于”程序员能力”的认知#

1、不要把所有程序员都想得很厉害#

新人常见认知：

只要是在公司里上班的程序员，肯定都特别厉害。

实际情况：

认知误区	真实情况
所有同事都是技术大佬	程序员之间能力差异非常大
我比所有人都差	有厉害的人，也有能力一般的人
不敢跟同事交流	大家都是从不会到会的

更合理的认知：

行业里有很厉害的人，也有能力一般的人，大家的水平差异其实很大。

这样你既不会过度自卑，也不会对别人产生不切实际的幻想。

2、不要认为厉害的程序员什么都不用查#

新人常见认知：

厉害的程序员是不是一遇到问题，什么都不用查，什么技术都张口就来？

实际情况：

哪怕是经验丰富的程序员，也离不开：

查询方式	说明
搜索引擎	快速找到类似问题的解决方案
官方文档	确认API的正确用法
AI 工具	快速生成代码片段或解释概念
现有代码	参考项目中的实现方式
社区经验	CSDN、掘金等

真正有经验的程序员，不是”什么都不用查”，而是：

知道去哪里查
知道查什么
知道怎么快速判断哪些信息有用
知道怎么结合项目现有代码落地

核心原则：厉害的程序员，不是不用查资料，而是更会查资料。

3、不要认为别人写代码很快是因为技术特别强#

新人常见认知：

看到同事写代码很快，就觉得对方技术特别强，自己差太远。

实际情况：

很多时候写代码快，是因为：

对方已经做过类似需求
对方对这个项目很熟
对方知道该改哪几处
对方不需要重新理解业务

影响因素	说明
业务熟悉度	对业务流程的掌握程度
项目熟悉度	对代码结构和模块的了解
经验积累	类似功能的实现经验

核心原则：很多时候写代码快，是因为熟悉，而不是因为天赋。

对新人来说，前期最大的差距往往不是能力，而是对业务、项目、代码结构的熟悉程度。这些都是可以通过时间慢慢补上的。

三、关于”学习与成长”的认知#

1、要有主动使用搜索引擎和 AI 的意识#

对于程序员来说，搜索能力和借助工具解决问题的能力，本身就是工作能力的一部分。

很多时候，一个问题你不会，不代表你真的不会，可能只是：

你还没有查过
你还没有把问题描述清楚
你还没有找到合适的关键词
你还没有结合项目代码去验证

核心原则：先查、先搜、先问 AI、先看文档，再判断自己到底会不会。

可以这样理解：

在合理利用搜索引擎、AI、文档和现有代码之后，仍然解决不了的问题，才是真正需要重点突破的”不会”。

这并不是说什么都靠搜，而是说：

要先学会借助工具
再逐渐把这些能力沉淀成自己的东西

2、不要认为”没有问题”才说明自己厉害#

新人常见认知：

一个厉害的程序员，应该是拿到需求就什么问题都没有，什么都懂，什么都不会卡。

实际情况：

真实工作里，越有经验的人，往往越能发现问题：

哪些地方需求没说清楚
哪些边界情况容易出问题
哪些地方有风险
哪些改动会影响上下游

核心原则：没有问题，不一定代表你很厉害；很多时候，恰恰说明你还没有真正看出问题。

反而是那些能及时发现问题、指出风险、提前确认边界的人，通常才更有经验。

工作中最重要的不是”看起来没问题”，而是有问题能够及时发现，并推动解决。

3、不要认为看不懂项目代码就是自己太菜#

新人常见心理：

项目代码看不懂，我是不是太菜了？

实际情况：

公司代码经常会存在：

历史逻辑复杂
命名不规范
注释很少
业务流程绕
系统之间调用很多

核心原则：看不懂项目代码，不一定是你太菜，而是你还处在熟悉项目的阶段。

对刚进入公司的人来说，看不懂代码本来就是一个正常阶段。即使是一个具备真实开发经验的人来说，也不是说进入一家新公司就立马把项目都看懂了。

关键不是一开始能不能全看懂，而是：

能不能慢慢拆解
能不能顺着入口一点点理解
能不能通过需求、日志、接口、表结构把主线梳理出来

四、关于”信息判断与问题排查”的认知#

1、不要对任何信息都毫无保留地直接相信#

在真实工作中，你会从不同的人那里拿到信息：

来源	可能的信息
同事	某个接口就是这样用的
前端	参数一定不会为空
产品	这个逻辑很简单
测试	问题一定出在后端
领导	这块应该没影响
运维/同事	配置文件、服务器信息、数据库信息

这些信息都可以参考，但不能完全不加判断地全盘接受。

因为很多时候，问题之所以复杂，正是因为：

别人提供的信息不完整
别人的理解本身就有偏差
别人说的是旧逻辑，不是最新情况
别人只是凭经验判断，并没有真正验证
配置文件、服务器信息、数据库信息也有可能是错的或过时的

核心原则：对别人提供的信息，先参考，再验证。

要建立基本的判断意识：

验证对象	验证方式
关键结论	确认、沟通
关键数据	核实、查库
关键逻辑	看代码、看文档、看日志

这样才能减少因为”别人说是这样”而踩坑。

2、不要认为所有问题都是代码问题#

新人常见反应：

遇到问题时，第一反应是：是不是代码写错了？

实际情况：

真实工作里，很多问题并不一定出在代码本身：

问题类型	说明
代码问题	逻辑错误、语法错误
环境问题	配置不一致、版本差异
配置问题	配置文件错误、环境变量
数据问题	数据不一致、脏数据
权限问题	没有操作权限
调用顺序问题	接口调用顺序错误
接口联动问题	上下游系统问题

核心原则：问题不一定是代码问题，要从多个角度去分析。

如果一遇到问题就只盯着代码，很容易：

查偏方向
排查效率很低
自己吓自己

更好的方式是先判断：

判断维度	说明
需求 vs 代码	是需求理解问题还是代码实现问题
配置 vs 代码	是配置问题还是代码问题
数据 vs 代码	是数据问题还是代码问题
本地 vs 远程	是自己这边的问题还是上下游联动的问题

五、关于”工作方式与态度”的认知#

1、不要还有被动接收的意识，要具备主观能动性#

新人常见状态：

总觉得别人会主动告诉你该做什么，主动把资料给你，主动把环境和权限准备好。

真实工作里：

不会有人一直这样照顾你。很多事情，如果你自己不开口、不主动推进，就会一直卡着。

核心原则：缺什么，就主动去补什么；少什么，就主动去要什么。

对于自己完成工作需要的东西，要主动去要：

主动争取的内容	说明
文档	需求文档、技术文档
环境	开发环境、测试环境
权限	Git权限、服务器权限
表结构说明	数据库设计文档
接口信息	接口文档、对接人
对接人联系方式	方便沟通协作

不要因为不好意思、怕打扰别人，就一直被动等着。很多时候，事情推进不下去，不是因为真的做不了，而是因为你一直在等。

2、不要认为工作就是一直写代码#

新人常见认知：

程序员的工作就是每天写代码。

实际情况：

工作内容	占比说明
写代码	往往只占一部分时间
看需求	理解业务逻辑
看代码	熟悉项目代码
查日志	排查问题
联调	与前后端、第三方对接
改 bug	修复问题
沟通	与前端、测试、产品沟通
开会	需求评审、技术评审

核心原则：程序员的工作，本质上是解决问题，而不是单纯写代码。

如果你只把自己理解成”写代码的人”，后面就很容易在需求理解、业务沟通、问题排查、联调推进这些事情上吃亏。

3、不要急着证明自己很厉害#

新人常见心态：

刚进公司时会特别急：

想快速证明自己
想表现能力
想让别人觉得自己很强
想尽快接复杂需求

实际情况：

刚入职更重要的不是”证明自己”，而是：

先熟悉项目
先熟悉流程
先把基础事情做好
先建立”靠谱”的印象

核心原则：刚入职阶段，先建立”靠谱”，比急着证明自己更重要。

真正让你在团队里站稳的，往往不是你说了多少，而是你能不能：

建立信任的方式	说明
把事情正常推进	任务按时完成
遇到问题及时反馈	不隐瞒问题
慢慢把短板补起来	持续学习成长
让别人觉得你可沟通	良好的沟通协作

六、关于”人际沟通”的认知#

1、不要认为别人不帮你就是针对你#

新人常见心理：

问同事问题时，对方可能回答很简单、回答比较慢、让你自己先看看，看起来不是特别热情。

于是开始多想：

“是不是觉得我太菜了？”
“是不是不想带我？”
“是不是在针对我？”

实际情况：

对方很忙
对方也不一定完全清楚
对方以为你已经懂了
对方只是表达方式比较直接

核心原则：不要过度解读别人的反应。

更合理的做法是：

先把问题描述清楚
先说你已经尝试过什么
先让对方看到你不是完全没动脑子

这样别人通常也更愿意帮你。

2、提问前要先自己尝试#

新人常见做法：

遇到问题立刻就去问别人，完全没有自己先思考或尝试。

更合理的方式是：

在提问之前，先做到以下几点：

提问前的准备	说明
自己先查一下	搜索引擎、AI、文档
自己先试一下	尝试不同的解决方案
整理问题描述	把问题说清楚
说明已尝试的方法	让别人看到你的努力

核心原则：提问之前先自己尝试，带着问题去问，而不是带着懒惰去问。

这样别人会觉得你是经过思考才来问的，而不是一遇到问题就依赖别人。

七、关于”面对不确定性”的认知#

1、学会接受不确定性，不要总想一开始就拿到标准答案#

新人常见期待：

最好有人把需求讲得很清楚，文档写得很完整，逻辑很统一，流程很明确，我只要照着做就行。

实际情况：

真实工作里，很多事情并不会一开始就那么清晰。你会经常遇到：

需求说得不完整
产品自己也没完全想清楚
文档缺失
老逻辑没人讲得明白
不同的人说法不一致
代码实现和文档描述对不上

核心原则：工作中很多事情，不是”先完全看清，再开始做”，而是”先往前做一点，再慢慢看清”。

新人最容易陷入的痛苦：

我想先把一切都看明白，再开始做。可问题是，我现在又看不明白。所以我就一直卡着，不敢动。

但你要明白：

很多问题的答案，不是在你原地想的时候出现的，而是在你开始查、开始问、开始试、开始推进的过程中，慢慢浮现出来的。

不要试图一开始就拿到全局地图，先走通眼前能走的路。很多时候，是做着做着才看清了，而不是看清了再做。

在信息不完整的情况下，要学会：

应对策略	说明
先确认目前已明确的部分	抓住确定的点
先把能做的部分往前推进	不要等所有信息
在推进过程中持续补信息	边做边完善
通过代码、日志、数据、沟通修正理解	持续验证

遇到”还没有完全搞明白”的情况，先问自己三个问题：

现在已经明确的是什么？
我眼下能推进的第一步是什么？
我还缺哪些信息，可以通过什么方式补齐？

记住：很多事情，不是因为你看清了才敢做，而是因为你开始做了，才慢慢看清。

2、接受”在模糊中前进”是工作的常态#

新人常见心理：

觉得信息不完整就不能开始工作，一定要等所有信息都确认清楚。

真实情况：

工作阶段	信息完整度
刚接手需求	信息往往不完整
做的过程中	逐渐补全信息
快完成时	才可能看清全貌

核心原则：接受”在模糊中前进”，在工作中逐步明确，而不是等到完全明确才开始。

这种能力需要在实践中培养：

从小事开始练习
在小步推进中积累信息
通过验证来修正理解
不要追求一次性完美

入职之后需要注意哪些问题

Sat, 01 Aug 2026 00:00:00 GMT

一、建立良好的人际关系#

和同事处好关系，融入团队，是很多人会忽视的。认为程序猿只要搞好技术就行了，其实是大错特错。你要清楚，你是一个新人，刚进入这个行业，你必然会遇到一堆连不上环境、摸不清流程的坑。这时候，团队里如果能有一个愿意随口提点你两句的‘自己人’，能帮你省掉几个小时甚至一天的瞎折腾。因此，人际关系的基础一定要提前打好，切忌在遇到麻烦时才临时抱佛脚，那种带有强目的性的求助往往效果很差，也容易引起别人反感。社会很现实：如果大家关系好，你的技术失误那叫‘新人正常踩坑’，大家笑笑就帮你解了；如果大家看你不顺眼，你写错一个标点符号那都叫‘能力不行’。更别忘了，‘团队融入度’本身就是领导决定你试用期去留的隐形考核指标。

当然，这里说的“建立关系”，不是让你去刻意讨好谁，而是让你在进入新环境后，不要把自己完全封闭起来。

那应该怎么做？

其实不需要太刻意，也不需要一上来就搞复杂的人情往来。更重要的是做到以下几点：

主动和同事打招呼，不要总是过于封闭
平时有机会时，正常参与聊天和吃饭，不要总是一个人闷着
遇到别人帮助你时，及时表达感谢
在工作配合上积极一点，让别人感受到你是愿意沟通、愿意配合的人

有时候一些小的善意动作，比如一起买水、顺手帮忙、请大家喝个饮料，当然也可以起到拉近关系的作用。

二、尽快熟悉开发流程#

入职后，要尽快搞清楚公司的开发流程和规范。

1、了解公司的开发环境#

需要了解的内容：

公司有哪些开发环境（开发环境、测试环境、生产环境）
每个环境的用途和访问方式
环境之间的配置差异

2、明确 Git 协作流程#

需要搞清楚的问题：

公司使用什么 Git 协调开发的工作流程是什么
分支命名规范是什么
提交代码的流程是怎样的
Code Review 的标准是什么

记住：这些问题要大胆地问，尽早搞清楚。

不懂就问，总比因为不懂而犯错要好得多。

三、开发任务前的准备#

在给你开发任务的时候，有几个关键点一定要注意。

1、需求必须搞清楚#

开发前要确认：

需求的具体逻辑是什么
有哪些边界情况需要处理
输入输出是什么
有哪些异常场景需要考虑

不要没搞清楚需求就开始写代码，这样很容易返工。

2、确定开发分支#

开发前要确认：

应该在哪个分支上开发
分支是从哪里拉取的
开发完成后要合并到哪里

一定要搞清楚在哪个分支开发之后，再写代码。

避免写完代码才发现分支搞错了，需要重新来过。

四、工作态度和表现#

刚入职的前几个月，你的工作态度和表现非常重要。

1、态度要端正#

第一印象很重要：

刚开始多加加班
尽量保证安排的任务都能按时完成
表现出积极的态度

第一印象一旦形成，后面就很难改变了。

2、不要心虚，放平心态#

正确的心理状态：

自信一些，不要一上来就觉得自己什么都不行
承认自己有不足，但也要承认自己有基础
既然能通过面试进入公司，就说明具备一定的能力

既不要妄自菲薄，也不要盲目自大。

3、少说话，多做事（技术层面）#

技术上的”少说话”是指：

没有把握的话不要说
对于不了解的领域，先去了解再发表意见
多听别人说，多学习

为什么不说更好？

你不说，别人可能会认为你对待技术很严谨
说了一些比较低级的问题，别人很容易看出你的水平

多做事是指：

本职工作要主动承担
领导给的其他事情也要积极配合
表现出你的积极性

4、多说话，多沟通（非技术层面）#

非技术上的”多说话”是指：

尽快通过沟通融入到团队中去
建立起自己的朋友圈
参与团队的讨论和活动

总结：技术严谨少说话，融入团队多沟通。

五、提前做好准备#

如果时间比较充裕，可以做一些提前准备。

1、提前写测试接口#

为什么要提前写？

熟悉项目框架的代码结构
提前排雷，了解常见的坑
保证后续给你任务时，能够快速上手

怎么做？

在项目框架里面写个测试接口
熟悉接口的调用方式
了解数据库的连接方式
熟悉常见的工具类和组件

六、Git 操作注意事项#

Git 操作一定要谨慎，一个小错误可能导致严重后果。

1、不明确的操作先备份#

操作前要做的事：

不确定的操作，先备份当前代码
确保出问题时可以快速恢复

2、Pull 前先 Commit#

为什么要这样做？

方便回滚
避免代码冲突时丢失自己的修改

操作流程：

1
1. 先 commit 自己的修改
2
2. 再 pull 远程代码
3
3. 如果有冲突，解决冲突
4
4. 最后再提交

3、切换分支前先 Commit#

为什么要这样做？

避免切换分支时把未提交的修改带到其他分支
保持代码的清晰和可追溯

记住：本地有修改时，一定要先 commit 再切换分支。

七、风险报备意识#

当任务可能无法按时完成时，一定要提前报备。

1、为什么要提前报备？#

提前报备的好处：

给领导留出调整计划的时间
给团队留出应对措施的时间
避免到最后才发现问题，影响整个项目进度

2、什么时候报备？#

报备的时机：

发现需求比自己预想的复杂
遇到无法解决的技术问题
发现需要依赖其他人的工作
意识到时间可能不够

在规定时间内搞不出的需求，一定要提前找 leader 把风险报备上去。

不是等到最后一刻才说，而是发现问题就要及时沟通。

八、保持正确的学习节奏#

刚入职时，很容易受到老员工的影响，要注意保持自己的节奏。

1、不要好高骛远#

要认清的现实：

目前这份工作是你还能学到东西的
你是初次入职，还有很多需要学习
项目虽然可能有问题，但也是学习的机会

2、围绕公司项目去学习#

正确的学习方式：

围绕公司项目去学习
把工作中遇到的问题当成学习机会
不要跟着老员工吐槽项目

3、不要受老员工影响#

老员工的吐槽不代表你的感受：

老员工可能已经工作了几年
他们的节奏和你的不一样
你的节奏不要受老员工的影响

记住：这是你的第一份工作，围绕公司项目去学习，保持自己的节奏。

九、关于包装经验的注意事项#

这是一个比较敏感但非常重要的问题。

1、不要跟任何同事说#

无论关系多好：

不要跟任何同事说你的经验是包装的
即使别人怀疑你，也不要承认

2、可以承认自己菜#

正确的应对方式：

可以承认自己菜
可以承认自己经验不足
可以承认自己有些东西不会

3、菜很正常，包装不正常#

为什么可以承认菜？

菜的程序员是很多的
菜可以通过学习变强
菜不代表你能力有问题

为什么不能承认包装？

包装涉及诚信问题
一旦承认，别人对你的信任会大打折扣
可能会影响你的职业发展

总结：可以承认自己菜，但不要承认自己包装经验。

微服务系统中如何开发

Sat, 01 Aug 2026 00:00:00 GMT

从开发角度来说，微服务项目和单体项目的日常开发区别并没有想象中那么大。因为说到底，微服务架构下的每一个服务，本质上也都是一个独立的 Spring Boot 项目，我们平时写 Controller、Service、Mapper、SQL、接口开发等工作，和在单体项目中并没有太大区别。

真正的区别在于：原本在一个项目内部完成的事情，被拆分到了多个服务之间协同完成。因此在开发过程中，会额外涉及一些单体项目中不太会遇到的问题，例如服务的注册与发现、远程配置管理、服务间远程调用、API 网关、分布式锁、分布式事务等。

所以，对于刚接触微服务的新人来说，不必把它想得过于高深。先把每个服务当成一个普通的 Spring Boot 项目去理解，再逐步掌握服务之间的协作方式，会更容易上手。

微服务架构

一、远程配置与注册中心#

在微服务架构下，有两个基础组件几乎是必须的：配置中心和注册中心。

配置中心解决的是”配置怎么统一管理”的问题，注册中心解决的是”服务之间怎么找到对方”的问题。

这两个东西看起来是独立的功能，但在实际项目中，它们经常由同一个中间件来承担，比如 Nacos 就同时支持配置中心和注册中心。

1、远程配置#

1.1 为什么需要远程配置？#

在单体项目里，配置文件一般就直接放在项目里，比如 application.yml，改了配置就重启服务就行。

但在微服务架构下，通常有这些问题：

公共配置分散，改一处要动 N 个项目：微服务下有十几个甚至几十个服务，很多配置是多个服务共用的（比如 Redis 地址、数据库连接、第三方接口密钥）。虽然 Spring Boot 自带的 Profile 机制（application-dev.yml、application-prod.yml）也能做多环境切换，但当服务数量多了之后，每个服务都维护自己的一套配置文件，公共配置一旦变更就要逐个修改 N 个项目，很容易漏改或改错。配置中心可以把公共配置集中管理，改一次所有服务都生效
敏感配置不适合放在代码仓库中：数据库密码、第三方接口密钥等敏感信息，如果直接写在项目的配置文件里，会被提交到 Git 仓库，存在泄露风险。配置中心可以集中管理这些敏感配置，代码仓库里只保留非敏感的基本配置
配置修改需要重启才能生效：有些配置改了之后，服务必须重启才能生效，这在生产环境是很不方便的

所以，微服务架构下，通常会引入配置中心来统一管理配置。

简单理解：配置中心就是把你之前放在 application.yml 里的配置，搬到远程服务器上统一管理。你可以随时改，改完之后服务可以做到动态生效，不需要重启。

1.2 常见的配置中心#

配置中心	说明
Nacos	阿里开源，国内使用最广泛，同时支持注册中心和配置中心
Apollo	携程开源，功能丰富，配置管理能力很强
Spring Cloud Config	Spring Cloud 官方提供，需要依赖 Git 等存储

其中，Nacos 是国内企业用得最多的，很多公司的微服务架构都是基于 Spring Cloud Alibaba + Nacos 搭建的。

1.3 远程配置一般怎么用？#

以 Nacos 为例，一般的用法是这样的：

1）在 Nacos 控制台上创建配置

你登录 Nacos 控制台，在里面创建一个配置，比如：

Data ID：order-service-dev.yml
Group：DEFAULT_GROUP
配置内容：就是你的 yml 配置，比如数据库连接、Redis 地址等

2）在项目的 bootstrap.yml 中配置 Nacos 地址

1
spring:
2
  application:
3
    name: order-service
4
  cloud:
5
    nacos:
6
      config:
7
        server-addr: 127.0.0.1:8848
8
        file-extension: yml
9
        group: DEFAULT_GROUP   #分组不设置，默认就是DEFAULT_GROUP
10
        namespace: 7c5c0c0d-c0c5-4c0c-b0c5-0c5c0c5c0c5c   #命名空间不设置，默认是public
11
        username: nacos
12
        password: nacos
13
        shared-configs:           # 引入公共配置
14
          - data-id: application-dev.yml   # 公共配置的 Data ID
15
            refresh: true         # 是否支持动态刷新

展开收起

注意：Nacos 配置相关的内容一般放在 bootstrap.yml（或 bootstrap.properties）里，而不是 application.yml。因为 bootstrap.yml 的加载优先级比 application.yml 更高，这样可以保证在应用启动时先连上 Nacos 拉取配置，再进行后续初始化。

除了在 bootstrap.yml 里写死 Nacos 地址，也可以在 IDEA 的启动配置里通过 JVM 参数指定，本地开发时用这种方式更灵活，不用改代码：

在 IDEA 的 Run Configuration 里，找到 VM options，添加：

1
-Dspring.cloud.nacos.config.server-addr=http://127.0.0.1:8848
2
-Dspring.cloud.nacos.config.file-extension=yml
3
-Dspring.cloud.nacos.config.namespace=0662a2cc-f7fd-42e0-b33b-aa07603950bd
4
-Dspring.cloud.nacos.config.shared-configs[0].data-id=application-dev.yml
5
-Dspring.cloud.nacos.config.shared-configs.refresh=true
6
-Dspring.profiles.active=dev
7
-Dspring.cloud.nacos.config.group=DEFAULT_GROUP
8
-Dspring.cloud.nacos.discovery.server-addr=http://127.0.0.1:8848
9
-Dspring.cloud.nacos.discovery.group=zy
10
-Dspring.cloud.nacos.discovery.namespace=0662a2cc-f7fd-42e0-b33b-aa07603950bd

这样本地开发连自己电脑的 Nacos，测试环境连测试环境的 Nacos，只需要改 VM 参数就行，不用动配置文件。

3）启动服务时自动拉取远程配置

服务启动后，会自动去 Nacos 拉取对应的配置，和本地配置合并后生效。

启动过程中，各个配置被读入的先后顺序是这样的：

1
1、bootstrap.yml（本地）
2
        ↓
3
2、拉取公共配置（shared-configs）
4
        ↓
5
3、拉取当前服务自己的配置（Data ID = 服务名.yml）
6
        ↓
7
4、application.yml（本地）
8
        ↓
9
最终合并生效

特别注意：这里讲的”加载顺序”和下面讲的”优先级”不是一回事，别搞混了。 上面说的是各个配置在启动过程中”什么时候被读到”，而真正决定同名属性最终用哪个值的，是优先级。Nacos 拉取到的远程配置会被插入到比本地配置更高的优先级位置上，所以它虽然比 application.yml 先被加载，最终却能覆盖 application.yml。

如果同一个属性在多处都配了，最终生效遵循以下优先级（高优先级覆盖低优先级）：

1
Nacos 服务专属配置（Data ID = 服务名.yml）    ← 最高
2
        ↓ 覆盖
3
Nacos 公共配置（shared-configs）
4
        ↓ 覆盖
5
application.yml（本地）
6
        ↓ 覆盖
7
bootstrap.yml（本地）                          ← 最低

简单记三条就够：

远程 > 本地：Nacos 上的配置会覆盖本地配置
专属 > 共享：服务自己的配置会覆盖公共配置
application > bootstrap：本地文件中，application.yml 覆盖 bootstrap.yml

优先级能改吗？ 能，但一般不需要。Spring Cloud Nacos 提供了一些配置项（如 spring.cloud.config.override-none=true 可以让远程配置不覆盖本地），但实际项目中几乎不会去改默认优先级，了解有这么回事就行。

这也是为什么很多项目本地只保留最基本的配置（服务名、Nacos 地址、端口号等），其他配置全部放到 Nacos 上管理——避免本地和远程配置打架。

当然，如果某个属性只在某一处配了，其他地方没配，那自然就是那一处的值生效。

其中，公共配置是多个服务共用的配置，比如数据库连接、Redis 地址、通用日志配置等。这些配置不需要每个服务都重复配一遍，只需要在 Nacos 上创建一份公共配置文件（如 common.yml），然后在每个服务的 bootstrap.yml 中引入即可。修改公共配置时，所有引用它的服务都会生效，不用一个一个改。

1.4 哪些配置适合放远程，哪些不适合？#

放远程配置中心	放本地配置文件
数据库连接地址	服务端口号
Redis 地址	应用名称
第三方接口地址和密钥	日志级别（本地调试用的）
业务开关配置	框架本身的配置
需要经常修改的配置	基本不会变的配置

原则：多环境有差异的、需要经常修改的、敏感信息类的配置，优先放配置中心。

1.5 配置修改后，服务怎么感知？#

有两种常见方式：

方式一：自动刷新

通过 @RefreshScope 注解，配合 Nacos 的配置监听机制，配置修改后，对应的 Bean 会自动重新创建，不需要重启服务。

实际开发中，最常见的场景是业务开关——比如某个功能上线后发现问题，需要紧急关闭，如果配置写在代码里就只能重新发版；但放在 Nacos 上，改个配置就能即时生效，不用重启服务。

1）在 Nacos 上添加开关配置

1
# 比如配置在 order-service-dev.yml 中
2
order:
3
  flash-sale-enabled: false    # 秒杀功能开关，false 表示关闭
4
  max-order-count: 5           # 单用户最大下单数

2）在代码中通过 @Value 读取，配合 @RefreshScope 实现动态刷新

1
@RestController
2
@RefreshScope
3
public class OrderController {
4

5
    @Value("${order.flash-sale-enabled:false}")
6
    private Boolean flashSaleEnabled;
7

8
    @Value("${order.max-order-count:10}")
9
    private Integer maxOrderCount;
10

11
    @GetMapping("/flashSale")
12
    public String flashSale() {
13
        if (!flashSaleEnabled) {
14
            return "秒杀活动暂未开放";
15
        }
16
        return "秒杀活动进行中，每人限购" + maxOrderCount + "件";
17
    }
18
}

展开收起

启动服务后，浏览器访问 /flashSale 会返回”秒杀活动暂未开放”。然后在 Nacos 上把 order.flash-sale-enabled 改成 true，不用重启服务，再刷新页面就能看到返回”秒杀活动进行中，每人限购5件”。

方式二：手动重启

有些配置改了之后，确实需要重启服务才能生效（比如数据库连接池的配置）。这种情况就直接改配置、重启服务。

1.6 远程配置相关的常见问题#

问题一：本地配置不生效

这是新人特别容易遇到的问题。排查思路：

检查 bootstrap.yml 或 Idea 启动脚本里配置的 Nacos 地址是否正确
检查 Data ID、Group 是否和 Nacos 上的一致
检查环境（dev / test / prod）是否正确
检查远程配置是否覆盖了本地配置（优先级问题）

问题二：配置改了但没生效

确认你改的是不是正确的环境配置（可能改的是测试环境的，但本地连的是开发环境）
确认是否需要 @RefreshScope 才能动态刷新
确认修改后是否需要重启服务

问题三：远程配置里数据库、Redis 这些中间件的 IP，应该写哪个？

很多新人会困惑：Nacos 是配置中心，那配置里的数据库 IP，到底是要写 Nacos 能访问的，还是服务自己能访问的？

答案：写”服务自己能访问的”IP。

原因很简单：Nacos 只是配置的”仓库”，它负责存储和分发配置，本身根本不去连接数据库、Redis 这些中间件。真正拿着这些连接信息去建立连接、发 SQL 的，是消费配置的业务服务（order-service、user-service 等）。所以 IP 必须是业务服务所在的网络环境里能访问到的地址。

举个例子：

Nacos、MySQL、Redis 都部署在 A 服务器
你的业务服务部署在 B 服务器

那么远程配置里数据库、Redis 的 IP 不能写 127.0.0.1 或 localhost，因为 127.0.0.1 在 B 服务器的视角下指的是 B 自己，B 上根本没有装 MySQL/Redis，肯定连不上。应该写 A 服务器对外的 IP（也就是从 B 服务器上能 ping 通的那个 IP）。

2、注册中心（服务的注册与发现）#

2.1 为什么需要注册中心？#

在单体项目里，所有代码都在一起，调用另一个模块的方法直接调就行了，不需要关心对方在哪台机器上。

但在微服务架构下，每个服务都是独立部署的，可能分布在不同机器上，而且服务的实例数量还可能随时变化（比如某个服务扩容了，从 2 个实例变成 5 个；某个实例挂了，只剩 4 个了）。

1
订单服务想调用用户服务，问题是：
2
    - 用户服务部署在哪台机器上？
3
    - IP 地址是多少？端口是多少？
4
    - 用户服务有几个实例？调哪个？
5
    - 如果某个实例挂了怎么办？

如果这些信息全靠人工维护，比如在配置文件里写死每个服务的 IP 和端口，那根本管不过来：

某个服务换了机器，所有调用方都要改配置
某个服务扩容了，调用方不知道新的实例在哪
某个服务挂了，调用方还在傻傻地请求已经不存在的地址

注册中心就是用来自动解决这些问题的。

2.2 注册中心是做什么的？#

用一句话概括：

注册中心就是一个”服务通讯录”，每个服务启动时把自己的地址登记上去，需要调用别人时从通讯录里查。

2.3 注册中心的工作流程#

2.4 常见的注册中心#

注册中心	说明
Nacos	阿里开源，国内使用最广泛，同时支持注册中心和配置中心
Eureka	Netflix 开源，Spring Cloud 早期默认组件，目前已停止维护
ZooKeeper	Apache 基金会项目，Dubbo 早期默认使用的注册中心
Consul	HashiCorp 开源，功能丰富，支持多数据中心

其中，Nacos 是目前国内企业使用最多的注册中心，特别是基于 Spring Cloud Alibaba 的微服务项目，基本上都是用 Nacos。前面说过，Nacos 同时支持配置中心和注册中心，所以很多公司只需要部署一个 Nacos 就够了。

2.5 服务注册与发现在代码中是怎么体现的？#

很多新人会觉得：“注册中心这么重要，我是不是要写很多注册相关的代码？”

实际上，注册中心的使用基本上是自动的，你不需要手动写注册和发现的代码。

以 Spring Cloud Alibaba + Nacos 为例，我们的项目只需要：

1）添加依赖

1
<dependency>
2
    <groupId>com.alibaba.cloud</groupId>
3
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
4
</dependency>

2）在配置文件中指定 Nacos 地址

1
spring:
2
  application:
3
    name: order-service    # 服务名，注册到 Nacos 上的名称
4
  cloud:
5
    nacos:
6
      discovery:
7
        server-addr: 127.0.0.1:8848   # Nacos 地址
8
        group: DEFAULT_GROUP   #分组不设置，默认就是DEFAULT_GROUP
9
        namespace: 7c5c0c0d-c0c5-4c0c-b0c5-0c5c0c5c0c5c   #命名空间不设置，默认是public
10
        username: nacos
11
        password: nacos

也是可以在IDEA 的启动配置里通过 JVM 参数指定。

3）启动服务

服务启动后，Spring Cloud 会自动帮你完成以下操作：

把当前服务（order-service）注册到 Nacos
定时向 Nacos 发送心跳，告诉它”我还活着”
当你用 Feign 或 Dubbo 调用其他服务时，自动从 Nacos 查询目标服务的地址

你在 Nacos 控制台的”服务列表”页面，就能看到所有已注册的服务及其实例信息。

2.6 关于服务注册与发现的几个关键概念#

1）服务注册

服务启动时，将自己的信息（服务名、IP、端口等）注册到注册中心。

2）服务发现

服务消费方从注册中心获取目标服务的实例列表，选择其中一个进行调用。

3）心跳检测

注册中心会定时检查每个服务是否还活着。如果某个服务长时间没有发送心跳，注册中心会认为它已经挂了，把它从服务列表中剔除。

4）负载均衡

当一个服务有多个实例时，调用方需要决定请求哪个实例。常见的负载均衡策略有：

策略	说明
轮询	按顺序依次请求每个实例
随机	随机选一个实例
权重	按权重比例分配请求（性能好的机器权重高，分配更多请求）

在 Spring Cloud 中，负载均衡默认使用的是 Spring Cloud LoadBalancer（早期版本用的是 Ribbon，从 Spring Cloud 2020.0 开始 Ribbon 已被移除，统一换成 LoadBalancer）。一般不需要你手动配置。

2.7 注册中心相关的常见问题#

问题一：服务启动了，但注册中心上看不到

排查思路：

检查 Nacos 地址是否配置正确
检查服务名是否正确
检查网络是否能连上 Nacos（telnet 一下 Nacos 的端口）
检查依赖是否引入了 spring-cloud-starter-alibaba-nacos-discovery
看启动日志里有没有注册失败的报错

问题二：远程调用报错”找不到服务”

这种情况通常是调用方在注册中心上找不到目标服务。排查思路：

确认目标服务是否已启动并注册成功
确认调用方配置的目标服务名和注册中心上的服务名是否一致（大小写、横杠、下划线等）
确认调用方和目标服务连的是同一个 Nacos、同一个命名空间（namespace）、同一个分组

3、一些注意事项#

1）先搞清楚你们公司用的是哪个注册中心和配置中心

如果有使用注册中心：确认注册中心和配置中心用的是 Nacos、Apollo + Eureka 还是别的？管理后台地址是什么？可以直接问AI或者看pom文件引入的依赖是什么。

2）配置改完，记得确认是否生效

不要改完 Nacos 上的配置就觉得万事大吉了。有时候你可能改的是测试环境的配置，但本地连的是开发环境；或者配置改了但没刷新成功。改完之后，最好实际验证一下。

3）不要随便改生产环境的配置

生产环境的配置修改一般有流程和审批机制，不要直接上去改。如果确实需要改，先和同事确认。

4）服务启动后，先去注册中心确认注册成功

不要启动完就不管了。登录 Nacos 控制台，看服务列表里有没有你的服务，实例信息（IP、端口）是否正确。如果注册都没成功，后续的远程调用肯定会出问题。

5）本地开发时，注意环境隔离

本地调试代码时，经常会遇到一种情况：你明明改了代码，但调用时发现改的没生效。这时候很可能是请求没有走到你本地启动的服务实例，而是走到了线上或测试环境的服务实例上。

排查方法：

在本地服务打断点：如果请求走的是你本地的服务，断点一定会被命中。断点没命中，说明请求走的是远程实例
通过命名空间或分组隔离：本地开发时，把服务注册到一个独立的命名空间或分组（比如 dev-local），这样本地实例和线上实例互不干扰
Dubbo 可以改版本号：本地服务配置一个不同的版本号（比如 version = "1.0.0-local"），调用方指定这个版本号，就能确保请求只走你本地的实例

二、远程调用#

1、为什么需要远程调用？#

在单体项目里，所有代码都在一个项目里，模块之间直接调用方法就行了：

1
// 单体项目：直接调用
2
orderService.createOrder(order);

但在微服务架构下，系统被拆成了多个独立的服务，比如：

用户服务
订单服务
商品服务
支付服务

订单服务要查用户信息，不可能直接调用用户服务的方法，因为它们是两个独立的 Java 进程，跑在不同的机器上。

这时候就需要通过远程调用来让服务之间互相通信。

1
订单服务
2
        ↓ （远程调用）
3
用户服务

简单理解：远程调用，就是服务 A 通过网络请求去调用服务 B 的接口，看起来像调用本地方法一样，但底层实际上是通过 HTTP 或 RPC 发了一次网络请求。

2、常见的远程调用方式#

方式	说明	典型框架
HTTP 调用	通过 HTTP 协议调用其他服务的接口	RestTemplate、OpenFeign
RPC 调用	通过自定义协议直接调用，性能更好	Dubbo

目前企业里用得比较多的是 OpenFeign（HTTP 方式）和 Dubbo（RPC 方式）。

3、OpenFeign 的基本用法#

OpenFeign 是 Spring Cloud 提供的一个声明式 HTTP 客户端，用起来非常简单。

1）添加依赖

1
<dependency>
2
    <groupId>org.springframework.cloud</groupId>
3
    <artifactId>spring-cloud-starter-openfeign</artifactId>
4
</dependency>

2）在启动类上开启 Feign

1
@EnableFeignClients
2
@SpringBootApplication
3
public class OrderApplication {
4
    public static void main(String[] args) {
5
        SpringApplication.run(OrderApplication.class, args);
6
    }
7
}

3）定义 Feign 接口

1
@FeignClient(name = "user-service")
2
public interface UserClient {
3

4
    @GetMapping("/user/{id}")
5
    UserDTO getUserById(@PathVariable("id") Long id);
6
}

这段代码的意思是：

name = "user-service"：要调用的目标服务名（注册中心上的服务名）
@GetMapping("/user/{id}")：目标服务的接口路径
UserDTO：返回值类型

重要：Feign 接口的入参必须加注解。

普通 Controller 里，简单类型的参数不加注解默认当 @RequestParam 处理，但 Feign 接口不行，不加注解会报错或参数传不过去。必须通过注解明确告诉 Feign 参数放在哪：

1
// 路径参数 → @PathVariable
2
@GetMapping("/user/{id}")
3
UserDTO getUserById(@PathVariable("id") Long id);
4

5
// 查询参数 → @RequestParam
6
@GetMapping("/user/list")
7
List<UserDTO> listUsers(@RequestParam("name") String name,
8
                        @RequestParam("page") Integer page);
9

10
// 请求体 → @RequestBody（POST/PUT 传对象）
11
@PostMapping("/user")
12
void createUser(@RequestBody UserDTO user);
13

14
// 请求头 → @RequestHeader
15
@GetMapping("/user/info")
16
UserDTO getInfo(@RequestHeader("Authorization") String token);
17

18
// 文件上传 → @RequestPart
19
@PostMapping(value = "/upload", consumes = MediaType.MULTIPART_FORM_DATA_VALUE)
20
void upload(@RequestPart("file") MultipartFile file);
21
// consumes 指定请求格式，文件上传用 multipart/form-data，不加一般也能自动识别

展开收起

4）在业务代码中直接注入使用

1
@Service
2
public class OrderServiceImpl implements OrderService {
3

4
    @Autowired
5
    private UserClient userClient;
6

7
    public OrderDTO getOrderDetail(Long orderId) {
8
        Order order = orderMapper.selectById(orderId);
9
        // 远程调用用户服务，查询下单用户信息
10
        UserDTO user = userClient.getUserById(order.getUserId());
11
        // 组装返回
12
        OrderDTO dto = new OrderDTO();
13
        dto.setOrder(order);
14
        dto.setUser(user);
15
        return dto;
16
    }
17
}

展开收起

可以看到，使用起来和调用本地方法几乎没有区别，这就是 OpenFeign 的好处。

3.1 Feign 接口抽取到独立 API 模块（最常见的做法）#

上面演示的是在消费方（order-service）里自己写 Feign 接口。但工作中更常见的做法是：服务提供方把 Feign 接口和 DTO 放到一个独立的模块里，打成 jar 包，消费方直接引用这个 jar 包就行。

1
openfeign-test/                       ← 父工程
2
├── user-api                          ← 独立模块，只放接口和 DTO
3
│   └── com.example.user.api
4
│       ├── UserClient.java           ← Feign 接口
5
│       └── UserDTO.java              ← 数据传输对象
6
├── user-service                      ← 服务提供方（用户服务）
7
│   └── com.example.user
8
│       ├── UserServiceApplication.java
9
│       └── controller/
10
│           └── UserController.java   ← Controller 实现 UserClient 接口
11
└── order-service                     ← 服务消费方（订单服务）
12
    └── com.example.order
13
        └── OrderServiceApplication.java

服务提供方的 Controller 直接实现这个 Feign 接口：

1
// user-api 模块中的 Feign 接口
2
@FeignClient(name = "user-service")
3
public interface UserClient {
4

5
    @GetMapping("/user/{id}")
6
    UserDTO getUserById(@PathVariable("id") Long id);
7

8
    @PostMapping("/user")
9
    void createUser(@RequestBody UserDTO user);
10
}
11

12
// user-service-impl 模块中的 Controller 实现该接口
13
@RestController
14
public class UserController implements UserClient {
15

16
    @Autowired
17
    private UserService userService;
18

19
    @Override
20
    public UserDTO getUserById(Long id) {
21
        return userService.getUserById(id);
22
    }
23

24
    @Override
25
    public void createUser(UserDTO user) {
26
        userService.createUser(user);
27
    }
28
}

展开收起

消费方只需要在 pom.xml 里引用 user-api 的依赖，就能直接注入使用：

1
<!-- order-service 的 pom.xml -->
2
<dependency>
3
    <groupId>com.example</groupId>
4
    <artifactId>user-api</artifactId>
5
    <version>1.0.0</version>
6
</dependency>

1
// order-service 中直接注入，不用自己写 Feign 接口
2
@Autowired
3
private UserClient userClient;

这样做的好处：

消费方不用自己写 Feign 接口，直接引用提供方的 jar 包，减少重复代码
接口和实现天然一致，因为 Controller 实现了 Feign 接口，路径、参数、返回值都是一样的，不会出现”调用方写的接口和提供方不一致”的问题
DTO 共享，请求和响应的对象也放在 api 模块里，双方用的是同一个类

简单理解：就像你调用别人的 SDK，人家把接口定义好打成 jar 包给你用，你不用关心人家怎么实现的，直接调就行。
入职后看到项目结构里有 xxx-api 模块，多半就是这种模式。

3.2 `contextId` 解决同服务名多个 FeignClient（了解）#

有些项目会把一个大服务的接口拆成多个 FeignClient（比如用户查询一组、用户管理一组），这时会出现两个 @FeignClient 的 name 相同的情况，启动会报错。加上 contextId 就能解决：

1
// 两个接口都指向 user-service，用 contextId 区分
2
@FeignClient(name = "user-service", contextId = "userQueryClient")
3
public interface UserQueryClient {
4

5
    @GetMapping("/user/{id}")
6
    UserDTO getUserById(@PathVariable("id") Long id);
7
}
8

9
@FeignClient(name = "user-service", contextId = "userManageClient")
10
public interface UserManageClient {
11

12
    @PostMapping("/user")
13
    void createUser(@RequestBody UserDTO user);
14

15
    @PutMapping("/user")
16
    void updateUser(@RequestBody UserDTO user);
17
}

展开收起

简单理解：Spring 容器里不能有两个同名的 Bean。name 相同的 FeignClient 会冲突，contextId 就是给它们起不同的 Bean 名字。

4、Dubbo 的基本用法#

Dubbo 是阿里开源的 RPC 框架，在国内企业中使用也非常广泛。和 OpenFeign 基于 HTTP 不同，Dubbo 使用自定义的二进制协议进行通信，性能更高。

4.1 Dubbo 和 OpenFeign 的区别#

对比项	OpenFeign	Dubbo
通信协议	HTTP	自定义 RPC 协议（默认 Dubbo 协议）
性能	一般（HTTP 协议开销较大）	更高（二进制协议，序列化效率更高）
使用方式	声明式接口 + Spring MVC 注解	声明式接口 + Dubbo 注解
服务注册	依赖 Spring Cloud 注册中心	自带注册中心集成（Nacos、ZooKeeper 等）
生态	Spring Cloud 生态	Dubbo 生态（Spring Boot 也可以集成）
适用场景	中小型项目、对外接口	高并发内部服务调用

简单理解：OpenFeign 就像你用浏览器访问网页，走的是通用的 HTTP 协议；Dubbo 就像两个人打专线电话，用专门的协议直接通话，速度更快但需要两边都用同一套协议。

4.2 Dubbo 的基本用法#

Dubbo 的使用方式有两种主流写法：一种是老版本的 XML / 注解方式，另一种是新版本推荐的 Spring Boot 方式。现在新项目基本都用 Spring Boot 方式，这里也以此为例。

1）添加依赖

服务提供方和服务消费方都需要引入 Dubbo 的 starter：

1
<dependency>
2
    <groupId>org.apache.dubbo</groupId>
3
    <artifactId>dubbo-spring-boot-starter</artifactId>
4
    <version>3.2.0</version>
5
</dependency>
6
<!-- 注册中心以 Nacos 为例 -->
7
<dependency>
8
    <groupId>org.apache.dubbo</groupId>
9
    <artifactId>dubbo-registry-nacos</artifactId>
10
    <version>3.2.0</version>
11
</dependency>

2）配置 Dubbo

1
dubbo:
2
  application:
3
    name: user-service
4
  registry:
5
    address: nacos://127.0.0.1:8848?namespace=7c5c0c0d-c0c5-4c0c-b0c5-0c5c0c5c0c5c&group=zy
6
    username: nacos
7
    password: nacos
8
  protocol:
9
    name: dubbo
10
    port: 20880

3）定义服务接口

Dubbo 的做法是：把接口定义抽成一个独立的模块（API 模块），服务提供方和消费方都依赖这个模块。

1
// user-api 模块（公共接口）
2
public interface UserService {
3
    UserDTO getUserById(Long id);
4
}

4）服务提供方实现接口

在用户服务中实现这个接口，并暴露为 Dubbo 服务：

1
// user-service 模块（服务提供方）
2
@DubboService
3
public class UserServiceImpl implements UserService {
4

5
    @Autowired
6
    private UserMapper userMapper;
7

8
    @Override
9
    public UserDTO getUserById(Long id) {
10
        User user = userMapper.selectById(id);
11
        UserDTO dto = new UserDTO();
12
        dto.setId(user.getId());
13
        dto.setName(user.getName());
14
        return dto;
15
    }
16
}

展开收起

@DubboService 注解表示：这个类是一个 Dubbo 服务，会自动注册到注册中心，其他服务可以通过远程调用来使用它。

5）服务消费方调用远程服务

在订单服务中，通过 @DubboReference 注入远程服务：

1
// order-service 模块（服务消费方）
2
@Service
3
public class OrderServiceImpl implements OrderService {
4

5
    @DubboReference
6
    private UserService userService;
7

8
    public OrderDTO getOrderDetail(Long orderId) {
9
        Order order = orderMapper.selectById(orderId);
10
        // 远程调用用户服务
11
        UserDTO user = userService.getUserById(order.getUserId());
12
        OrderDTO dto = new OrderDTO();
13
        dto.setOrder(order);
14
        dto.setUser(user);
15
        return dto;
16
    }
17
    }

展开收起

可以看到，使用方式和 OpenFeign 类似，注入后直接调用方法就行，底层 Dubbo 会自动完成远程调用。

6）启动类上加注解

1
@EnableDubbo
2
@SpringBootApplication
3
public class OrderApplication {
4
    public static void main(String[] args) {
5
        SpringApplication.run(OrderApplication.class, args);
6
    }
7
}

说明：Dubbo 3.x 配合 dubbo-spring-boot-starter 时已经支持自动装配，理论上可以不写 @EnableDubbo。但项目里如果用到了包路径扫描（比如服务接口分散在多个包下），写上 @EnableDubbo 并配合 @DubboService/@DubboReference 会更稳妥，所以很多老项目和教程里都保留了这个注解。新人照着现有代码来就行。

4.3 Dubbo 使用时的注意事项#

1）接口模块要独立

Dubbo 的服务接口（如 UserService）通常放在一个独立的 api 模块中，服务提供方和消费方都依赖这个模块。这样消费方不需要依赖服务提供方的整个项目，只需要知道接口定义就行。

2）序列化问题

Dubbo 远程调用时，传输的对象需要能被序列化。所以 DTO 类一定要实现 Serializable 接口：

1
public class UserDTO implements Serializable {
2
    private static final long serialVersionUID = 1L;
3
    private Long id;
4
    private String name;
5
    // ...
6
}

3）版本号

Dubbo 支持给同一个接口配置不同的版本号，在做接口升级时非常有用：

1
// 服务提供方
2
@DubboService(version = "2.0")
3
public class UserServiceImplV2 implements UserService { ... }
4

5
// 服务消费方
6
@DubboReference(version = "2.0")
7
private UserService userService;

4）超时和重试配置

Dubbo 的超时和重试配置在后面”远程调用失败怎么办”章节会详细讲，这里先知道有这个概念就行。

5）Dubbo 和 OpenFeign 在 Nacos 服务列表中的区别

使用 OpenFeign 的项目，所有服务都会注册到 Nacos 服务列表中，不管是调用方还是被调用方。

但 Dubbo 不一样：只有服务提供者会注册到 Nacos 服务列表，消费者默认不会注册。 消费者只是订阅它需要调用的服务，不会把自己作为”服务”注册上去。

所以如果你用的是 Dubbo，在 Nacos 服务列表里只看到提供者、看不到消费者，这是正常的，不是配置问题。想确认消费者是否正常工作，可以在 Nacos 控制台点进某个服务，查看它的”订阅者列表”（注意：Dubbo 3.x 中订阅者的应用名可能显示为 “unknown”，这也是正常现象，不影响实际调用）。

4.4 怎么快速判断项目用的是哪种？#

入职后，快速判断项目远程调用方式的方法：

特征	OpenFeign	Dubbo
看依赖	有 spring-cloud-starter-openfeign	有 dubbo-spring-boot-starter
看注解	有 @FeignClient	有 @DubboService、@DubboReference（3.x）或 @Service、@Reference（2.x）
看配置	有 feign 相关配置	有 dubbo 相关配置
看项目结构	不一定有独立 api 模块	通常有独立的 api/接口模块

注意：有些项目可能同时用了 OpenFeign 和 Dubbo。比如内部服务间调用用 Dubbo（性能更好），调用外部系统用 OpenFeign（走 HTTP 更通用）。碰到这种情况不要奇怪。

5、远程调用失败怎么办？#

5.1 超时配置#

不管是 OpenFeign 还是 Dubbo，都需要合理配置超时时间。

OpenFeign 超时配置：

1
feign:
2
  client:
3
    config:
4
      default:
5
        connectTimeout: 5000   # 连接超时 5 秒
6
        readTimeout: 10000     # 读取超时 10 秒

Dubbo 超时配置：

1
dubbo:
2
  consumer:
3
    timeout: 5000    # 全局超时 5 秒

也可以在注解上针对单个服务设置超时：

1
@DubboReference(timeout = 10000)
2
private UserService userService;

注意：正常情况下不需要单独设置超时时间，公司一般通过 Nacos 远程配置统一管理，或者直接使用框架默认值。除非你新写的接口调用比较耗时，而且已经优化到极限、业务方也可以接受，这时候再去修改超时配置。

5.2 重试#

有些临时性的网络抖动，重试一次可能就好了。但重试要谨慎，因为很多时候，请求超时并不代表业务一定失败。比如下游服务可能已经成功执行了，只是响应返回过程中超时了，如果此时直接重试，可能会导致重复下单、重复扣款等问题。

正因为如此，大部分项目不会在远程调用层面对所有接口统一开启自动重试。通常只会对查询类、幂等接口做有限重试，而新增、扣减、支付类接口一般会禁用自动重试。

处理方式有两种思路：

直接禁用重试：简单粗暴，非幂等接口设置 retries = 0，大部分项目用这种
把接口做成幂等：比如下单接口用唯一订单号做去重，扣款接口用唯一交易流水号做去重，同样的请求只处理一次。这样即使重试也不会重复操作，但需要额外开发去重逻辑

说明：OpenFeign 默认不重试，调用失败直接抛异常，所以一般不需要额外配置。Dubbo 默认会重试 2 次（总共调用 3 次），非幂等接口一定要手动设置 retries = 0，否则可能会重复操作。

如果确实需要 OpenFeign 开启重试（比如查询类接口），配置一个 Retryer Bean 即可：

1
@Configuration
2
public class FeignConfig {
3

4
    @Bean
5
    public Retryer retryer() {
6
        // 参数：初始间隔(ms)、最大间隔(ms)、最大尝试次数（含首次调用）
7
        return new Retryer.Default(100, 1000, 3);
8
    }
9
}

注意：这是全局配置，对所有 FeignClient 生效。如果项目中既有查询接口（可重试）又有写入接口（不可重试），就不要全局开启，可以在 @FeignClient 的 configuration 属性上针对单个客户端指定配置。

如果用的是 Dubbo，可以通过配置或注解设置重试次数：

1
dubbo:
2
  consumer:
3
    retries: 2       # 全局重试 2 次（总共调用 3 次）

也可以在注解上针对单个服务设置：

1
@DubboReference(retries = 0)  // 不重试（非幂等接口建议关闭）
2
private OrderService orderService;
3

4
@DubboReference(retries = 2)  // 重试 2 次（查询类接口可以开）
5
private UserService userService;

5.3 降级（Fallback）#

降级就是调用失败时，不直接报错，而是返回一个兜底结果：

1
@FeignClient(name = "user-service", fallback = UserClientFallback.class)
2
public interface UserClient {
3

4
    @GetMapping("/user/{id}")
5
    UserDTO getUserById(@PathVariable("id") Long id);
6
}
7

8
// 降级类
9
@Component
10
public class UserClientFallback implements UserClient {
11

12
    @Override
13
    public UserDTO getUserById(Long id) {
14
        UserDTO fallback = new UserDTO();
15
        fallback.setId(id);
16
        fallback.setName("未知用户");
17
        return fallback;
18
    }
19
}

展开收起

踩坑提醒：Spring Cloud 2020+ 移除了 Hystrix，如果项目中没有引入替代的断路器依赖（如 spring-cloud-starter-circuitbreaker-resilience4j），或者没有在配置文件中开启 spring.cloud.openfeign.circuitbreaker.enabled=true，fallback 属性会静默失效，不报错也不降级。另外，降级类一定要加 @Component 注解，否则 Spring 不认识它，fallback 同样不会生效。

Dubbo 没有像 OpenFeign 那样内置的 fallback 参数，但可以通过 mock 属性声明降级逻辑：

1
@DubboReference(version = "1.0.0", mock = "return null")
2
private UserService userService;

mock 的几种写法：

写法	说明
mock = “return null”	调用失败直接返回 null
mock = “return 默认值”	比如 return new UserDTO()
mock = “force: return null”	不管调用是否失败，直接返回 null（用于手动关闭某个调用）
mock = “com.example.MockUserService”	指定一个 Mock 类，实现完整的降级逻辑

说明：mock 方式虽然简单，但大部分项目中用得不多，很多项目直接不配降级，远程调用失败就抛异常，由全局异常处理器统一处理。入职后先看项目里有没有现成的写法，照着来就行。

不过，降级不是所有项目都会用。有些公司要求每个远程调用都配置降级；也有很多项目不配降级，远程调用失败就直接抛异常，由全局异常处理器统一处理。两种方式都可以，取决于公司的技术规范。入职后先看项目里有没有降级相关的代码，照着现有写法来就行。

注意：配置了 fallback 的话，降级类里返回的值要合理。比如查询用户信息失败，返回”未知用户”是合理的；但如果下单接口失败返回”下单成功”，那就会出大问题。

5.4 熔断(了解)#

熔断和降级通常会配合使用。当某个服务调用失败率过高、响应时间过长，或者异常次数达到阈值后，熔断器会暂时阻止继续调用下游服务，避免故障扩散。此时系统通常会进入降级逻辑，返回默认值、缓存数据或友好提示。就像家里的保险丝，电流过大时自动断开，保护整个电路不烧毁。

常见的熔断框架有 Sentinel 和 Resilience4j，国内企业用 Sentinel 比较多。早期的 Hystrix 目前已经停止维护，新项目基本不再使用。

如果项目用了 Sentinel，通常会通过 @SentinelResource 注解标记需要保护的远程调用方法，然后在 Sentinel 控制台上配置熔断规则。

不过，熔断在很多公司的项目中并没有使用。因为熔断、限流等治理功能会增加系统复杂度，需要额外维护规则、监控和告警。对于访问量不大、服务链路不复杂的项目，很多公司不会专门引入完整的熔断体系，只用 Nacos + OpenFeign/Dubbo + Gateway 就够了。所以入职后发现项目里没有熔断相关的代码，不要觉得奇怪。先了解公司有没有用，如果有就学一下 Sentinel 的用法，如果没有就不用管。

6、远程调用时需要注意的问题#

1）不要循环调用远程接口

1
// 错误示范：循环调用远程接口，性能极差
2
for (Order order : orders) {
3
    UserDTO user = userClient.getUserById(order.getUserId());
4
    order.setUserName(user.getName());
5
}

如果列表有 100 条数据，就要发 100 次远程调用，性能会非常差。

正确做法是提供一个批量查询接口：

1
// 正确做法：批量查询
2
List<Long> userIds = orders.stream().map(Order::getUserId).collect(Collectors.toList());
3
List<UserDTO> users = userClient.listUsersByIds(userIds);

2）远程调用报”找不到服务”或”No provider available”

这是远程调用最常见的报错之一，但问题根源通常不在调用代码本身，而是注册中心层面的问题（服务没注册上、命名空间/分组不一致等）。排查思路见前面「注册中心」章节的常见问题。

3）本地调试时注意环境隔离，避免请求打到远程实例

本地开发时，你的服务和线上/测试环境的服务都注册在同一个 Nacos 上。这时候远程调用可能会被负载均衡到别人的实例上，而不是你本地启动的实例。表现就是：你明明改了代码，但调用时发现没生效，断点也进不去。

解决方法在前面「注册中心」章节的注意事项里有详细说明（独立命名空间、Dubbo 改版本号等），这里不再重复。

三、API 网关#

1、为什么需要 API 网关？#

在微服务架构下，系统被拆分成了多个独立服务，每个服务都有自己的地址。如果让前端直接调各个服务，会有一堆问题：前端要维护多个服务地址、每个服务各自做鉴权逻辑重复、跨域问题无法统一处理、没有统一入口做限流。

所以，微服务架构下通常会引入 API 网关，作为整个系统的统一入口。网关的核心功能：

功能	说明
路由转发	根据请求路径，把请求转发到对应的微服务
统一鉴权	在网关层统一校验 Token 和权限，不需要每个服务各自处理
限流	控制某个接口或服务的访问频率，防止流量过大拖垮系统
日志记录	统一记录请求日志，方便排查问题
跨域处理	在网关层统一解决跨域问题，不需要每个服务各自配置

简单理解：网关就像一栋大楼的前台。你要找不同部门的人，不需要自己记住每个人在哪个房间，只需要到前台，前台帮你转接到对应的房间。同时，前台还会检查你的身份（鉴权）、控制来访人数（限流）。

1
前端 / 客户端
2
        ↓
3
   API 网关（统一入口）—— 鉴权、限流、日志、路由转发
4
        ↓
5
   ┌────┴────┬────────┐
6
   ↓         ↓         ↓
7
用户服务   订单服务   商品服务

常见的网关有 Spring Cloud Gateway（Spring 官方，目前国内使用最广泛）、Zuul（Netflix 开源，已停止维护）、Kong（基于 Nginx + Lua）。目前新项目基本都用 Spring Cloud Gateway。

2、Spring Cloud Gateway 快速上手#

1）添加依赖

1
<dependency>
2
    <groupId>org.springframework.cloud</groupId>
3
    <artifactId>spring-cloud-starter-gateway</artifactId>
4
</dependency>

注意：Gateway 基于 Netty + WebFlux，因此网关模块中一般不要再引入 spring-boot-starter-web（Spring MVC），否则容易出现 Web 容器冲突导致启动失败。只是网关模块不能用 Spring MVC，其他业务服务正常使用 Spring MVC 没有问题。

2）配置路由规则

以若依微服务版的网关配置为例（国内使用非常广泛的开源框架）：

1
spring:
2
  cloud:
3
    gateway:
4
      routes:
5
        # 认证中心
6
        - id: ruoyi-auth
7
          uri: lb://ruoyi-auth
8
          predicates:
9
            - Path=/auth/**
10
          filters:
11
            - CacheRequestFilter        # 自定义过滤器：缓存请求体
12
            - ValidateCodeFilter        # 自定义过滤器：校验验证码
13
            - StripPrefix=1
14
        # 系统模块
15
        - id: ruoyi-system
16
          uri: lb://ruoyi-system
17
          predicates:
18
            - Path=/system/**
19
          filters:
20
            - StripPrefix=1
21
        # 代码生成
22
        - id: ruoyi-gen
23
          uri: lb://ruoyi-gen
24
          predicates:
25
            - Path=/code/**
26
          filters:
27
            - StripPrefix=1
28
        # 定时任务
29
        - id: ruoyi-job
30
          uri: lb://ruoyi-job
31
          predicates:
32
            - Path=/schedule/**
33
          filters:
34
            - StripPrefix=1
35
        # 文件服务
36
        - id: ruoyi-file
37
          uri: lb://ruoyi-file
38
          predicates:
39
            - Path=/file/**
40
          filters:
41
            - StripPrefix=1

展开收起

每条路由的核心就三个配置：

配置项	说明
uri: lb://服务名	转发到哪个服务。lb:// 表示从注册中心获取地址并负载均衡
predicates: Path=/**	什么样的请求路径匹配这条路由
filters: StripPrefix=1	转发前去掉第一段路径

StripPrefix 为什么要去掉？ 因为前端请求的路径带前缀（如 /auth/login），但服务端 Controller 的路径不带（如 @PostMapping("/login")）。/auth 只是网关用来区分”转发给哪个服务”的标识，转发前必须去掉，否则服务匹配不到路径会返回 404。StripPrefix 配几段取决于 Controller 的实际路径，入职后看项目里怎么配的就行。

另外注意 ruoyi-auth 路由多配了两个东西：CacheRequestFilter 和 ValidateCodeFilter。这两个就是过滤器（Filter）——请求在转发到服务之前，先经过过滤器处理。比如 ValidateCodeFilter 会在登录请求到达认证服务之前，先校验验证码是否正确，不对的话直接拦截，不用等到服务层才报错。

3）启动类

1
@SpringBootApplication
2
public class GatewayApplication {
3
    public static void main(String[] args) {
4
        SpringApplication.run(GatewayApplication.class, args);
5
    }
6
}

只要配置了 Nacos 地址，Gateway 会自动从注册中心发现服务，不需要额外写代码。

3、常见问题#

3.1 放开接口时，网关层和服务层都要放#

这是一个新人特别容易踩的坑。

很多项目中，网关层会做统一鉴权（Token 校验、权限检查等），不在白名单里的请求会被网关直接拦截，根本到不了后端服务。所以当你需要放开某个接口（比如登录、注册、公共查询等无需登录就能访问的接口）时，不能只在服务层放开，网关层也要同步放开。

举个例子：你写了一个 /system/register 注册接口，不需要登录就能访问。你在系统服务里把 Security 配置放开了，但前端调用时还是返回 401。原因是：请求先到了网关，网关的鉴权过滤器发现没有 Token，直接返回 401 了，请求根本没到你的系统服务。

1
前端请求 /system/register（没带 Token）
2
        ↓
3
网关鉴权过滤器 → 没有 Token → 直接返回 401 ❌
4
        ↓ （请求根本没到系统服务）
5
系统服务（你配的放开规则没机会生效）

正确做法：在网关的鉴权过滤器白名单中，也把这个接口加上。 比如前面示例中的 AuthGlobalFilter：

1
// 白名单路径（不需要鉴权的接口）
2
if (path.startsWith("/auth/login")
3
        || path.startsWith("/system/register")    // ← 加上需要放开的接口
4
        || path.startsWith("/file/public")) {
5
    return chain.filter(exchange);
6
}

简单记：微服务架构下，一个请求要经过网关 → 服务两道关。放开接口时两道关都要放，少放一个就会被拦住。排查 401、403 问题时，先确认是网关拦的还是服务拦的，不要只盯着服务层看。

3.2 通过接口路径定位到哪个服务处理的#

入职后经常会遇到这种情况：前端跟你说某个接口报错了，你拿到接口路径（比如 /system/user/list），但不知道这个请求最终是由哪个后端服务处理的。这时候就可以通过网关的路由规则来定位。

定位步骤：

1）找到网关的路由配置

路由配置一般在网关模块的 application.yml（或 bootstrap.yml）里，也可能在 Nacos 的网关配置中。

2）用请求路径匹配路由规则

比如接口路径是 /system/user/list，对照路由规则：匹配 Path=/system/**，对应的 uri 是 lb://ruoyi-system，所以这个接口是 ruoyi-system 处理的。

3）确认转发后的实际路径

由于配了 StripPrefix=1，转发前会去掉第一段 /system，所以 ruoyi-system 收到的请求路径是 /user/list，对应 Controller 里的 @GetMapping("/user/list")。

举几个例子：

前端请求路径	匹配的路由	转发到哪个服务	服务收到的路径
/auth/login	Path=/auth/**	ruoyi-auth	/login
/system/user/list	Path=/system/**	ruoyi-system	/user/list
/code/gen/tables	Path=/code/**	ruoyi-gen	/gen/tables
/file/upload	Path=/file/**	ruoyi-file	/upload

注意：如果请求路径没有匹配到任何路由规则，网关会直接返回 404。如果匹配到了但目标服务不可用，网关会返回 502。

常见问题排查：

接口返回 404：先确认路由规则是否匹配你的接口路径，再确认 StripPrefix 配置是否正确（比如接口实际路径是 /user/list，但 StripPrefix 多去了一段，转发后变成 /list，服务里根本匹配不到）
接口返回 502：通常表示网关调用下游服务失败，不一定是服务宕机，也可能是服务未注册、连接超时、网络异常等原因。先确认服务是否注册成功，再确认服务本身是否正常（直接调服务 IP 看看能不能通）
本地调试时可以先绕过网关：如果网关出了问题不好排查，先直接请求你自己服务的本地端口，确认接口本身没问题。服务没问题之后，再去看网关层面的问题
在浏览器控制台（F12 → Network）看到接口请求，对照路由规则就能快速定位到对应的服务

3.3 跨域处理（了解）#

前端页面直接请求多个不同地址的服务会碰到跨域问题。在微服务架构下，跨域最理想的做法是在网关层统一处理，比如在网关模块里写一个跨域过滤器（实现 WebFilter），统一设置跨域响应头，这样所有经过网关的请求都不用再单独处理。

但真实项目中，不一定都在网关层做。也有可能通过以下方式处理：

在业务服务的公共模块里统一配置：所有服务都依赖一个公共模块（如 framework、common），在公共模块里通过 CorsFilter 统一处理
在 Nginx 层处理：有些项目在 Nginx 反向代理时直接加跨域头，请求还没到网关就解决了
按需单独处理：只在需要的接口上单独配，比如通过 WebMvcConfigurer.addCorsMappings() 或在 Controller 上加 @CrossOrigin

所以入职后，遇到跨域问题先看项目里是怎么处理的，不要自己加配置，可能和已有的配置冲突。

四、锁与并发问题#

1、为什么微服务下并发问题更复杂？#

在单体项目里，如果多个线程同时操作同一份数据，可以用 Java 自带的锁（如 synchronized、ReentrantLock）来解决：

1
// 单体项目：用 synchronized 就行
2
synchronized (this) {
3
    int stock = getStock(productId);
4
    if (stock > 0) {
5
        deductStock(productId);
6
    }
7
}

但在微服务架构下，同一个服务可能会部署多个实例（多台机器），每个实例都是独立的 JVM。这时候，Java 自带的锁就只能锁住自己这台机器上的线程，其他机器上的线程完全不受影响。

1
实例 A（JVM 1）: synchronized → 只能锁住实例 A 内部的线程
2
实例 B（JVM 2）: synchronized → 只能锁住实例 B 内部的线程
3
实例 C（JVM 3）: synchronized → 只能锁住实例 C 内部的线程

也就是说，Java 自带的锁在多实例部署的情况下，起不到互斥作用。

这时候就需要分布式锁。

2、什么是分布式锁？#

分布式锁，就是让多个服务实例在操作同一份数据时，也能做到互斥。

不管是哪台机器上的线程，谁先抢到锁，谁就能执行；其他线程必须等锁释放后才能继续。

1
实例 A → 抢锁 → 成功 → 执行业务 → 释放锁
2
实例 B → 抢锁 → 失败，等待
3
实例 C → 抢锁 → 失败，等待

3、常见的分布式锁实现方式#

方式	说明
Redis 分布式锁	最常用，基于 Redis 的 SETNX 命令实现
Redisson	基于 Redis 的分布式锁框架，封装得更完善
ZooKeeper 分布式锁	基于 ZooKeeper 的临时顺序节点实现
数据库锁	通过数据库行锁或乐观锁实现，性能较低

其中，Redis + Redisson 是企业里用得最多的方案。

4、Redis 分布式锁的基本原理#

最简单的实现方式是借助 Redis 的 SETNX 命令，核心思路就三步：

抢锁：往 Redis 写一个 key，谁先写成功谁就拿到锁（SETNX = set if not exists，key 不存在才写入成功）
设过期时间：防止拿到锁的服务突然宕机，导致锁永远不释放
释放锁：业务执行完，把这个 key 删掉

下面是一个最简实现（基于 StringRedisTemplate），只有两个方法：tryLock 抢锁、unlock 释放锁：

1
@Component
2
public class SimpleRedisLock {
3

4
    @Autowired
5
    private StringRedisTemplate redisTemplate;
6

7
    /**
8
     * 尝试获取锁（不阻塞，拿不到立即返回 false）
9
     *
10
     * @param key     锁的 key，例如 "lock:job:order_report_daily"
11
     * @param expire  锁的过期时间（防止宕机后锁不释放）
12
     * @param unit    时间单位
13
     */
14
    public boolean tryLock(String key, long expire, TimeUnit unit) {
15
        // setIfAbsent 就是 SETNX：key 不存在才写入
16
        // 这里用 4 参数版本，把"设值 + 设过期时间"合成一步，保证原子性
17
        return Boolean.TRUE.equals(
18
                redisTemplate.opsForValue().setIfAbsent(key, "1", expire, unit)
19
        );
20
    }
21

22
    /** 释放锁：把 key 删掉 */
23
    public void unlock(String key) {
24
        redisTemplate.delete(key);
25
    }
26
}

展开收起

小贴士：早期写法是先 SETNX 设值、再单独 expire 设过期时间，两步之间如果服务宕机，锁就永远不释放了。现在推荐用上面这种「设值 + 过期时间一条命令完成」的 4 参数版本，从根上避免这个坑。

工作中的一个使用场景是定时任务防重复执行（多台机器都部署了同一个定时任务，但只希望其中一台真正执行）：

1
@Autowired
2
private SimpleRedisLock redisLock;
3

4
@Scheduled(cron = "30 30 0 * * ?")  // 每天 00:30:30 执行
5
public void generateDailyReport() {
6
    // 1. 抢锁，过期时间设 6 小时（只要够任务跑完就行）
7
    boolean locked = redisLock.tryLock(
8
            "lock:job:order_report_daily", 6, TimeUnit.HOURS);
9

10
    // 2. 没抢到锁，说明其他机器正在执行，本次直接跳过
11
    if (!locked) {
12
        log.info("其他实例正在执行，本次跳过");
13
        return;
14
    }
15

16
    try {
17
        // 3. 抢到了，执行业务逻辑
18
        this.reportService.generateDailyReport();
19
    } finally {
20
        // 4. 跑完后释放锁（放 finally 里，即使抛异常也能释放）
21
        redisLock.unlock("lock:job:order_report_daily");
22
    }
23
}

展开收起

注意：这种基于 SETNX 的实现比较简单，适合定时任务这种”获取失败就跳过”的场景。但对于库存扣减、订单处理这种需要等待锁释放的业务场景，一般用 Redisson。真实项目里通常不会让你从零写这套工具类，公司大概率已经有现成的封装（比如下面 Redisson 那节会提到的自定义注解）。先看项目里已有的，有的话直接用。

5、Redisson 分布式锁的基本用法#

第 4 节那套 SETNX 锁要自己处理过期时间、释放时机等一堆边界问题。而 Redisson 作为成熟的分布式锁框架，已经把这些都封装好了（比如锁续期、可重入、公平锁等），实际项目里基本都用它。

Redisson 加锁 API 速览#

Redisson 加锁常用的方法就下面几个，先有个整体印象，看后面的代码才不懵：

方法	说明
lock.lock()	阻塞等待，一直等到拿到锁为止
lock.lock(10, TimeUnit.SECONDS)	阻塞等待，但显式指定过期时间（这里是 10 秒），到点强制释放
lock.tryLock(5, 30, TimeUnit.SECONDS)	带超时返回：最多等 5 秒，拿不到就返回 false；拿到后锁 30 秒强制释放
lock.unlock()	释放锁

简单记：lock 是”抢不到就一直等”，tryLock 是”等一会儿就算了”。至于”不写过期时间会不会出问题”，下面会专门讲。

5.1 Redisson 原生写法#

下面是一个电商项目中库存锁定的真实代码，使用 Redisson 的 lock() 方法：

1
@Autowired
2
private RedissonClient redissonClient;
3

4
@Transactional(rollbackFor = Exception.class)
5
public void lockStock(List<StockLockParam> stockLockParams) {
6
    List<RLock> locks = new ArrayList<>();
7
    try {
8
        for (StockLockParam param : stockLockParams) {
9
            // 1. 按商品 SKU ID 获取锁（每个商品一把锁，粒度细）
10
            RLock lock = redissonClient.getLock("lock:stock:" + param.getSkuId());
11
            // 2. 加锁（阻塞等待，直到获取成功）
12
            lock.lock();
13
            locks.add(lock);
14

15
            // 3. 执行业务逻辑：校验库存 → 扣减库存
16
            int stock = stockService.getStock(param.getSkuId());
17
            if (stock < param.getCount()) {
18
                throw new BusinessException("库存不足");
19
            }
20
            stockService.deductStock(param.getSkuId(), param.getCount());
21
        }
22

23
        // 4. 保存库存锁定记录
24
        stockLockMapper.saveBatch(stockLockParams);
25

26
        // 5. 发送延时消息，1小时后自动解锁库存（订单超时未支付场景）
27
        mqTemplate.syncSend("stock-unlock-topic", orderIds);
28

29
    } finally {
30
        // 6. 释放所有锁（只释放当前线程持有的，避免释放别人的锁）
31
        for (RLock lock : locks) {
32
            if (lock.isHeldByCurrentThread()) {
33
                lock.unlock();
34
            }
35
        }
36
    }
37
}

展开收起

说明：这里用 lock.lock() 阻塞等待，保证一定拿到锁才继续执行。获取锁后，通过 isHeldByCurrentThread() 判断再释放，防止释放别人的锁。锁的粒度是 SKU 级别（lock:stock:{skuId}），不是整个订单，并发性能更好。

疑问：上面 lock.lock() 没有写过期时间，会不会出问题？
不会。这正是 Redisson 和手写 SETNX 锁（第 4 节那种）最大的区别——无参的 lock.lock() 会自动带过期时间，并启动”看门狗”机制自动续期：

拿到锁时，Redisson 在底层设了一个默认过期时间（默认 30 秒）

同时启动一个后台线程（看门狗），每隔 10 秒检查一次：“这个锁还被当前线程持有吗？是的话，把过期时间重新刷回 30 秒”

这样就化解了一个矛盾：业务没跑完时一直续期，不会出现”锁提前过期、别人插队”的超卖问题；而服务一旦宕机，看门狗也跟着死了，锁最多 30 秒后自动释放，不会永远卡死。
⚠️ 反直觉的坑：一旦你显式指定过期时间（比如 lock.lock(10, SECONDS) 或 tryLock(5, 30, SECONDS)），看门狗就不会启动了，锁到点强制释放，哪怕业务还没跑完。所以要么用无参 lock.lock()（靠看门狗），要么自己估算一个足够长的过期时间，别设太短。
下面是一个 tryLock 的例子，抢锁失败时还能给用户一个友好提示：
1
RLock lock = redissonClient.getLock("lock:product:" + productId);
2
try {
3
    if (lock.tryLock(5, 30, TimeUnit.SECONDS)) {   // 最多等 5 秒；拿到后锁 30 秒强制释放
4
        try {
5
            doDeductStock(productId);
6
        } finally {
7
            lock.unlock();
8
        }
9
    } else {
10
        throw new BusinessException("系统繁忙，请稍后重试");  // 抢锁失败，给用户友好提示
11
    }
12
} catch (InterruptedException e) {
13
    Thread.currentThread().interrupt();
14
}

5.2 实际项目中的封装方式#

在实际开发中，公司一般会把 Redisson 封装成自定义注解，你不会直接写上面的代码。最常见的封装方式是「自定义注解 + AOP」：通过注解声明锁，AOP 切面自动处理加锁和解锁，业务代码完全不感知锁的存在。以下是某项目的真实封装：

1
// 注解定义
2
@Target({ElementType.METHOD})
3
@Retention(RetentionPolicy.RUNTIME)
4
public @interface RedissonLock {
5
    /** 锁的 key，支持 SpEL 表达式，例如：keys = {"#orderId"} */
6
    String[] keys();
7
    /** key 前缀，默认用「类名:方法名」 */
8
    String prefix() default "";
9
    /** 锁超时时间（毫秒），默认 30000ms */
10
    long lockTimeout() default 0;
11
    /** 等待加锁超时时间（毫秒），0 表示不等待 */
12
    long waitTimeout() default 0;
13
}

1
// AOP 切面实现（核心逻辑）
2
@Aspect
3
@Component
4
public class RedissonLockAspect {
5

6
    private final RedissonClient redissonClient;
7

8
    @Around("@annotation(RedissonLock)")
9
    public Object around(ProceedingJoinPoint joinPoint) {
10
        Method targetMethod = ((MethodSignature) joinPoint.getSignature()).getMethod();
11
        RedissonLock annotation = targetMethod.getAnnotation(RedissonLock.class);
12

13
        // 1. 通过 SpEL 解析锁的 key（例如从参数中取 orderId）
14
        String lockKey = getLockKey(annotation.keys(), targetMethod, joinPoint.getArgs());
15
        String keyPrefix = targetMethod.getDeclaringClass().getName()
16
                         + ":" + targetMethod.getName();
17

18
        // 2. 获取锁
19
        RLock lock = redissonClient.getLock("lock:" + keyPrefix + ":" + lockKey);
20
        boolean lockFlag = false;
21
        Object proceed = null;
22
        try {
23
            // 3. 尝试加锁（带超时）
24
            lockFlag = lock.tryLock(annotation.waitTimeout(),
25
                                    annotation.lockTimeout(), TimeUnit.MILLISECONDS);
26
            if (lockFlag) {
27
                // 4. 获取成功，执行业务方法
28
                proceed = joinPoint.proceed();
29
            }
30
        } finally {
31
            if (lockFlag && lock.isHeldByCurrentThread()) {
32
                lock.unlock();
33
            }
34
        }
35
        // 5. 获取失败，抛异常（防重复提交）
36
        if (proceed == null) {
37
            throw new BusinessException("操作过于频繁，请稍后重试");
38
        }
39
        return proceed;
40
    }
41
}

展开收起

使用时只需加一个注解：

1
@RedissonLock(keys = {"#orderId"}, waitTimeout = 5000, lockTimeout = 30000)
2
public void processOrder(String orderId) {
3
    // 业务逻辑，自动被分布式锁保护
4
}

6、分布式锁使用时的注意事项#

1）锁的粒度要合理

锁的范围要尽量小，只锁住真正需要互斥的操作。比如：

不要锁整个方法，只锁住操作共享资源的代码块
锁的 key 要精确到具体的业务对象，比如 lock:order:123 而不是 lock:order

2）一定要设置过期时间

防止服务宕机后锁一直不释放，导致其他服务永远获取不到锁。

3）释放锁一定要放在 finally 里

保证即使业务代码抛异常，锁也能正常释放。

4）获取锁失败时要处理

获取锁失败，说明有其他线程在操作，不能直接忽略。要么返回提示信息让用户重试，要么走其他逻辑。

五、事务如何解决#

1、微服务下的事务问题#

在单体项目里，事务很好处理，一个 @Transactional 注解就能搞定：

1
// 单体项目：一个事务搞定
2
@Transactional
3
public void createOrder(Order order) {
4
    orderMapper.insert(order);           // 写订单表
5
    orderItemMapper.batchInsert(items);   // 写订单明细表
6
    productMapper.deductStock(productId); // 扣库存
7
}

但在微服务架构下，这些操作可能分布在不同服务中：

1
创建订单 → 订单服务（写订单表、订单明细表）
2
扣库存   → 商品服务（扣商品库存）

这时候，@Transactional 只能保证订单服务自己数据库的事务，商品服务那边出了问题，订单服务是管不了的：

这就是分布式事务问题。

2、解决分布式事务的常见思路#

分布式事务没有完美解决方案，只有在一致性和性能之间做取舍。

常见的思路有：

方案	说明	一致性
2PC（两阶段提交）	准备阶段 + 提交阶段，所有参与者都成功才提交	强一致
TCC	Try-Confirm-Cancel，手动编写三个阶段的逻辑（Seata 支持此模式，详见 4.5）	最终一致
消息事务	通过消息队列保证最终一致性	最终一致
Seata	阿里开源的分布式事务框架，支持多种模式	看选用的模式

3、先搞清楚：大多数业务不需要强一致性#

这是新人特别容易纠结的一个点。

很多新人一听到”分布式事务”，就觉得必须保证所有服务的数据实时一致。但实际上，大部分业务场景只需要最终一致性就够了。而且很多互联网业务项目并不会引入 Seata，而是采用本地事务 + MQ + 补偿机制实现最终一致性；只有一致性要求较高或业务复杂的场景，才可能采用 Seata、TCC 等方案。

什么叫最终一致性？

不要求所有服务的数据在同一时刻完全一致，但经过一段时间后，数据最终会变成一致的。

比如下单场景：

用户下单后，订单先创建成功
过一会儿，库存扣减成功
如果库存扣减失败，再把订单取消掉

用户看到的可能有一小段时间的”不一致”，但最终数据是对的。

哪些场景需要强一致性？

转账、支付等金融场景（钱必须实时一致，不能有中间态）

哪些场景只需要最终一致性？

大部分订单、库存、物流类业务
通知、消息类业务
积分、优惠券等

关于库存的一个常见疑问：库存不是怕超卖吗，为什么也算最终一致性？因为防止超卖靠的是「分布式锁 + 原子扣减」（上一章讲过的 lock:stock:{skuId}），而不是靠分布式事务——锁保证同一时刻只有一个请求在扣库存，扣减成功后通过 MQ 通知其他服务即可。
这两个概念新人特别容易混，一定要分清：分布式事务解决的是「跨服务数据一致性」问题（A 服务成功了，B 服务也要成功）；分布式锁解决的是「并发竞争」问题（同一时刻只有一个线程能操作）。两者关注点不同，不要混为一谈。

4、实际开发中最常见的处理方式#

说实话，很多中小型公司的微服务项目，并不一定会引入完整的分布式事务框架，甚至有些公司压根不会对分布式事务做系统性处理——出了数据不一致就人工修。原因很简单：发生事务不一致的概率本身就很低（网络正常、服务不宕机的绝大部分时间里，数据都是一致的），如果业务本身能容忍这个极低概率的不一致，那加一堆补偿逻辑、消息表、分布式事务框架反而增加了系统复杂度，得不偿失。能简单解决的问题就不要用复杂方案，这是 KISS 原则。

4.1 本地事务 + 普通消息（最常用，但有隐患）#

这是企业里用得最多的一种方式。注意这里用的是 MQ 的「普通消息」，不是「事务消息」，所以会有一个先天的隐患，下面会专门讲。

实现思路：

代码示例（以 RocketMQ 为例）：

1）订单服务（生产者）——创建订单后发送扣库存消息

1
@Service
2
public class OrderServiceImpl implements OrderService {
3

4
    @Autowired
5
    private OrderMapper orderMapper;
6
    @Autowired
7
    private RocketMQTemplate rocketMQTemplate;
8

9
    @Transactional
10
    public void createOrder(Order order) {
11
        // 1. 写订单表（本地事务）
12
        orderMapper.insert(order);
13

14
        // 2. 发送消息到 MQ，通知商品服务扣库存
15
        StockMessage msg = new StockMessage();
16
        msg.setOrderId(order.getId());         // 带上订单 ID，消费端用于幂等校验和取消订单
17
        msg.setProductId(order.getProductId());
18
        msg.setQuantity(order.getQuantity());
19
        rocketMQTemplate.convertAndSend("topic-stock-deduct", msg);
20

21

22
        //其他业务逻辑
23
    }
24
}

展开收起

2）商品服务（消费者）——收到消息后扣库存

1
@Component
2
@RocketMQMessageListener(
3
    topic = "topic-stock-deduct",           // 监听哪个 topic（和生产者发送时的 topic 一致）
4
    consumerGroup = "product-service-group" // 消费者组名：同一组内只有一台机器消费这条消息，避免重复消费
5
)
6
public class StockConsumer implements RocketMQListener<StockMessage> {
7

8
    @Autowired
9
    private ProductMapper productMapper;
10
    @Autowired
11
    private OrderClient orderClient;       // 回调订单服务，用于取消订单
12
    @Autowired
13
    private StringRedisTemplate redisTemplate;
14

15
    @Override
16
    public void onMessage(StockMessage msg) {
17
        // 【幂等校验】防止 MQ 重复投递导致库存被多扣
18
        // MQ 保证「至少一次」投递，不保证「恰好一次」，所以消费端必须自己做幂等
19
        String lockKey = "mq:stock:deducted:" + msg.getOrderId();
20
        Boolean alreadyDeducted = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", 24, TimeUnit.HOURS);
21
        if (!Boolean.TRUE.equals(alreadyDeducted)) {
22
            log.info("订单{}已扣过库存，跳过重复消息", msg.getOrderId());
23
            return;  // 已处理过，直接返回
24
        }
25

26
        try {
27
            // 扣库存（SQL 里带 stock > 0 条件，原子操作防超卖）
28
            int rows = productMapper.deductStock(msg.getProductId(), msg.getQuantity());
29
            if (rows == 0) {
30
                // 库存不足是「业务异常」，不能靠 MQ 重试解决（重试再多库存还是不够）
31
                // 正确做法：走业务补偿 —— 通知订单服务取消这张订单
32
                redisTemplate.delete(lockKey);  // 清除标记，允许后续如果用户重新下单时能正常处理
33
                orderClient.cancelOrder(msg.getOrderId(), "库存不足");
34
                return;   // 正常返回，消息消费成功，不再重试
35
            }
36
        } catch (Exception e) {
37
            // 扣库存过程中发生异常（如数据库超时），清除幂等标记
38
            // 让 MQ 重试时能重新进入，否则 key 会把重试全部挡住
39
            redisTemplate.delete(lockKey);
40
            throw e;  // 抛出异常，触发 MQ 重试
41
        }
42
    }
43
}

展开收起

3）消息体定义

1
@Data
2
@AllArgsConstructor
3
@NoArgsConstructor
4
public class StockMessage implements Serializable {
5
    private Long orderId;      // 订单 ID（用于幂等校验 + 取消订单）
6
    private Long productId;
7
    private Integer quantity;
8
}

⚠️ 必须知道的隐患：上面这段代码有一个经典坑——@Transactional 方法里直接调用 rocketMQTemplate.convertAndSend() 发消息。如果消息发出之后，本地事务因为后续代码抛异常而回滚了，会出现：本地数据没写入，但 MQ 消息已经发出去并被下游消费了，导致数据不一致。
关于消费端的幂等：MQ 默认会重试，所以消费端要做幂等处理（比如通过消息 ID 或业务 ID 去重），防止重复消费导致库存多扣。多次重试仍失败的消息会进入死信队列，需要人工介入。

优点：实现简单，服务间解耦缺点：有上述”事务回滚但消息已发”的隐患；属于最终一致性，有少量延迟

4.2 本地消息表 + MQ（推荐）#

上面的方案有一个隐患：本地事务和消息发送不在同一个原子操作中。本地消息表就是用来解决这个问题的。

思路：不直接发 MQ 消息，而是先在本地数据库里写一条消息记录，和业务数据在同一个事务中，然后由定时任务扫描并发送。

流程：

1）消息表结构（参考）

1
CREATE TABLE local_message (
2
    id          BIGINT PRIMARY KEY AUTO_INCREMENT,
3
    topic       VARCHAR(100)    COMMENT 'MQ topic',
4
    content     TEXT            COMMENT '消息内容（JSON）',
5
    status      TINYINT         COMMENT '0-待发送 1-已发送 2-发送失败',
6
    retry_count INT DEFAULT 0   COMMENT '重试次数',
7
    create_time DATETIME        COMMENT '创建时间',
8
    INDEX idx_status (status)
9
);

2）订单服务——在本地事务中同时写入业务数据和消息记录

1
@Service
2
public class OrderServiceImpl implements OrderService {
3

4
    @Autowired
5
    private OrderMapper orderMapper;
6
    @Autowired
7
    private MessageMapper messageMapper;
8

9
    @Transactional
10
    public void createOrder(Order order) {
11
        // 1. 写订单表（本地事务）
12
        orderMapper.insert(order);
13

14
        // 2. 写消息表（和业务数据在同一个事务中，保证原子性）
15
        LocalMessage message = new LocalMessage();
16
        message.setTopic("topic-stock-deduct");
17
        message.setContent(JSON.toJSONString(
18
            new StockMessage(order.getId(), order.getProductId(), order.getQuantity())));
19
        message.setStatus(0);  // 0-待发送
20
        messageMapper.insert(message);
21
    }
22
}

展开收起

3）定时任务——扫描消息表并发送

1
@Component
2
public class MessageScheduler {
3

4
    @Autowired
5
    private MessageMapper messageMapper;
6
    @Autowired
7
    private RocketMQTemplate rocketMQTemplate;
8

9
    @Scheduled(fixedRate = 5000)  // 每 5 秒扫描一次
10
    public void sendPendingMessages() {
11
        // 查询条件：status != 1（未成功的）且 retry_count <= 5（没超过重试上限）
12
        // 这样 status=0（待发送）和 status=2（之前发送失败）的消息都会被查出来重试
13
        List<LocalMessage> messages = messageMapper.selectPendingAndFailed(5);
14
        for (LocalMessage msg : messages) {
15
            try {
16
                rocketMQTemplate.convertAndSend(msg.getTopic(), msg.getContent());
17
                msg.setStatus(1);  // 1-已发送
18
                messageMapper.updateById(msg);
19
            } catch (Exception e) {
20
                msg.setRetryCount(msg.getRetryCount() + 1);
21
                msg.setStatus(2);  // 标记为失败
22
                // 查询条件是 status != 1 AND retry_count <= 5
23
                // retryCount <= 5 的消息下次扫描依然会被查出来重试
24
                // retryCount > 5 的消息不会再被查出，留给人工处理
25
                messageMapper.updateById(msg);
26
                log.warn("消息发送失败，id={}，重试次数={}", msg.getId(), msg.getRetryCount());
27
            }
28
        }
29
    }
30
}

展开收起

一句话总结：把”发消息”这个不可靠动作，变成”写本地数据库”这个可靠动作，和业务操作绑在同一个事务里，再由定时任务异步发送、失败重试。这是实际项目中最稳妥的最终一致性方案。
优点：解决了 4.1 的隐患，本地数据与消息严格原子一致缺点：要额外建一张消息表、配一个定时任务，有少量延迟

4.3 RocketMQ 事务消息（推荐）#

本地消息表虽然可靠，但要额外建表 + 定时任务，有点重。RocketMQ 本身提供了事务消息机制，可以不建表就解决 4.1 的隐患。

原理：

和本地消息表（4.2）的对比：

	本地消息表（4.2）	事务消息（4.3）
可靠性	✅ 可靠	✅ 可靠
需要额外建表	✅ 需要	❌ 不需要
需要定时任务	✅ 需要	❌ 不需要
实现复杂度	中等	较低（RocketMQ 原生支持）
依赖	无特殊依赖	依赖 RocketMQ

代码示例：

1
@Service
2
public class OrderServiceImpl implements OrderService {
3

4
    @Autowired
5
    private RocketMQTemplate rocketMQTemplate;
6

7
    public void createOrder(Order order) {
8
        // 1. 发送半消息（此时消费者还收不到）
9
        //    发完后 RocketMQ 会自动回调 OrderTransactionListener.executeLocalTransaction()
10
        //    写订单表的操作在那个回调方法里执行，不在这里
11
        rocketMQTemplate.sendMessageInTransaction(
12
            "tx-order-group",           // 事务消息生产者组
13
            "topic-stock-deduct",       // 目标 topic
14
            MessageBuilder.withPayload(
15
                new StockMessage(order.getId(), order.getProductId(), order.getQuantity())
16
            ).build(),
17
            order                       // 传递给本地事务的参数
18
        );
19
    }
20
}

展开收起

1
// 2. 事务监听器：执行本地事务 + 处理回查
2
@RocketMQTransactionListener(txProducerGroup = "tx-order-group")
3
public class OrderTransactionListener implements RocketMQLocalTransactionListener {
4

5
    @Autowired
6
    private OrderMapper orderMapper;
7

8
    @Override
9
    public RocketMQLocalTransactionState executeLocalTransaction(Message msg, Object arg) {
10
        try {
11
            Order order = (Order) arg;
12
            orderMapper.insert(order);   // 执行本地事务：写订单表
13
            return RocketMQLocalTransactionState.COMMIT;    // 成功 → 通知 Broker 投递消息
14
        } catch (Exception e) {
15
            return RocketMQLocalTransactionState.ROLLBACK;  // 失败 → 通知 Broker 丢弃消息
16
        }
17
    }
18

19
    @Override
20
    public RocketMQLocalTransactionState checkLocalTransaction(Message msg) {
21
        // 回查逻辑：Broker 主动来问"本地事务到底成功没有"
22
        // 从消息体中取出 orderId，查数据库确认订单是否已写入
23
        StockMessage stockMsg = JSON.parseObject(new String((byte[]) msg.getPayload()), StockMessage.class);
24
        Order order = orderMapper.selectById(stockMsg.getOrderId());
25
        if (order != null) {
26
            return RocketMQLocalTransactionState.COMMIT;    // 订单存在 → 提交
27
        }
28
        return RocketMQLocalTransactionState.ROLLBACK;      // 订单不存在 → 回滚
29
    }
30
}

展开收起

一句话总结：先发半消息 → 执行本地事务 → 根据结果 commit/rollback → 万一没响应 Broker 会回查。不需要建消息表和定时任务，是4.1 隐患的最优解。
注意：事务消息需要 RocketMQ 4.3+ 版本支持。消费端的幂等处理和 4.1 一样，不能省。

4.4 本地事务 + 补偿机制#

如果不想用 MQ，也可以在业务代码里手动处理补偿。

为什么不用 @Transactional 直接回滚？ 因为 productClient.deductStock() 是远程调用，如果放在 @Transactional 里，数据库连接会在整个远程调用期间被占用（可能 3~5 秒），高并发下连接池会被打爆，整个服务都不可用。所以这里先提交本地事务、释放连接，再调远程服务，失败了手动补偿。

思路：

先执行主业务逻辑
再调用其他服务
如果调用失败，手动回滚主业务的数据

1
public void createOrder(Order order) {
2
    // 1. 先创建订单（本地事务）
3
    orderMapper.insert(order);
4

5
    // 2. 调用商品服务扣库存
6
    try {
7
        productClient.deductStock(order.getProductId(), order.getQuantity());
8
    } catch (Exception e) {
9
        // 扣库存失败，回滚本地订单
10
        orderMapper.deleteById(order.getId());
11
        throw new BusinessException("创建订单失败");
12
    }
13
}

优点：简单直接

缺点：补偿逻辑需要自己写，如果涉及多个服务的调用，补偿代码会比较复杂

⚠️ 补偿机制的真实难度：上面的例子只涉及”调一个服务、回滚一步”，看起来很简单。但实际业务中，一个方法可能调三四个远程服务（扣库存 + 扣积分 + 发优惠券），失败时要逆序补偿每一步，代码很容易写漏。而且补偿本身也可能失败（比如 deleteById 网络超时），这时候数据照样不一致。所以需要可靠补偿的场景，优先用上面 4.2 的消息表方案，而不是手写补偿逻辑。

4.5 使用 Seata 框架#

如果你们公司已经引入了 Seata，那就可以直接用。Seata 支持多种模式：

模式	说明
AT 模式	最常用，自动管理全局事务和回滚，对业务代码侵入最小
TCC 模式	需要手动编写 Try / Confirm / Cancel 三个阶段的逻辑
Saga 模式	长事务解决方案，通过正向操作和补偿操作来管理事务
XA 模式	基于数据库 XA 协议的强一致方案，性能较低，适合对一致性要求极高的场景

其中，AT 模式用得最多，因为它基本不需要改业务代码，只需要加一个注解：

1
@GlobalTransactional
2
public void createOrder(Order order) {
3
    orderMapper.insert(order);                              // 本地事务：写订单表
4
    productClient.deductStock(order.getProductId());        // 远程调用 1：扣库存
5
    pointClient.deductPoints(order.getUserId(), 100);       // 远程调用 2：扣积分
6
    // 任何一步失败，以上操作全部自动回滚
7
}

加了 @GlobalTransactional 注解后，Seata 会自动管理整个分布式事务，任何一步失败都会自动回滚——包括本地事务和所有远程调用。

注意：Seata 用起来方便，但要额外部署 Server 端、增加运维成本，AT 模式对数据库性能也有一定影响。如前所述，很多互联网业务项目更倾向用本地事务 + MQ + 补偿的方案来实现最终一致性。只有当业务对一致性要求较高、或涉及多步复杂远程调用时，才值得引入 Seata。

六、善用 AI 辅助开发#

前面五章讲了微服务开发的各个核心知识点——从配置中心、注册中心，到远程调用、网关、分布式锁、分布式事务。内容不少，对于刚接触微服务的新人来说，不可能一次性全部记住，也不需要全部记住。

实际开发中，更高效的方式是：先把整体概念理清楚，知道每个技术点是干什么的、大概怎么用。具体细节和配置写法，用到的时候再查。 遇到不确定的问题，可以直接问 AI。

像 Claude Code 这样的 AI 编程工具，可以直接打开你的项目目录，自动读取所有代码和配置文件，然后用自然语言向它提问。不需要你手动复制粘贴代码，也不需要自己一行一行去翻。

微服务开发过程中，遇到不确定的问题可以直接问：

“这个项目的注册中心和配置中心是怎么配的？”
“这个项目的远程调用方式是什么？OpenFeign 还是 Dubbo？”
“这个项目的网关路由规则是怎么配的？”
“我要新增一个远程调用接口，参考哪个现有代码来写？”
“这个分布式锁的用法对不对？有没有什么边界问题？”
“服务注册不上 Nacos，可能是什么原因？”
“远程调用报找不到服务，帮我排查一下”
“配置改了但没生效，可能是什么原因？”

核心思路：遇到不确定的问题，先问 AI。AI 能解决的就不用打扰同事了；AI 解决不了的，你已经对问题有了基本概念，带着这个基础再去问同事，沟通效率会高很多，同事也不需要从零给你解释，同时也会觉得你是有思考过的。

项目爆红怎么办

Sat, 01 Aug 2026 00:00:00 GMT

项目爆红问题排查

刚拉下公司项目代码，满怀期待地用 IDEA 打开，结果映入眼帘的是漫山遍野的红色报错……先别慌！深呼吸！

这几乎是每个开发者都会经历的“下马威”。通常情况下，代码本身并没有错，绝大多数的“爆红”都是因为本地环境配置、构建工具或缓存同步出现了偏差。

按照以下四个维度的排查清单按图索骥，帮你快速将项目“由红转绿”。

一、JDK 版本不匹配#

很多时候，项目的地基没打对。如果 IDEA 使用的 JDK 版本和项目实际要求的版本不一致，就会出现大量的基本语法报错。

排查动作：统一全局 JDK 配置 请依次检查以下两个地方，确保版本号（如 JDK 8、JDK 11 等）与项目要求完全一致：
1. 项目结构设置： 菜单栏 File -> Project Structure -> 检查 Project SDK 和 Modules SDK。
2. 编译器设置： 菜单栏 File -> Settings -> Build, Execution, Deployment -> Compiler -> Java Compiler -> 检查 Target bytecode version。

二、项目构建异常 (Maven/Gradle)#

依赖管理工具（Maven/Gradle）的状态异常，是导致项目爆红的“重灾区”。请按顺序检查：

1. 构建配置文件未被识别#

现象： pom.xml 或 build.gradle 文件图标显示为普通的文本/XML图标，没有对应的官方 Logo。
解决： 右键点击该文件，选择 Add as Maven Project（或 Gradle 对应选项），强制 IDEA 重新解析构建脚本。

2. 目录资源标识丢失#

现象： java 文件夹不是蓝色的，resources 文件夹没有带有金条图标。
解决： 右键对应的目录 -> Mark Directory as -> 将 java 标记为 Sources Root，将 resources 标记为 Resources Root。

3. 构建存在旧缓存#

现象： 依赖明明都配置了，但依然飘红。
解决： 构建工具可能卡在旧缓存里了。执行 clean 命令清除历史，再重新构建（例如在 Maven 面板双击运行 clean，然后运行 install 或 compile）。

4. 依赖未正确加载（重点！）#

这是最常见的情况，需要分情况讨论：

情形 A：Jar 包在公司的 Maven 私仓里
- 排查 1： 你的 IDEA 是否配置了正确的 settings.xml？（里面需要包含公司的私服地址和镜像配置）。
- 排查 2： 去私仓后台看一眼，包确实存在，但版本号对得上吗？（特别是 SNAPSHOT 快照版本，可能没有拉取到最新）。
情形 B：Jar 包不在 Maven 私仓里
- 本地依赖： 包可能直接扔在项目的 lib 目录下了，需要手动添加本地依赖（通过 pom 的 scope=system 引入）。
- 模块依赖： 这个 Jar 包其实是公司另一个基础模块的源码。你需要先找到那个模块，在本地跑一遍 mvn clean install，把它装到你自己的本地仓库里。

5. Lombok 插件“罢工”#

现象： 实体类上明明加了 @Data 等注解，但其他类调用 get/set 方法时依然报错找不到。
解决：
1. 检查 IDEA 的 Lombok 插件版本，确保与项目依赖中的 Lombok 版本兼容，必要时更新插件。
2. 在 IDEA 的 Settings -> Build, Execution, Deployment -> Compiler -> Shared build process VM options 中添加参数：-Djps.track.ap.dependencies=false。

三、IDEA 缓存错乱#

IDEA 为了让你搜索和跳转更丝滑，会在后台建立海量索引。一旦这些索引文件损坏，就会出现“薛定谔的报错”（代码没问题，运行也正常，但就是满屏红线）。

终极杀招：清除 IDEA 缓存
1. 点击顶部菜单栏 File -> Invalidate Caches...
2. 在弹出的对话框中，将前四个选项全部勾选（包括 Clear file system cache and Local History 等）。
3. 点击 Invalidate and Restart，耐心等待 IDEA 重启并重新建立索引。

四、代码真有问题（语法或同步缺失）#

如果经历了上面三步的洗礼，依然有零星报错，那很可能是代码层面真的少东西了。

排查动作：确认是否有人“漏交”代码
- 现象： 提示缺少某个类、或是某个类里缺少刚刚调用的新方法。
- 解决： 看看 Git 提交记录，最近是不是有同事刚推过代码？大概率是这位同事在 Commit 时漏选了某些新增的类文件。这时候不用怀疑自己，大胆去群里艾特对应同事补充提交代码即可。

💡 总结排查口诀： 遇到爆红莫心慌，排查顺序记心上：一查 JDK 环境，二看 Maven 依赖，三清 IDEA 缓存，最后核对 Git 同步。

项目本地启动失败该怎么办

Sat, 01 Aug 2026 00:00:00 GMT

项目克隆下来之后，下一步就是尝试在本地启动项目。如果启动失败了，不要慌，大部分启动失败都是有明确原因的，关键是要学会看错误信息。

启动前要确认的信息#

在尝试启动项目之前，先确认以下基础信息是否正确：

1、JDK 版本是否设置正确#

检查 IDEA 中 Project SDK 是否与项目要求的 JDK 版本一致。

如果不一致，可以在 File → Project Structure → Project SDK 中修改。

2、是否使用正确的方式启动#

SpringBoot 项目不一定就是直接运行启动类来启动。

如何判断：

如果启动类继承了 SpringBootServletInitializer 类，说明这个项目采用的是外置容器（如 Tomcat）的部署方式，不是通过内嵌容器直接启动的：

1
@SpringBootApplication
2
public class YourApplication extends SpringBootServletInitializer {
3
    @Override
4
    protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
5
        return application.sources(YourApplication.class);
6
    }
7

8
    // 可选：保留 main 方法，便于本地用内嵌容器直接运行测试
9
    public static void main(String[] args) {
10
        SpringApplication.run(YourApplication.class, args);
11
    }
12
}

这种情况，需要先配置外置容器（如配置 Tomcat），然后通过容器来启动项目。

如果不确定项目应该怎么启动，直接问同事。

3、多配置文件，确保使用正确的配置文件启动#

很多项目有多个环境配置文件，比如：

application-dev.yml：开发环境
application-prod.yml：生产环境

确保你激活的是本地开发环境的配置。如果用错了配置文件，可能会连接到错误的数据库或中间件。

4、项目启动需要使用的中间件，确保本地网络可以访问#

项目启动可能依赖以下中间件，确保它们已经启动并且网络可达：

MySQL
Redis
RabbitMQ / Kafka
Elasticsearch
Nacos / 注册中心

启动失败的关键：看控制台错误信息#

启动失败，关键就是要看控制台错误信息！

如果看不懂错误信息，可以把错误信息交给 AI 进行分析。

要多关注报错信息里面的 Caused by 信息！ Caused by 后面的内容，才是导致问题的根本原因。

常见启动错误及解决方式#

1、拒绝连接#

1
Connection refused
2
java.net.ConnectException: Connection refused

原因： 本地无法连接到目标服务（比如数据库、Redis、中间件等）。

排查方式：

使用 telnet 命令检测具体的 IP 和端口是否通畅：

1
telnet <IP> <端口>

如果 telnet 不通，说明目标服务没有启动，或者网络不通。

2、类找不到#

1
ClassNotFoundException
2
NoClassDefFoundError
3
java.lang.NoSuchMethodError

原因： 明明存在这个类，但运行时却说找不到，基本就是缓存问题。

解决方式：

清除 IDEA 缓存并重启（File → Invalidate Caches → Invalidate and Restart）
在 Maven 面板中 clean 整个工程
再 install 整个工程

3、端口被占用#

1
Web server failed to start. Port XXXX was already in use.

原因： 项目要使用的端口已经被其他程序占用了。

解决方式：

使用如下命令查看端口是否被占用：

1
netstat -ano | findstr :8080

找到占用端口的进程 PID 后，可以使用以下命令结束进程：

1
taskkill /PID <进程ID> /F

或者直接在 IDEA 的启动配置中把端口号改成其他未被占用的端口。

4、配置属性错误#

1
ConfigurationPropertiesBindException
2
IllegalArgumentException: Could not resolve placeholder 'xxx' in value "${xxx}"

原因： 配置文件中的属性值格式错误、类型不匹配或引用了一个不存在的属性。

排查方式：

检查 application.yml 或 application.properties 中对应的配置项，确认属性名是否正确、值是否符合要求。

写不出代码怎么办

Sat, 01 Aug 2026 00:00:00 GMT

一、为什么写不出代码？#

新人写不出代码，归根结底只有两个原因。第一个，也是最常见：需求没理解。

为什么这一条排第一？因为代码是为业务服务的，脱离了业务，代码就毫无意义——你写什么样的代码，取决于需求是什么。 需求都不明确，你要写什么代码自然也不明确，写不出来才是正常的。

但偏偏这一步，是新人最容易跳过的，常见两种情况：

一种是看两眼文档，觉得“大概懂了”，立马开始写，结果写两行就卡住——因为你根本没真正理解，只是感觉自己理解了。

另一种更常见：其实没看懂，但不好意思问。怕导师觉得你菜、怕问出来显得自己笨，就硬撑着、对着文档发呆。结果时间白白耗掉，需求还是一团雾水。

记住：问需求不丢人，做出来的东西完全跑偏才丢人。导师宁愿你花十分钟问清楚，也不想看你憋两天交一坨错的东西。

真正理解一个需求，至少要能答出这几个问题：

这个功能干什么？ 最终实现什么效果？
谁在用？ 运营、管理员、还是普通用户？
输入是什么？ 前端传什么参数？
输出是什么？ 返回什么数据、页面展示什么？
正常流程是什么？ 请求进来后会发生什么？
异常情况怎么处理？ 参数为空、查不到数据、用户被禁用……

举个具体的例子，比如需求是根据用户 ID 查询订单列表，你得能答出：

干什么：传一个用户 ID，查出这个用户的所有订单
谁在用：后台运营人员，在管理页面查某个客户的订单
输入：userId、pageNum、pageSize（要分页）
输出：订单编号、金额、下单时间、订单状态
正常流程：校验参数 → 查库 → 返回分页列表
异常情况：userId 为空、查不到订单、用户被禁用

能这样答出来，才算真正理解了需求。只要有一个答不上来，那就不是”不会写代码”，而是根本不知道要写什么代码。这时候硬写没意义，正确做法是：

再看一遍需求文档和原型图
把不确定的地方记下来
找产品或导师确认

二、需求理解了，为什么还是写不出？#

因为你不会拆分问题。

新人最容易犯的错，就是脑子里装着一整个功能（比如”做一个订单查询接口”），然后开始发呆——因为这问题太大，大到不知道从哪下手。

这时候要做的不是继续想，而是拆，拆到自己会为止。

三、不会写，就继续拆#

假设需求是”根据用户 ID 查询订单列表”，怎么拆？要分两种情况：

情况一：项目里有高度相似的功能（最常见）

大部分需求，项目里都有”长得像”的现成功能。这时别自己设计，直接找最像的那个，照它的结构拆：

它有 Controller，你就建一个 Controller
它有 Service，你就建一个 Service
它的入参叫 XxxQueryReq，你的就叫 OrderQueryReq
它的方法叫 pageList，你的也叫 pageList，只改里面的表名和字段

照着抄结构，只改业务细节——这是真实开发里最常用、也最靠谱的拆法。

情况二：没有高度相似的功能，只能参考分层骨架

这种情况少，但会遇到（比如做一个全新模块）。这时候虽然没有”像”的功能可以照抄，但分层骨架和命名规范永远能参考——整个项目都在用 Controller→Service→Mapper 这套结构，DTO/VO 也是统一的命名。你就照这个骨架，把功能拆成一个个能动手的动作：

建接口：新建 Controller——会吧？
定入参：定义 Query 对象，放 userId、pageNum、pageSize——会吧？
定返回：定义 OrderVO——会吧？
写 Service：定义查询方法——会吧？
写 Mapper：写数据库查询——会吧？
返回结果：DO 转 VO——每一步，都是你已经会的。

无论哪种情况，结论都一样：原来不会的是”做订单查询接口”这个大问题，拆开以后每一步你都会。所以不是你不会，是你没拆到足够细。

如果拆出来的小问题你还不会，那就继续拆——一直拆到”新建一个类、写一个方法、定义一个字段”这种粒度，你就一定能动手。

四、真实开发中的万能流程#

写不出代码该怎么办

看起来步骤不少，其实就是下面四步的细化。以后拿到需求，按这个顺序走：

第一步：看需求 —— 搞清楚做什么、给谁用、输入什么、输出什么。（这一步过了，你才知道要拆什么。）

第二步：按上面的拆法，把结构搭出来 —— 有高度相似的，照抄结构改字段；没有的，按项目的分层骨架和命名规范来。无论哪种，先有结构，再谈逻辑。

第三步：搭空架子 —— 不管结构是怎么来的，都先把三层空壳搭好、把链路跑通，再往里填逻辑：

1
// Controller：先把接口和入参出参定下来，方法体先空着
2
@PostMapping("/pageList")
3
public Result<List<OrderVO>> pageList(@RequestBody OrderQueryReq req) {
4
    return Result.success(Collections.emptyList());
5
}

1
// Service：先写空实现，确认链路通
2
public List<OrderVO> pageList(OrderQueryReq req) {
3
    return Collections.emptyList();
4
}

先用 Postman 跑通（请求能进、能返回），再回头填业务逻辑。

第四步：一层层补逻辑 —— 不要一次写完，每完成一步就测一步：

第一轮：接口能调通
第二轮：参数能接到
第三轮：SQL 能查出数据
第四轮：自测

这样出问题时，你只需要检查刚刚改过的那部分代码。

五、不会的时候，该问谁？#

到底问 AI 还是问同事？判断标准就一句话：换家公司还存在吗？

存在 → 问 AI。 比如 Stream 怎么转 Map、MyBatis 动态 SQL 加循环条件怎么加、Spring 事务怎么用等。这些是通用知识，问 AI 效率最高——而且最好保证它告诉你的东西，你下次能用上：就算记不住具体怎么写，至少得记住”有这么个东西，下次遇到能想到它”。

不存在 → 问同事。 比如 status=3 代表什么、为什么必须调用户中心接口、为什么不能直接查库、这表为什么这么设计。这些是项目特有的东西，AI 根本不知道。

但有一点必须强调：问 AI 是为了学，不是为了代劳。 尤其是新人，千万别图省事把整个功能甩给 AI 让它直接生成。问题要自己拆、骨架要自己搭、逻辑要自己写，AI 只在你卡在某个具体小问题上时给个提示。能自己动手的尽量自己动手。等你把基本功练扎实、有了独立写代码的底气之后，再让 AI 来写、你来监工。

六、一个重要的认知#

很多新人迟迟不敢动手，不是因为不会，而是想一步写出完美代码——怕命名不规范、怕方法拆得不优雅、怕被导师喷。

但真实开发不是这样。哪怕工作五六年的程序员，拿到需求也是先写出能跑的版本，再优化。

能跑通的代码，永远比脑子里完美的代码更有价值。

第一版丑一点没关系。先跑通、先验证、先保证有可交付出去的东西。

一般系统的登录鉴权是如何实现的

Sat, 01 Aug 2026 00:00:00 GMT

一、什么是登录鉴权，为什么需要它？#

1、什么是登录鉴权？#

简单来说，登录鉴权就是解决一个问题：

“你是谁？你有没有权限访问这个资源？”

在实际系统中，几乎所有的功能都不是”谁都能用”的。比如：

用户必须先登录，才能看到自己的订单
管理员才能看到后台的用户管理页面
普通用户不能删除别人的数据

这就需要系统在用户访问资源时，先验证用户的身份，再判断用户有没有权限做这个操作。

2、登录鉴权包含两个核心概念#

概念	说明	回答的问题
认证（Authentication）	验证”你是谁”	你真的是张三吗？
授权（Authorization）	验证”你能做什么”	张三有没有权限访问这个接口？

这两个概念在实际开发中经常被一起提到，但它们做的事情是不同的：

认证：通常发生在登录阶段，验证用户名密码是否正确
授权：通常发生在用户访问某个接口或页面时，判断该用户是否有权限

3、为什么需要了解登录鉴权？#

虽然基本上不会让你从头实现登录鉴权，但它是几乎所有业务系统都有的功能，作为程序员还是要有一些基本认识。而且，入职后你大概率会碰到以下场景：

自测接口的时候，需要知道如何去传认证登录的参数
需要做接口鉴权的时候，要明白一般的鉴权逻辑，这样你才能更好的理解你们公司的鉴权方式
需要放行某些接口（不需要登录就能访问）的时候，要知道怎么配置，比如登录接口本身、注册接口、验证码接口、公开页面等
写业务代码时经常需要获取当前登录用户（比如记录”谁创建的""谁修改的”），要知道怎么从后端拿，而不是让前端传
和同事沟通登录鉴权相关需求的时候，要具备这方面基本的认知能力

二、登录鉴权的整体流程#

不管系统用的是哪种技术方案，大多数登录鉴权的整体流程都可以概括为下面几个步骤：

登录鉴权整体流程

用一句话概括：

登录时验证身份，生成凭证；后续请求携带凭证，后端校验凭证和权限。

三、常见的登录认证方式#

1、前后端不分离项目#

前后端不分离的老项目的登录认证一般都是使用的 Session + Cookie 的方式。

Session+Cookie工作流程

1.1 工作流程#

1.2 简单理解#

你可以把 Session + Cookie 理解成这样：

1
你去银行办业务
2
        ↓
3
你拿着身份证去柜台验证身份（提交用户名密码）
4
        ↓
5
验证通过，柜台为你建立一份专属档案，并交给你一张号码牌
6
（登录成功，创建 Session，存入用户信息，通过 Set-Cookie 返回 JSESSIONID）
7
        ↓
8
你拿着号码牌去办业务（浏览器后续请求自动带上 Cookie）
9
        ↓
10
柜台看到号码牌，查到你的档案，办理业务（后端根据 Session ID 找到用户信息）

1.3 关键点#

关键点	说明
Session 存在哪	服务端（内存、Redis、数据库等）
Session ID 怎么传给前端	通过 HTTP 响应头 Set-Cookie
Session 创建时机	理论上首次调用 request.getSession() 就会触发自动创建，但在企业实战中，为了防内存溢出与 Session 固定攻击，拦截器绝不盲目创建，正式 Session 必须在用户登录成功并销毁旧会话后强制重建
前端怎么带 Session ID	浏览器每次请求自动携带 Cookie
Session 过期	服务端设置超时时间，超时后 Session 失效
用户退出登录	服务端销毁 Session，前端清除 Cookie

1.4 优点#

实现简单，浏览器自动管理 Cookie
服务端可以主动让 Session 失效（用户退出登录、修改密码等场景）
状态可控，服务端可以随时查看和管理所有在线用户

1.5 缺点#

分布式问题：Session 默认存在应用服务器内存中，如果是集群部署（多台服务器），用户第一次请求到 A 服务器创建了 Session，第二次请求被分发到 B 服务器，B 服务器没有这个 Session，就会认为用户未登录
跨域问题：Cookie 在跨域场景下处理比较麻烦
移动端不友好：APP、小程序等非浏览器环境，没有自动管理 Cookie 的能力

1.6 分布式 Session 的常见解决方案(了解)#

方案	说明
Session 共享（Redis）	把 Session 存到 Redis 中，所有服务器都从 Redis 读写 Session
IP Hash（Nginx）	同一 IP 的请求始终路由到同一台服务器，但不适合服务器宕机切换的场景
粘性 Session	负载均衡器将同一用户的请求始终分配到同一台服务器

其中，把 Session 存到 Redis 是企业里最常见的方式。

2、前后端分离的项目#

在前后端分离的项目中，我们通常采用 Token 机制 来实现登录认证，而 JWT 则是目前最常用的 Token 格式。

Token自测示例

2.1 什么是 Token？#

Token，翻译过来就是”令牌”。

它就是一个字符串，服务端在用户登录成功后生成，返回给前端，前端后续每次请求都带上这个 Token，服务端通过校验 Token 来判断用户身份。

2.2 什么是 JWT？#

JWT（JSON Web Token）是目前最常用的 Token 格式。

一个 JWT 由三部分组成：

1
Header（头部）.Payload（载荷）.Signature（签名）

例如：

1
eyJhbGciOiJIUzI1NiJ9.eyJyb2xlIjoiQURNSU4iLCJ1c2VySWQiOjEsInZlcnNpb24iOjAsInVzZXJuYW1lIjoiYWRtaW4iLCJpYXQiOjE3ODA2MjkzNjAsImV4cCI6MTc4MTIzNDE2MH0.YMHDAIskTfOcOl4tjWFUUqwcBsvKA4O_xuD2wijezXQ

这三部分的作用：

部分	说明
Header	描述 Token 类型和签名算法，例如 {“alg”: “HS256”, “typ”: “JWT”}
Payload	存放用户信息和自定义数据，例如用户 ID、用户名、过期时间等
Signature	对前两部分的签名，用于验证 Token 是否被篡改

注意

JWT 的 Payload 部分只是经过 Base64 编码，不是加密。所以，不要在 JWT 中存放密码、手机号等敏感信息。

2.3 工作流程#

密钥（Secret Key）的作用说明

密钥是 JWT 安全性的核心，它只保存在服务端，不会泄露给前端。它的作用有两个：

生成 Token 时：后端用密钥对 Header 和 Payload 进行签名（计算出一个哈希值），拼接到 JWT 的第三部分（Signature）

校验 Token 时：后端用同一个密钥重新计算签名，如果和 JWT 中携带的签名一致，说明 Token 没有被篡改

如果密钥泄露了，任何人都可以伪造 JWT，所以密钥的安全保管非常重要。

2.4 简单理解#

1
你去景区玩
2
        ↓
3
售票处验证你的身份证（验证用户名密码）
4
        ↓
5
验证通过，给你一张"门票"（生成 JWT）
6
        ↓
7
门票上写了你的名字、有效期（JWT 的 Payload）
8
        ↓
9
门票上有景区的防伪印章（JWT 的 Signature）
10
        ↓
11
你每次进景点，工作人员看门票（后端校验 JWT）
12
        ↓
13
门票是真的且没过期 → 放行
14
门票是假的或已过期 → 拒绝进入

2.5 Token 和 Session 的核心区别(了解)#

对比项	Session + Cookie	Token（JWT）
用户信息存储位置	服务端（内存/Redis）	Token 本身（客户端携带）
服务端是否需要存储会话信息	需要	JWT 本身可以做到无状态，但实际项目中为了实现踢人下线、Token 续期、多端登录控制等能力，经常配合 Redis 使用
分布式支持	需要额外做 Session 共享	天然支持，因为 Token 自带用户信息
跨域支持	较差	较好
主动失效	容易（删掉服务端 Session 即可）	较难（JWT 签发后，在过期之前始终有效）
移动端支持	不太方便	非常适合

2.6 JWT 的优点（了解）#

无状态：JWT 本身可以做到无状态，服务端不需要存储 Session 信息，天然支持分布式
跨域友好：适合前后端分离、多端（Web、APP、小程序）场景
性能好：理论上 JWT 中的信息可以直接使用，不必依赖服务端会话存储；但实际项目中通常仍会结合 Redis 缓存用户信息

2.7 JWT 的缺点（了解）#

无法主动失效：JWT 签发后，在过期之前始终有效。用户修改密码、被踢下线等场景不好处理
Payload 不可太大：JWT 每次请求都要携带，如果 Payload 里塞太多数据，会增加请求体积
Token 续期问题：Token 过期了怎么处理？是用 Refresh Token 续期，还是让用户重新登录？

2.8 JWT 无法主动失效的常见解决方案#

虽然 JWT 本身无法主动失效，但在实际项目中通常有以下几种处理方式：

方案	说明
缩短 Token 有效期	把 Token 有效期设短一些（比如 30 分钟），配合 Refresh Token 使用
黑名单机制	用户退出登录或修改密码时，把对应 Token 加入黑名单（通常存到 Redis），校验时先查黑名单
Refresh Token	登录时同时返回一个短期 Token 和一个长期 Refresh Token，Token 过期后用 Refresh Token 换取新的 Token

四、如何获取当前登录用户#

用户登录之后，我在业务代码里怎么知道”当前操作的人是谁”？

这个问题在实际开发中非常常见。和登录认证一样，获取登录用户信息一般也有现成的代码，不需要从头写。你需要记住两点：

不要让前端传用户 ID（除非你的组长明确告诉你这样做）
获取登录用户是通过 Session 或 Token 实现的，项目中一般已有封装好的工具类，找到直接用就行（最好封装成工具类，后面会频繁用到）。找不到的话，先让 AI 帮你搜，AI 也找不到就问同事：“我们项目里有没有获取当前登录用户的方法？“确认没有再自己写

1、为什么需要获取当前登录用户？#

举几个你入职后一定会遇到的场景：

场景	说明
数据新增	新增一条记录时，要记录这条数据是谁创建的（create_by 字段）
数据修改	修改数据时，要记录是谁改的（update_by 字段）
操作日志	记录”张三在 2024-01-01 删除了某条数据”
数据权限	查询时只返回当前用户自己的数据，比如”我的订单”

这些场景都有一个共同点：后端需要知道当前请求是谁发的，而不是让前端来告诉后端。

2、为什么不能让前端传用户 ID？#

有些新人可能会想：前端直接把用户 ID 传过来不就行了？

1
// ❌ 错误做法：让前端传 userId
2
@PostMapping("/add")
3
public Result add(@RequestParam Long userId, @RequestBody Order order) {
4
    order.setCreateBy(userId);  // 前端传过来的 userId
5
    orderService.save(order);
6
    return Result.success();
7
}

这存在严重的安全问题：

如果有人用 Postman 之类的工具直接调用接口，把 userId 改成别人的，就能以别人的身份创建数据。这等于说，谁都能冒充任何人操作。

所以，当前用户的身份必须从后端的认证信息中获取，不能依赖前端传递。

正确的做法是：

1
// ✅ 正确做法：从后端的认证上下文中获取当前用户
2
@PostMapping("/add")
3
public Result add(@RequestBody Order order) {
4
    Long userId = SecurityUtils.getUserId();  // 从后端获取，而非前端传入
5
    order.setCreateBy(userId);
6
    orderService.save(order);
7
    return Result.success();
8
}

3、真实工作中一般获取登录用户的代码#

以下均是真实工作中项目代码截图。从这些代码可以看出，这种获取登录用户的逻辑都是封装到工具类里面的。

获取登录用户示例1

获取登录用户示例2

获取登录用户示例3

4、一般都是怎么实现的？#

不同登录认证方式，获取用户的实现也有所不同。但一般思路知道即可，真实工作中需要你写的可能性极低，即使让你写，也可以让 AI 直接帮你写。

一般思路如下：

拦截请求 → 解析凭证 → 存储当前用户 → 后续随时获取用户信息

1）、拦截请求

请求到达后端后，会先经过全局拦截器（Filter / Interceptor）。它会检查请求中是否携带了 Token、Session ID 等登录凭证。

2）、解析用户信息

如果是 JWT Token：后端会解析 Token，拿到 userId 等用户信息，必要时再去 Redis 查询完整用户数据。
如果是 Session：后端会根据 Session ID，从 Tomcat 或 Redis 中取出对应的用户对象。

3）、存入当前线程（ThreadLocal）

拿到用户信息后，框架会把当前用户存入 ThreadLocal（例如 Spring Security 的 SecurityContext）。

这样后续业务代码中，就不需要层层传递用户参数了。在 Controller、Service 里直接调用类似：

1
SecurityUtils.getUser()

底层其实就是从 ThreadLocal 中获取当前登录用户。

4）、真实项目中常见的获取用户方式（了解）

上面讲的是一般思路，下面是真实项目中的统计，帮你了解实际工作中会遇到哪些方式。

常见方式统计

获取方式	使用频率	核心代码示例	说明
Spring Security Context	最常见	SecurityContextHolder.getContext().getAuthentication()	大部分项目都用这个
自定义 ThreadLocal	常见	StaffThreadLocal.getStaff()	自己封装的工具类
工具类从 Request 解析	常见	SecurityUserUtil.getCurrentUserId(request)	直接从请求头解析Token
框架 API（Sa-Token等）	少见	StpUtil.getLoginIdAsLong()	特定框架提供的API
HttpSession	老项目	request.getSession().getAttribute(“user”)	传统Session方式

实际工作中怎么快速上手？

找到项目里获取用户的方式：搜索 SecurityUtils、getLoginUser、getCurrentUser 等关键词
直接使用：找到后直接用，不用关心底层实现，项目里别人怎么写，你就怎么写
不要自己造轮子：项目里一般都有现成的工具类，直接调用即可

总结：入职后不需要从头实现获取用户的逻辑，找到项目里现有的方式直接用就行。如果找不到，先问 AI 帮你搜，搜不到再问同事。

五、权限控制（授权）#

工作中，我们写的接口一般都需要设置权限，不会让所有用户都能调用。权限控制这块通常不需要你从 0 到 1 去实现，但你需要先了解常见的权限控制逻辑，这样到了公司才能更好地理解你们项目的权限方案。如果公司采用的方式不是通用模式，直接问同事就行（也可以先让 AI 帮你生成一个权限控制设计方案，再跟同事沟通确认）。如果你连常见的权限控制逻辑都不清楚，可能就很难听懂别人给你讲的东西。

1、RBAC 权限模型#

RBAC（Role-Based Access Control，基于角色的访问控制）是企业中最常见的权限模型。

核心思路

1
用户 → 角色 → 权限

也就是说：

一个用户可以拥有多个角色
一个角色可以拥有多个权限
一个权限对应一个具体的操作（如：用户列表查询、用户删除等）

数据库设计通常是这几张表

表名	说明
user	用户表
role	角色表
permission	权限表
user_role	用户-角色关联表
role_permission	角色-权限关联表

举例

1
用户：张三
2
        ↓
3
角色：普通管理员
4
        ↓
5
权限：用户列表查询、用户详情查询、用户编辑
6
（没有"用户删除"权限）
7
        ↓
8
张三可以查看和编辑用户，但不能删除用户

2、权限控制的常见实现方式#

方式	说明	示例
接口级权限	控制某个接口只有特定角色才能访问	@RequiresRoles(“admin”)
按钮级权限	控制页面上某个按钮只有特定角色才能看到	前端根据权限列表判断是否显示按钮
数据级权限	控制用户只能看到自己部门的数据	查询时自动拼接部门过滤条件

其中，接口级权限 是后端开发最常接触的。

3、为什么要前后端都做权限控制？#

有些同学可能会想：前端已经根据权限隐藏了按钮，后端还需要再校验吗？

答案是：必须的。

因为前端隐藏按钮只是页面展示层面的控制，用户完全可以通过直接调用接口来绕过前端限制。所以：

前端权限控制是为了用户体验，后端权限控制是为了安全。

六、实际工作中常见的权限控制方式#

下面以国内最常用的后台管理系统脚手架若依（RuoYi）前后端分离版本为例，介绍实际工作中基于 RBAC 模型的权限控制是怎么实现的。很多公司会基于若依进行二次开发，或借鉴其权限方案，入职后你大概率会遇到。

1、权限控制#

若依的权限控制是基于 RBAC 模型 实现的，涉及以下几张核心表：

表名	说明
sys_user	用户表
sys_role	角色表，其中 data_scope 字段控制数据权限等级
sys_menu	菜单/权限表，每条菜单对应一个权限标识（如 system:user）
sys_user_role	用户-角色关联表
sys_role_menu	角色-菜单关联表
sys_role_dept	角色-部门关联表（数据权限为”自定义”时使用）

接口级权限

若依使用 Spring Security 的 @PreAuthorize 注解来控制接口权限：

按权限字符控制：判断当前用户是否拥有指定权限字符串

1
@PreAuthorize("@ss.hasPermi('system:user:list')")
2
@GetMapping("/list")
3
public TableDataInfo list(SysUser user) {
4
    // ...
5
}

@ss 是若依自定义的权限服务 PermissionService，注册为 Spring Bean，名称为 ss。hasPermi 方法会从当前登录用户的权限列表中判断是否包含指定的权限字符串。

1
// PermissionService.java — 权限判断的核心逻辑
2
@Service("ss")  // 注册为Spring Bean，名称为ss
3
public class PermissionService {
4

5
    public boolean hasPermi(String permission) {
6
        LoginUser loginUser = SecurityUtils.getLoginUser();
7
        if (StringUtils.isNull(loginUser) || CollectionUtils.isEmpty(loginUser.getPermissions())) {
8
            return false;
9
        }
10
        // 判断用户的权限列表中是否包含该权限
11
        return hasPermissions(loginUser.getPermissions(), permission);
12
    }
13

14
    // 支持任意一个权限匹配
15
    public boolean hasAnyPermi(String permissions) {
16
        // 多个权限用逗号分隔，只要有一个匹配就返回true
17
    }
18

19
    // 判断是否拥有某个角色
20
    public boolean hasRole(String role) {
21
        // 从用户的角色列表中判断
22
    }
23

24
    // 支持任意一个角色匹配
25
    public boolean hasAnyRoles(String roles) {
26
        // 多个角色用逗号分隔，只要有一个匹配就返回true
27
    }
28
}

展开收起

按角色控制：判断当前用户是否拥有指定角色

1
// 判断是否拥有 admin 角色
2
@PreAuthorize("@ss.hasRole('admin')")
3
@GetMapping("/list")
4
public TableDataInfo list(SysUser user) {
5
    // ...
6
}
7

8
// 判断是否拥有任意一个角色（admin 或 common）
9
@PreAuthorize("@ss.hasAnyRoles('admin,common')")
10
@GetMapping("/list")
11
public TableDataInfo list(SysUser user) {
12
    // ...
13
}

按钮级权限

前端使用自定义指令 v-hasPermi 来控制按钮是否显示：

1
<!-- 只有拥有 system:user:add 权限的用户才能看到"新增"按钮 -->
2
<el-button v-hasPermi="['system:user:add']">新增</el-button>
3
<el-button v-hasPermi="['system:user:edit']">修改</el-button>
4
<el-button v-hasPermi="['system:user:remove']">删除</el-button>
5

6
<!-- 需要同时拥有多个权限中的任意一个 -->
7
<el-dropdown v-hasPermi="['system:user:resetPwd', 'system:user:edit']">
8
    <el-button>更多操作</el-button>
9
</el-dropdown>

v-hasPermi 指令的判断逻辑：

hasPermi.js展开收起

1
export default {
2
  inserted(el, binding) {
3
    const { value } = binding                                    // 按钮上写的权限标识，如 ['system:user:add']
4
    const permissions = store.getters.permissions               // 用户拥有的权限列表（从 /getInfo 接口获取）
5

6
    const hasPermissions = permissions.some(permission => {
7
      return "*:*:*" === permission                              // 超级管理员有所有权限
8
        || value.includes(permission)                            // 或者用户权限列表中包含这个标识
9
    })
10

11
    if (!hasPermissions) {
12
      el.parentNode && el.parentNode.removeChild(el)            // 没权限就从页面移除按钮
13
    }
14
  }
15
}

展开收起

数据权限

前面的接口级权限和按钮级权限解决的是”你能不能调这个接口”的问题，而数据权限解决的是”你能看到哪些数据”的问题。

同样是”用户列表”接口，部门经理能看到本部门所有员工的数据，普通员工只能看到自己的数据。

若依的数据权限是通过 AOP + MyBatis 参数注入 实现的，核心思路就是在查询 SQL 中动态拼接 WHERE 条件。

1）数据权限的五个等级

每个角色都有一个 dataScope 字段，对应 sys_role 表的 data_scope 列：

值	含义	生成的 SQL 条件
1	所有数据权限	不加过滤
2	自定义数据权限	dept_id IN (SELECT dept_id FROM sys_role_dept WHERE role_id = ?)
3	本部门数据权限	dept_id = 当前用户部门ID
4	本部门及以下数据权限	dept_id IN (…本部门及子部门)
5	仅本人数据权限	user_id = 当前用户ID

2）怎么使用

只需在 Service 方法上加 @DataScope 注解：

1
@DataScope(deptAlias = "d", userAlias = "u")
2
public List<SysUser> selectUserList(SysUser user)
3
{
4
    return userMapper.selectUserList(user);
5
}

然后在 MyBatis XML 的查询 SQL 末尾加上 ${params.dataScope}：

1
<select id="selectUserList" parameterType="SysUser" resultMap="SysUserResult">
2
    select u.user_id, u.dept_id, u.user_name, d.dept_name
3
    from sys_user u
4
    left join sys_dept d on u.dept_id = d.dept_id
5
    where u.del_flag = '0'
6
    ${params.dataScope}
7
</select>

3）运行原理

AOP 切面（DataScopeAspect）会在方法执行前拦截，获取当前用户的所有角色，根据每个角色的 dataScope 值生成对应的 SQL 过滤条件，注入到方法参数的 params.dataScope 中。这样 MyBatis 执行时就会自动拼接上数据权限的过滤条件。

简单来说：加个 @DataScope 注解 + XML 里写个 ${params.dataScope}，数据权限就生效了。

注意：正常业务开发中应谨慎使用 ${}，因为它会直接进行字符串拼接，存在 SQL 注入风险（应优先使用 #{}）。若依的数据权限实现中，拼接内容由 AOP 切面根据用户角色自动生成，来源可控，因此能够安全使用。不要在其他业务场景中模仿这种写法，除非你能确保拼接内容的安全性。

2、其他权限控制方式#

上面介绍的若依是典型的 RBAC 权限模型，适合角色多、权限细的场景。但有些项目可能并不需要那么精细的权限控制，只需要区分”管理员”和”普通用户”，这种情况下往往直接在代码里加一层判断就行了。

2.1 用户表加一个角色字段#

最简单的做法就是在用户表里加一个字段来标识用户类型：

1
-- user 表中加一个 role 字段
2
CREATE TABLE user (
3
    id BIGINT PRIMARY KEY,
4
    username VARCHAR(50),
5
    password VARCHAR(100),
6
    role VARCHAR(20) DEFAULT 'user'  -- admin 表示管理员，user 表示普通用户
7
);

登录后，这个 role 字段会随着用户信息一起存到 Token 或 Session 中。后续请求时，后端直接判断角色即可。

2.2 后端怎么判断权限？#

方式一：在接口里直接判断

最直接的方式，就是在需要权限控制的接口里加一个 if 判断：

1
@GetMapping("/admin/users")
2
public Result getUserList() {
3
    User currentUser = SecurityUtils.getCurrentUser();
4
    if (!"admin".equals(currentUser.getRole())) {
5
        return Result.error(403, "无权限访问");
6
    }
7
    // 管理员才能执行的逻辑
8
    return Result.success(userService.list());
9
}

这种方式简单粗暴，适合接口不多的小项目。但如果需要控制的接口多了，每个接口都写一遍判断就太重复了。

方式二：抽一个公共方法

稍微好一点的做法，是把判断逻辑抽到一个公共方法里：

1
@GetMapping("/admin/users")
2
public Result getUserList() {
3
    checkAdmin();  // 公共方法，不是管理员直接抛异常
4
    return Result.success(userService.list());
5
}
6

7
private void checkAdmin() {
8
    User currentUser = SecurityUtils.getCurrentUser();
9
    if (!"admin".equals(currentUser.getRole())) {
10
        throw new BusinessException("无权限访问");
11
    }
12
}

方式三：用拦截器统一处理

更好的做法是通过拦截器（Filter / Interceptor）统一处理，而不是在每个接口里手动判断：

1
@Component
2
public class AdminInterceptor implements HandlerInterceptor {
3

4
    @Override
5
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
6
        String uri = request.getRequestURI();
7
        // 只拦截 /admin/** 路径下的接口
8
        if (uri.startsWith("/admin/")) {
9
            User currentUser = SecurityUtils.getCurrentUser();
10
            if (!"admin".equals(currentUser.getRole())) {
11
                response.setStatus(403);
12
                return false;
13
            }
14
        }
15
        return true;
16
    }
17
}

展开收起

然后注册拦截器，把 /admin/** 路径的请求都交给它处理：

1
@Configuration
2
public class WebMvcConfig implements WebMvcConfigurer {
3

4
    @Autowired
5
    private AdminInterceptor adminInterceptor;
6

7
    @Override
8
    public void addInterceptors(InterceptorRegistry registry) {
9
        registry.addInterceptor(adminInterceptor)
10
                .addPathPatterns("/admin/**");
11
    }
12
}

这样，所有以 /admin/ 开头的接口，只有管理员才能访问，普通用户会直接被拦截返回 403。不需要在每个接口里写判断，代码更干净。

方式四：用自定义注解

和拦截器类似的思路，也可以通过自定义注解来实现：

1
// 定义注解
2
@Target(ElementType.METHOD)
3
@Retention(RetentionPolicy.RUNTIME)
4
public @interface RequireAdmin {
5
}
6

7
// 在需要管理员权限的接口上加注解
8
@RequireAdmin
9
@GetMapping("/users")
10
public Result getUserList() {
11
    return Result.success(userService.list());
12
}

然后通过 AOP 切面来拦截加了 @RequireAdmin 注解的方法：

1
@Aspect
2
@Component
3
public class AdminAspect {
4

5
    @Before("@annotation(requireAdmin)")
6
    public void checkAdmin(RequireAdmin requireAdmin) {
7
        User currentUser = SecurityUtils.getCurrentUser();
8
        if (!"admin".equals(currentUser.getRole())) {
9
            throw new BusinessException("无权限访问");
10
        }
11
    }
12
}

这几种方式本质上都是做同一件事：判断当前用户是不是管理员，不是就拒绝访问。区别只是代码组织方式不同。

2.3 前端怎么配合？#

后端控制了接口权限，前端一般也会配合做界面上的控制：

1
// 根据用户角色控制页面元素的显示
2
if (user.role === 'admin') {
3
    // 显示管理后台入口、用户管理菜单等
4
    showAdminMenu();
5
} else {
6
    // 隐藏这些元素
7
    hideAdminMenu();
8
}

七、登录鉴权常见问题与排查#

1、什么是跨域？跨域和鉴权有什么关系？#

同源策略是浏览器的安全机制：只有当请求的协议、域名、端口三者都相同时，才被认为是”同源”。不满足任一条件就是”跨域”。

例如，前端在 http://localhost:3000，后端在 http://localhost:8080，端口不同，就是跨域。

跨域对鉴权的影响：

Cookie 方式：默认情况下，跨域请求不会携带 Cookie，需要后端配置 CORS 并设置 Access-Control-Allow-Credentials: true
Token 方式：前端手动在请求头中添加 Token，不受 Cookie 限制，但需要后端配置 CORS 允许自定义请求头

后端解决跨域的常见方式：

1
// 方式一：在 Controller 或方法上加注解
2
@CrossOrigin(origins = "http://localhost:3000")
3

4
// 方式二：全局配置
5
@Configuration
6
public class CorsConfig implements WebMvcConfigurer {
7
    @Override
8
    public void addCorsMappings(CorsRegistry registry) {
9
        registry.addMapping("/**")
10
                .allowedOrigins("http://localhost:3000")
11
                .allowedMethods("*")
12
                .allowCredentials(true);
13
    }
14
}

2、什么是 OAuth 2.0？它和 JWT 什么区别？#

OAuth 2.0 是什么？

OAuth 2.0 是一个授权框架，它解决的核心问题是：

如何让用户在不给第三方应用密码的情况下，授权它访问自己的资源。

最常见的场景就是”第三方登录”，比如：

用微信扫码登录某个网站
用 GitHub 账号登录某个开发工具
用 Google 账号登录某个 App

OAuth 2.0 和 JWT 的区别

这两个东西经常被混淆，但它们根本不在同一层：

对比项	OAuth 2.0	JWT
本质	授权框架（一套流程规范）	数据格式（一种 Token 规范）
解决的问题	如何让用户安全地授权第三方访问资源	Token 怎么生成、怎么校验、怎么防篡改
典型场景	微信登录、GitHub 登录	前后端分离项目的登录认证

简单来说：OAuth 2.0 定义的是”流程”，JWT 定义的是”格式”。 OAuth 2.0 流程中产生的 Token 可以用 JWT 格式，也可以不用。

作为后端开发，你更常接触的是 JWT。OAuth 2.0 一般在对接第三方登录时才会用到，而且通常已经有现成的 SDK 或框架集成，不需要你自己从头实现。

3、SSO 是什么？#

SSO（Single Sign-On，单点登录）解决的问题是：

用户在多个系统中只需要登录一次，就能访问所有互相信任的系统，不需要重复登录。

举个例子：

1
你们公司有以下系统：
2
    - OA 系统（oa.company.com）
3
    - HR 系统（hr.company.com）
4
    - 邮件系统（mail.company.com）
5

6
没有 SSO 的情况：
7
    - 你要先登录 OA → 输入一次账号密码
8
    - 再登录 HR → 再输入一次账号密码
9
    - 再登录邮件 → 又输入一次账号密码
10

11
有了 SSO：
12
    - 你只要登录一次（比如先登录 OA）
13
    - 然后访问 HR、邮件系统，都自动识别你已登录，不需要再输入密码

SSO 的核心思路

1
用户访问系统 A
2
        ↓
3
系统 A 发现用户没登录，跳转到 SSO 认证中心
4
        ↓
5
用户在认证中心输入账号密码，登录成功
6
        ↓
7
认证中心给用户发一个全局凭证（Ticket / Token），同时记录"这个用户已经登录了"
8
        ↓
9
用户带着凭证回到系统 A，系统 A 拿凭证去认证中心验证，验证通过，登录成功
10
        ↓
11
用户再访问系统 B
12
        ↓
13
系统 B 发现用户没登录，跳转到认证中心
14
        ↓
15
认证中心发现这个用户已经登录过了（不需要再输密码），直接给用户发凭证
16
        ↓
17
用户带着凭证回到系统 B，登录成功

展开收起

常见实现方式

方式	说明	典型应用
CAS	企业内网最常用的 SSO 方案，基于 Cookie + Ticket	公司内部多个系统统一登录
OAuth 2.0	适用于第三方应用授权登录	微信登录、Google 登录
同域 SSO	多个系统在同一个顶级域名下，共享 Cookie	a.company.com 和 b.company.com 共享登录状态

入职后你大概率会遇到 SSO，因为只要公司有多个内部系统，基本都会做单点登录。不过 SSO 的实现一般也是现成的，你不需要从零写，了解即可。

4、如何放行某个接口，不需要登录即可访问？#

系统里不是所有接口都需要登录才能访问。有些接口天然就不需要鉴权，如果不放行，功能就会出问题。常见的放行场景如下：

场景	典型接口	为什么要放行
登录/注册	/login、/register、/captcha	用户还没登录，不可能有凭证，不放行就永远登不上
公开页面	文章详情、商品详情、公告列表	这些内容面向所有人，不需要登录就能看
第三方回调	微信登录回调、支付回调	第三方系统调你的接口，它没有你的登录凭证
健康检查/监控	/actuator/health、Spring Boot 健康检查端点	运维或监控系统需要定期探测服务是否存活
静态资源	图片、CSS、JS 文件	前端页面依赖这些资源，不能要求它们也带 Token
分享链接	带 Token 的临时分享链接	比如”分享给好友查看”，好友没有账号也能访问

想要知道你们项目怎么放行接口的，就全局搜索登录接口，去看它怎么放行的，或者也可以让 AI 告诉你。

常见的放行方式有以下几种：

方式一：在拦截器配置中排除路径

这是最直接的方式，在拦截器注册时指定哪些路径不需要拦截：

1
@Configuration
2
public class WebMvcConfig implements WebMvcConfigurer {
3

4
    @Autowired
5
    private AuthInterceptor authInterceptor;
6

7
    @Override
8
    public void addInterceptors(InterceptorRegistry registry) {
9
        registry.addInterceptor(authInterceptor)
10
                .addPathPatterns("/**")                          // 拦截所有请求
11
                .excludePathPatterns(                            // 排除以下路径，不做鉴权
12
                        "/login",
13
                        "/register",
14
                        "/captcha",
15
                        "/public/**"
16
                );
17
    }
18
}

展开收起

方式二：在 Security 配置中放行

如果项目用的是 Spring Security，可以在安全配置类中放行：

1
@Configuration
2
@EnableWebSecurity
3
public class SecurityConfig {
4

5
    @Bean
6
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
7
        http.authorizeHttpRequests(auth -> auth
8
                .requestMatchers("/login", "/register", "/captcha", "/public/**").permitAll()  // 放行
9
                .anyRequest().authenticated()  // 其他请求需要认证
10
        );
11
        return http.build();
12
    }
13
}

方式三：用自定义注解标记放行接口

有些项目会定义一个 @Anonymous 注解，加在接口上就表示不需要登录：

1
// 定义注解
2
@Target({ElementType.METHOD, ElementType.TYPE})
3
@Retention(RetentionPolicy.RUNTIME)
4
public @interface Anonymous {
5
}
6

7
// 在不需要登录的接口上加注解
8
@Anonymous
9
@GetMapping("/public/article/{id}")
10
public Result getArticle(@PathVariable Long id) {
11
    return Result.success(articleService.getById(id));
12
}

然后在拦截器中判断：如果接口方法上有 @Anonymous 注解，就直接放行：

1
@Override
2
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
3
    // 如果是带有 @Anonymous 注解的接口，直接放行
4
    if (handler instanceof HandlerMethod handlerMethod) {
5
        Anonymous anonymous = handlerMethod.getMethodAnnotation(Anonymous.class);
6
        if (anonymous != null) {
7
            return true;
8
        }
9
    }
10
    // 其他接口正常做鉴权校验
11
    // ...
12
}

方式三的好处：放行配置直接写在接口上，一目了然，不用跑到配置类里去找。若依框架就是用的这种注解方式（@Anonymous）来放行接口的。

5、常见鉴权问题排查#

实际工作中，以下是最常见的鉴权相关问题及排查思路。

实用排查技巧：参考平台其他接口的传参方式
如果不确定某个接口的认证参数怎么传，可以先登录你们公司的平台，按 F12 打开浏览器开发者工具，切换到 Network（网络）面板，然后在页面上随便操作一下，观察其他接口是怎么传 Token/Cookie 的——请求头叫什么名字、格式是什么（比如 Bearer xxx 还是直接传值）。照着别的接口的传参方式来就行，这是最快的方式，比自己猜或者翻代码都快。

5.1、接口返回 401（未认证）#

说明：请求没有携带有效的登录凭证，或者凭证已失效。

排查步骤：

步骤	检查内容
1	Token 有没有传？检查请求头中是否包含 Authorization 或 token 字段
2	Token 格式对不对？有的项目要求 Bearer xxx，有的只要 Token 值
3	Token 是否过期？看看 Token 的过期时间，或者重新登录拿一个新 Token
4	请求头名字对不对？不同项目的请求头名称可能不同（Authorization、token、X-Token 等），看项目配置
5	是不是跨域导致 Cookie 没带上？Session 方案要检查 Cookie 是否被浏览器拦截
6	网关是否丢失了请求头？如果项目用了网关（如 Nginx、Gateway），检查网关是否把认证相关的请求头透传了
7	接口是否被拦截器拦截？检查接口是否在放行列表中，如果不在，确认是否需要放行

5.2、接口返回 403（无权限）#

说明：已登录，但当前用户没有权限访问该资源。

排查步骤：

步骤	检查内容
1	当前用户的角色是否正确？检查用户绑定的角色是否符合预期
2	权限字符是否配置？检查接口上的权限注解（如 @RequiresPermissions(“system:user”)），确认权限字符在数据库中是否存在
3	菜单权限是否绑定到角色？确认权限字符对应的菜单已经绑定到当前用户的角色上
4	数据权限是否限制了数据范围？如果开启了数据权限，可能是 SQL 层面的过滤导致查不到数据，而非 403
5	是不是 admin 账号也 403？如果 admin 也 403，说明可能是配置问题；如果只有普通用户 403，大概率是权限没配置到位

5.3、当前用户获取为空#

代码中调用获取当前用户的方法返回 null，一般就这几个原因：

先确认是不是真的登录了（接口有没有返回 401，如果是，先解决登录问题）
如果是在子线程或异步方法（@Async、线程池）中获取用户，ThreadLocal 的值可能没有传递过去，需要在进入异步之前先把用户信息取出来，作为参数传进去：

1
// 在主线程中先获取当前用户
2
Long userId = SecurityUtils.getUserId();
3

4
// 把 userId 作为参数传给异步方法，不要在异步方法里面再去调 SecurityUtils.getUserId()
5
@Async
6
public void doSomething(Long userId) {
7
    // 这里直接用传进来的 userId，不要再去获取当前登录用户
8
}

确认你调用的获取当前用户的方法是不是项目封装好的那个，不同项目方法名可能不一样

总结：遇到鉴权问题，先确认”有没有登录”（401），再确认”有没有权限”（403），最后确认”能不能拿到用户信息”（null）。按这个顺序排查，基本能覆盖 90% 的场景。

Claude Code本地安装与配置国产智谱模型

Sat, 01 Aug 2026 00:00:00 GMT

准备工作

在开始之前，请确保你的电脑上已经安装了 Node.js（建议 18.0 或更高版本）和 Git 。

确认安装node

确认安装git

一、安装#

打开你的终端（Terminal）或命令行工具，输入以下命令。我们使用 npm 进行全局安装，这样你就可以在任何目录下呼出 Claude 了。

1
# 全局安装 Claude Code 核心组件
2
npm install -g @anthropic-ai/claude-code

注意：如果安装速度较慢，可以考虑切换 npm 的国内镜像源（如淘宝镜像）来加速下载。

二、验证安装完整性#

安装完成后，我们需要确认工具是否已成功装入你的系统。在终端中输入以下指令来查看当前版本：

Terminal window

1
# 查看版本号，验证是否安装成功
2
claude --version

如果终端成功返回了一串版本号（如下图所示），那么恭喜你，核心组件已经安装就绪！

三、绕过区域限制协议#

由于一些网络或区域的限制，部分小伙伴直接使用时可能会遇到连接超时或报错的问题。这个时候可以通过配置一个专属脚本来启动 Claude Code，完美且优雅地绕过区域限制。

1、创建专属启动脚本#

在你的电脑里找一个安全的文件夹（比如 C:\scripts），新建一个文本文件，命名为 cld.bat，然后将以下代码复制进去并保存：

Terminal window展开收起

1
@echo off
2
:: 1. 切换控制台编码为 UTF-8，确保中文显示正常
3
chcp 65001 >nul
4

5
:: 2. 设置局部环境变量 (仅对当前进程及其子进程有效)
6
:: 请确保 1080 与你的 Shadowrocket 本地代理端口一致
7
set ALL_PROXY=socks5://127.0.0.1:1080
8

9
echo [Claude CLI] 代理隧道已建立 (Port:1080)...
10

11
:: 3. 动态寻找并执行原始的 claude 程序
12
:: %* 允许你传递所有参数，如 cl /doctor 或 cl "explain this code"
13
for /f "delims=" %%i in ('where claude') do (
14
    "%%i" %*
15
    goto :finish
16
)
17
:finish
18
:: 脚本结束，变量自动销毁，不影响系统其他程序

展开收起

2、配置系统环境变量#

将存放 cld.bat 的文件夹路径（比如 C:\scripts），添加到你的 Windows 系统环境变量 Path 中。这样做的目的是，让你可以在系统的任意目录下直接执行该脚本。

3、通过脚本启动#

以后在任何项目文件夹下打开终端，不要再输入 claude，而是直接输入 cld！这样启动的 Claude Code 就自带代理，完美绕过区域限制。

首次启动时，会出现以下几个初始化界面：

主题设置：询问你终端的主题颜色和文本样式，直接按回车选择默认即可。

安全指南：系统安全提示，直接按回车

工作区信任确认：询问你是否信任当前代码文件夹，选择第一项 Yes, I trust this folder，回车即可。

四、配置国产智普模型如果你不想一直挂着代理，或者觉得官方 API 成本太高，我们可以直接修改底层配置，将其无缝切换为国内的智谱大模型 (GLM)。使用国产模型，也不会出现区域限制问题，也就不需要通过脚本启动来绕过区域限制。

打开以下路径的配置文件（如果没有 settings.json 文件则手动新建一个）：

Windows 路径：C:\Users\你的用户名\.claude\settings.json

用代码编辑器打开它，编写如下参数（请将 your_zhipu_api_key 替换为你自己在智谱开放平台申请的真实 API Key）：

Terminal window

1
{
2
  "env": {
3
    "ANTHROPIC_BASE_URL": "https://open.bigmodel.cn/api/anthropic",
4
    "ANTHROPIC_AUTH_TOKEN": "your_zhipu_api_key",
5
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "glm-4.5-air",
6
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "glm-5-turbo",
7
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "glm-5.1"
8
  }
9
}

配置保存后，再次在终端唤醒 Claude Code，就可以使用智谱了！

四、卸载#

Terminal window

1
# 卸载命令，cmd窗口执行
2
npm uninstall -g @anthropic-ai/claude-code

这个卸载完成之后还要将 Windows 路径：C:\Users\你的用户名\.claude\ 的该目录删除

Claude Code集成DeepSeek V4 pro

Sat, 01 Aug 2026 00:00:00 GMT

准备工作#

前往 DeepSeek 官网 https://platform.deepseek.com/usage 创建 API Key，并确保账户余额充足。

一、直接修改配置文件#

Claude Code 的核心配置存储在用户目录下的 settings.json 中：

路径：C:\Users\你的用户名\.claude\settings.json

如果文件不存在，请手动创建。用文本编辑器打开该文件，填入以下内容：

1
{
2
  "env": {
3
    "ANTHROPIC_AUTH_TOKEN": "your_deepseek_api_key",
4
    "ANTHROPIC_BASE_URL": "https://api.deepseek.com/anthropic",
5
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "deepseek-v4-flash",
6
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "deepseek-v4-pro[1m]",
7
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "deepseek-v4-pro[1m]",
8
    "ANTHROPIC_MODEL": "deepseek-v4-pro[1m]",
9
    "ANTHROPIC_REASONING_MODEL": "deepseek-v4-pro[1m]"
10
  }
11
}

二、使用 cc-switch（多模型切换工具）#

如果你需要在 Claude Code 中集成多个模型并频繁切换，每次都手动修改配置文件会非常繁琐。cc-switch 正是为了解决这个问题而生的。当然，如果你只固定使用一个模型，可以跳过这一步。

1. 安装 cc-switch#

前往 https://github.com/farion1231/cc-switch/releases 下载 Windows 版（.msi 后缀），双击安装即可。

2. 添加 DeepSeek 供应商#

3. 配置 DeepSeek V4 Pro#

需要配置的信息如下：

配置项	内容/值
供应商名称	DeepSeek V4 Pro(任意起，通过名字知道自己用的哪个模型即可)
备注	（空）
官网链接	（空）
API Key	填写你的 API Key
请求地址	https://api.deepseek.com/anthropic
API 格式	Anthropic Messages (原生)
认证字段	ANTHROPIC_AUTH_TOKEN（默认）
主模型	deepseek-v4-pro[1m]
推理模型 (Thinking)	deepseek-v4-pro[1m]
Haiku 默认模型	deepseek-v4-flash
Sonnet 默认模型	deepseek-v4-pro[1m]
Opus 默认模型	deepseek-v4-pro[1m]
写入通用配置	✅ 勾选
高强度思考	✅ 勾选

4. 验证配置#

点击下图模型名称旁边的测试按钮：

出现如下结果即表示配置成功。此时点击供应商右侧的”启用”，即可使用 DeepSeek V4 Pro 模型。

三、启动与使用#

配置完成后，在项目目录下执行以下命令启动 Claude Code（底层已自动切换为 DeepSeek）：

Terminal window

1
claude

常见问题：模型不匹配报错#

如果你在已打开的 Claude Code 会话中通过 cc-switch 切换了模型，继续使用当前会话可能会报如下错误：

这是因为当前会话仍在使用旧的模型（如图中的 glm-5.1），而新配置的供应商只支持 deepseek-v4-pro 或 deepseek-v4-flash。此时使用 /model 命令重新选择模型即可：

选择第二个模型，回车，再次提问”你是？“，即可得到正确响应。

DBeaver的使用

Sat, 01 Aug 2026 00:00:00 GMT

一、DBeaver是什么？#

DBeaver 是一款免费开源的通用数据库管理工具，支持几乎所有主流数据库。

DBeaver 就像是 Navicat 的免费替代品。因为Navicat 是收费的，想要免费使用就要破解，而破解就涉及侵权。所以，很多公司为了免费又不侵权，就选择使用DBeaver 来替代 Navicat 。
DBeaver 基于 Eclipse 开发，采用 Java 编写

二、DBeaver的使用#

1、连接数据库、创建库#

1.1 连接数据库#

步骤：

点击左上角 「新建数据库连接」 图标
选择数据库类型（如 MySQL）

新建连接-1
填写连接信息：
- 服务器地址：数据库服务器地址（localhost 表示本机）
- Port：MySQL默认 3306
- Database：数据库名（可选，连接后可选择）
- 用户名：数据库用户名（如：root）
- 密码：数据库密码
点击 「测试连接」 验证配置
首次连接会提示下载驱动，点击 「下载」
测试通过后点击 「完成」

新建连接-2

1.2 创建数据库#

方法一：右键菜单

在连接名下的数据库上右键 → 选择 「新建数据库」

新建数据库
填写数据库名、字符集、排序规则
- 数据库名：输入数据库名称，安装公司规范命名，公司没有相关规范，就按照通用规范，比如小写优先、下划线分割、命名反应业务等。
- 字符集：可以看你们别的库的字符集设置的什么，跟别的库保持一致的字符集。如果，没有其他可参考的库，推荐选择 utf8mb4
- 排序规则：同字符集，没有可参考的推荐选择 utf8mb4_general_ci 或 utf8mb4_unicode_ci
点击 「确定」

新建数据库-2

2、导出SQL脚本和执行SQL脚本#

2.1 导出SQL脚本（备份）#

步骤：

选中要导出的 数据库 或表
右键 → 「工具」 → 「转储数据库」

导出sql脚本-1
选择导出对象：

导出sql脚本-2
导出配置

该界面可以配置导出路径，导出文件名等，设置完之后点击开始。

导出sql脚本-3

💡 使用场景：

代码版本控制时导出表结构

环境迁移时导出完整数据

备份重要表数据

2.2 执行SQL脚本（导入）#

步骤：

选中目标 数据库
右键 → 「工具」 → 「恢复数据库」

导入sql脚本-1
选择要导入的 .sql 文件
点击 「开始」 开始导入

导入sql脚本-2

⚠️ 新人踩坑点：

大文件导入时内存不足，需要调整JVM参数

SQL文件编码不对导致中文乱码（确保UTF-8编码）

导入前确保选中了正确的数据库

3、新建表、修改表#

3.1 新建表#

步骤：

选中 数据库 → 右键 → 「新建表」
在表设计器中添加字段：

新建表

设置项	推荐设置
列名	般规范就是使用小写字母+下划线，如 user_name
数据类型	VARCHAR、INT、DATETIME 等，字段长度在类型后的括号里面设置，比如VARCHAR(50)
非空	主键不勾选
自增	一般主键ID勾选
默认值	如 CURRENT_TIMESTAMP
注释	添加字段注释
约束	这里设置主键字段

设置索引

新建索引
点击 「保存」 → 「执行」

常用数据类型：

1
-- 字符串
2
VARCHAR(255)      -- 变长字符串（推荐）
3
TEXT              -- 长文本
4
CHAR(1)           -- 固定长度（如：性别）
5

6
-- 数字
7
INT               -- 整数
8
BIGINT            -- 长整数（主键ID）
9
DECIMAL(10,2)     -- 金额字段
10
TINYINT(1)        -- 布尔值
11

12
-- 日期时间
13
DATETIME          -- 日期时间
14
TIMESTAMP         -- 时间戳（自动更新）
15
DATE              -- 日期

展开收起

💡 命名规范：

如果公司有命名规范就按照公司的命名规范。如果没有的话，就可以遵循如下一般规范即可。

表名：t_模块名 或 tb_模块名，如 t_user、tb_order
字段名：小写字母+下划线，如 user_name、create_time

3.2 修改表结构#

修改表字段，如果是开发环境、测试环境一般都可以直接修改。如果是生产环境在修改的时候，一定要确认清楚你们可不可以直接修改。如果不可以的话，确认需要走什么样的流程，然后按照流程去走。

进入设计视图：

选中表 → 右键双击 → 进入和新建表一样的界面，进行对应修改

修改表

⚠️ 注意：

修改已存在字段的类型可能导致数据丢失

删除字段前请确认没有代码在使用

修改表结构最好先备份！

4、数据筛选和排序#

数据筛选和过滤

5、执行SQL语句#

5.1 打开SQL编辑器#

打开sql编辑器

5.2 编写和执行SQL#

打开sql编辑器-2

⚠️ 新人踩坑点：

忘记加WHERE条件，导致全表更新/删除

选错库执行

SQL语句末尾没加分号

多行SQL时光标位置错误，执行了不该执行的语句

💡 安全习惯：

先SELECT查询确认

再UPDATE/DELETE修改

执行前检查WHERE条件

重要操作前备份数据

6、导出Excel、导入Excel#

DBeaver 本身不支持将表数据导出为Excel表格文件。不过可以导出为CSV文件，然后转成Excel文件。导入的文件如果是Excel文件，可以把Excel文件转成CSV文件，再导入。转换方式可以使用这个在线转行网站进行转行https://csvtoexcel.net/zh-cn/excel-to-csv

6.1 导出CSV#

步骤：

选中目标表 → 右键 → 导出数据

导出数据-1
选择导出格式：CSV

导出数据-3
点击 **「下一步」**到如下界面 → 设置保存位置、文件名

导出数据-2
点击 「下一步」 → 「继续」

6.2 导入CSV#

步骤：

选中目标表 → 右键 → 「导入数据」

导入数据-1
选择数据来源：CSV

导入数据-2
选择要导入的CSV文件

导入数据-3
配置字段映射：
- 确认Excel列与表字段的对应关系
- 设置数据类型转换
  
  导入数据-4
点击 「下一步」 → 「继续」

⚠️ 新人踩坑点：

Excel列顺序与表字段不匹配

日期格式转换失败

Excel中有合并单元格

数字字段包含非数字字符

💡 导入前检查：

确认列名与字段一致

检查数据格式（日期、数字）

删除空行和合并单元格

备份原数据

7、表数据截断和清空#

7.1 截断（TRUNCATE）#

特点：

重置自增ID
速度快（DDL操作）
不可回滚

步骤：

选中表 → 右键 →「工具」→ 「截断」
确认操作

截断

SQL语句：

1
TRUNCATE TABLE t_user;

7.2 删除表数据（DELETE）#

特点：

不重置自增ID
速度较慢（DML操作）
可回滚
可加WHERE条件

步骤：

打开表数据
全选数据（Ctrl+A）
按 Delete 键
保存操作

清空表

SQL语句：

1
-- 删除所有数据
2
DELETE FROM t_user;
3

4
-- 删除指定条件数据
5
DELETE FROM t_user WHERE create_time < '2024-01-01';

⚠️ 新人踩坑点：

混淆清空和删除，自增ID行为不同

操作前未备份，数据无法恢复

DELETE无WHERE条件，清空整表

💡 安全建议：

重要数据先备份（导出SQL或Excel）

确认使用清空还是删除

DELETE前务必检查WHERE条件

生产环境操作要谨慎

8、将表里面部分记录复制成sql语句#

当你需要把表里新增的记录或者表记录的更改以sql语句导出来的时候。

步骤：

选中你要操作的记录 → 「右键」
根据你的需求选择 Insert语句 或者 Update语句

将表里面部分记录复制成sql语句

推荐命名规范

类型	规范	示例
表名	t_模块名	t_user、t_order
字段名	小写+下划线	user_name、create_time
索引名	idx_字段名	idx_user_name
主键	id（自增）	id
外键	fk_关联表_字段	fk_order_user_id

Gradle的基本使用

Sat, 01 Aug 2026 00:00:00 GMT

一、什么是Gradle#

Gradle是一个构建工具，用于自动化项目的构建、测试、部署等过程。它使用一种基于Groovy或Kotlin的领域特定语言（DSL）来编写构建脚本，使得构建配置更加灵活和强大。

通俗来说，Gradle就像是一个智能的助手，你告诉它（通过编写构建脚本）你的项目需要如何编译、需要哪些依赖库、如何打包等，它就会按照你的指示自动完成这些任务。同时，它还能高效地处理任务之间的依赖关系，只执行必要的步骤，从而加快构建速度。

二、为什么有Maven了，还需要Gradle#

Maven 和 Gradle 的本质使命是一样的：帮你“一键”完成代码编译、测试、打包、发布、依赖管理。但 Maven 是 2004 年的“XML 老将”，Gradle 是 2012 年诞生的“DSL 新兵”，两者设计理念差异巨大，导致在大型、多模块、持续交付的场景下，Gradle 往往能更快、更省、更灵活。

一句话，Maven 能干的 Gradle 都能干，反之不行；当项目规模变大、构建速度、灵活性、持续集成成为瓶颈时，Gradle 就是“升级补丁”。

三、gradle项目的一般目录结构#

gradle目录结构

四、gradle项目常见操作#

1、打开gradle项目#

1）打开时选择当前工程下的build.gradle打开即可。打开后可能出现如下idea右侧无gradle工具栏的问题。此时可以按照如下操作

添加为gradle项目

2）打开完成后需要在idea的 Settings -> Building,Execution,Deployment -> Bulids Tools ->Gradle 中配置gradle

gradle设置本地仓库

2、引入依赖#

引入远程仓库依赖，gradle也是可以使用maven中央仓库的。

中央仓库的地址：https://mvnrepository.com/

1)、远程仓库存在的依赖，直接引入，刷新gradle

gradle的依赖是在build.gradle文件下的

1
dependencies {
2
implementation group: 'commons-beanutils', name: 'commons-beanutils', version: "${commonsbeanutilsVersion}"
3
}

这里面的版本是配置在gradle.properties文件里面的，这个文件定义的属性就是全局的！

1
commonsbeanutilsVersion         =1.9.4

implementation 是一个依赖配置（Dependency Configuration），用于声明依赖项，类似于maven在引入依赖的时候scope标签的值。配置项的可选值如下:

依赖配置	说明	典型应用场景
implementation	编译期和运行时使用，不传递依赖给其他模块。	推荐首选，用于声明绝大多数私有依赖，有助于加快编译和隐藏接口。
api	编译期和运行时使用，且会传递依赖。在Gradle 3.4+中引入，作用同已废弃的compile。	制作库时，需要向使用者暴露其依赖的第三方库接口。
compileOnly	仅在编译期需要，不打包到最终产物（如APK/JAR）。	编译时提供支持，但运行时由环境提供（如Servlet API）。
runtimeOnly	仅在运行时需要，编译期不需要。	数据库驱动等仅在运行时使用的库。
testImplementation	用于测试代码（src/test）的编译和运行，不参与主代码打包。	JUnit等测试框架。
debugImplementation	仅在构建 debug 变体时参与编译和打包。	仅需在调试模式下使用的工具（如LeakCanary）。
releaseImplementation	仅在构建 release 变体时参与编译和打包。

2）仓库不存在的依赖引入方式

1
dependencies {
2
    // 依赖lib目录下的某个jar文件，指定具体的jar文件使用files()
3
    implementation files('lib/xxx.jar')
4

5
    // 依赖lib目录下的所有以.jar结尾的文件
6
    //fileTree() 用于指定一个目录，并通过通配符规则批量匹配文件，适合依赖一个目录下的多个 JAR（无需逐个指定）
7
    implementation fileTree(dir: 'lib', includes: ['*.jar'])
8

9
    // 依赖lib目录下的除了xxx.jar以外的所有以.jar结尾的文件
10
    implementation fileTree(dir: 'lib', excludes: ['xxx.jar'], includes: ['*.jar'])
11
}

3、打包#

在build.gradle中通过如下方式设置打jar包或者war包

1
#打war的话，就把java换成war
2
apply plugin: 'java'

点击右侧gradle工具栏下的对应模块下build下的build按钮进行打包对应模块。

gradle打包

打完的包会在对应模块下的bulid目录下的libs目录下，如下图：

gradle-打jar包

Idea的基本使用

Sat, 01 Aug 2026 00:00:00 GMT

一、idea是什么？#

IDEA”常常特指 IntelliJ IDEA，这是一款功能强大的集成开发环境。它由JetBrains开发，尤其受Java开发者欢迎，以其智能代码补全、代码分析和重构功能而闻名。它也支持Kotlin、Python等多种语言和框架。IDEA正常情况下是需要破解才可以永久使用，按照网上破解教程破解即可！

二、idea常见操作#

1、打开一个工程#

1.1、按照下图打开一个工程

打开项目

1.2、选择要打开的工程，点击 Select Folder

打开项目2

1.3、根据当前工程类型选择对应的打开方式

打开项目3

有 pom.xml → Maven 工程
有 build.gradle / settings.gradle → Gradle 工程
有 .project + .classpath → Eclipse 工程
上面全没有，只有 src 文件夹 → 裸源码（普通 Java 工程）

2、设置当前工程的JDK版本#

如果当前工程的JDK版本为1.8，则以下几处地方均需要设置。

设置Project里面的JDK版本

Ctrl+Alt+Shift+S打开如下界面，设置工程的JDK版本。

设置JDK版本

设置Modules里面JDK版本

Ctrl+Alt+Shift+S打开如下界面，可以在下图界面设置工程里面对应模块的JDK版本。

设置JDK版本2

设置编译的JDK版本

设置JDK版本3

3、配置启动类#

启动类配置

4、插件的安装#

安装插件

5、添加Service窗口#

在SpringCloud项目中由于微服务模块很多,此时使用IDEA提供的Service界面可以很方便的可以看的当前工程下有哪些可启动模块，以及这些模块的运行状态和端口。还可以右击下面对应模块的启动类，选择 Jump to source 进入该启动类。

添加service窗口

首次添加可以使用Alt 8 快捷键，来添加service窗口，添加步骤如下：

添加service窗口2

添加service窗口3

6、当前文件里面查找、替换操作#

1）ctrl f 查找

查找当前文件内容

2）ctrl r 替换，也可以使用这个来查找

替换当前文件内容

7、全局查找、替换#

1）查找

ctrl shift f 全局文件查找，查找范围：整个项目/指定目录 全部文件（含源码、配置、XML、JS、MD…）

全局查找

双击 shift 查找文件, 这个搜索功能的范围几乎涵盖了整个 IDE 的内容，包括项目代码、菜单项、工具窗口、设置和更多。

全局查找2

2）ctrl shift r 替换，也可以使用这个来查找

全局替换

8、查看当前类、方法、变量在哪里使用#

1）查看类、方法使用处

光标放到你要查看的类或者方法上，按住ctrl键，再点击鼠标左击即可查看当前类或者方法在哪些地方使用。

查看类、方法引用

2）查看变量在哪里使用

鼠标左击变量即可，查看，该变量使用处。

查看变量使用处

9、查看当前类、方法、变量定义处#

光标放到你要查看的类、方法或者变量上，按住ctrl键，再点击鼠标左击即可调转到对应类、方法、变量定义的地方。如果调用的方法是接口里面的，则会跳转到对应接口里面，此时需要点击接口方法前的向下的箭头进入到对应的实现类里面的方法里面。

进入实现类方法

10、本地历史#

当你本地代码出现丢失的情况，此时通过版本控制工具比如git也无法找到的话。此时，就可以使用idea本地历史记录来查看记录的历史版本。

1）右击你需要查看的文件或者文件夹查看历史版本

本地历史记录

2）进入如下界面，按照下图指示，根据需要来恢复代码

本地历史记录2

11、格式化代码#

格式化代码可以使用快捷键 Ctrl Alt L。直接使用 Ctrl Alt L，默认格式化当前文件。如果当前文件不全是你写的，最好选中格式化的范围之后，再使用Ctrl Alt L进行代码格式化。否则，你可能会修改别人的代码，当你推送代码到远程仓库之后，后续你格式化别人的代码都会变成你写的，当这块代码出问题的时候，可能你会背锅！

格式化代码

12、快速生成for循环#

快速生成for循环

三、其他常用快捷键#

场景	高频键	作用一句话
最近文件	Ctrl+E	弹刚才打开过的文件列表
跳回/跳前	Ctrl+Alt+← / →	光标来回穿越文件
重命名	Shift+F6	重命名变量/类/包
万能修复	Alt+Enter	导包、类型转换、生成变量、实现类、实现方法等
生成代码	Alt+Insert	一键生成构造器、getter/setter、toString 等
包围代码	Ctrl+Alt+T	快速加 if/try/while/Runnable…
优化 import	Ctrl+Alt+O	删无用包、按规则排序
复制	Ctrl+D	不用剪贴板直接复制当前行
剪切	Ctrl+X	剪切

idea中如何debug调试代码

Sat, 01 Aug 2026 00:00:00 GMT

一、打断点的作用#

调试是程序员的基本功，当你在程序中打上断点之后，程序运行到断点处就会停下来，此时，你就可以通过跟踪代码的执行过程。让你能够更清晰的理解代码的执行逻辑，以及快速定位bug。使用debug调试的时候需要注意如下几点：

使用debug调试的时候，一定使用debug模式运行项目，这样断点才会生效！
正常情况下，项目在运行过程中新加断点是不需要重启项目即可生效的！
项目运行之后，如果在断点前新加了代码的话当前断点就会变成灰色，即不可用！此时需要重启项目灰色才会重新变成红色！
有时候在启动项目的时候，发现项目长时间卡在那里，一直未显示运行成功。此时，可以将所有断点取消调再重新启动！

二、调试工具栏常用按钮说明#

调试工具栏说明

三、断点的基本使用#

1、行断点#

行断点是我们经常使用的一种断点，顾名思义就是将断点，打到代码行上。打断点的方式也很简单，直接将光标移动到当前行代码左侧的行号上，单击鼠标左键即可。

行断点

2、方法断点(了解)#

方法断点顾名思义就是在方法声明行打断点，打断点的方式和行断点一样。

方法断点

3、字段断点（了解）#

字段断点，也就是字段声明行设置，用来监控字段访问或者修改的，打断点的方式和行断点一样。

字段断点

4、异常断点（了解）#

当使用异常断点的时候，再程序捕获异常的时候就会暂停。打异常断点的方式如下：

断点面板

进入断点面板，添加需要监控的异常信息

断点面板2

5、条件断点#

当循环里只停第N次或当变量==某值时，用条件断点就可以避免手点几百次的情况。

条件断点

6、多线程断点#

当我们在异步执行逻辑之外设置了普通断点后，程序执行到异步执行的方法时，此时只是打普通的断点是进不去异步方法逻辑里的，而是要按照下图打断点才行。
当涉及到并发执行某块逻辑的时候，由于多个线程同时运行，相互之间的执行顺序和状态变化较为复杂。如果我们想要跟踪每个并发线程的详细执行情况，或者希望精确控制线程的执行过程，也要按照下图打断点才行。

多线程断点使用

7、stream流断点（了解）#

在链式调用的 lambda 体内下断点，才能让我们窥见每一次元素流转的中间结果。使用方式其实也很简单，就直接在你需要监控的stream流前打断点即可。

stream流断点

下图即是stream流链面板：

stream流追踪面板

Linux系统的使用

Sat, 01 Aug 2026 00:00:00 GMT

为什么需要学习Linux系统的使用？

因为在真实工作中，很多中间件以及我们的应用服务，通常都是部署在 Linux 服务器 上，而不是 Windows 系统。所以，Linux 的常见操作是开发人员必须掌握的基础能力。

另外，Linux 的使用方式和 Windows 也不太一样。 Windows 更多是通过图形化界面进行管理，而 Linux 在实际工作中，更多是通过命令行来完成文件查看、日志排查、服务启动、进程管理等操作。

因此，想要更好地适应真实开发工作， Linux 的基本使用一定要会。

一、XShell 的使用#

1.1 什么是 XShell#

XShell 是一个强大的安全终端模拟软件，支持SSH1、SSH2、SFTP、TELNET等多种协议，用于远程连接Linux服务器。它是Java开发人员日常工作中不可或缺的工具。

1.2 安装#

1.3 连接服务器步骤#

第一步：创建新会话

打开 XShell，点击「文件」→「新建」
或直接点击工具栏的「新建」图标

第二步：配置连接信息

配置项	说明	示例
名称	会话名称（自定义，便于识别）	正常服务器少的话，直接填写IP即可
协议	连接协议	SSH
主机	服务器IP地址	192.168.1.100
端口	SSH端口	22（默认）

第三步：配置用户认证

点击左侧「用户身份验证」
输入用户名（如：root）

1
输入密码
点击「确定」连接

1

1.4 保存会话技巧#

建议按环境分类保存会话，方便管理：

1
XShell 会话管理
2
├── 生产环境
3
│   ├── 应用服务器1
4
│   ├── 应用服务器2
5
│   └── 数据库服务器
6
├── 测试环境
7
│   ├── 应用服务器
8
│   └── 数据库服务器
9
└── 开发环境
10
    └── 本地虚拟机

1.5 常见问题#

问题1：连接被拒绝

检查IP地址和端口是否正确
检查服务器SSH服务是否启动：systemctl status sshd
检查防火墙是否开放22端口

问题2：密码正确但无法登录

检查用户名是否正确
检查服务器是否开启了密码登录
联系运维人员确认账号状态

问题3：连接超时

检查网络连通性：ping 服务器IP telnet 服务器IP SSH端口
检查防火墙设置
确认SSH端口是不是默认端口22

问题4：中文乱码

将编码设置为 UTF-8

1

二、XFTP 的使用#

2.1 什么是 XFTP#

XFTP 是一个文件传输软件，用于在Windows和Linux之间安全地传输文件，支持SFTP、FTP等协议。通常与XShell配合使用。

2.2 安装#

2.3 连接服务器#

在已连接的XShell会话中，点击工具栏的「XFTP」图标，可以直接打开XFTP并自动连接到当前服务器，无需重复输入密码。

2.4 界面说明#

2.5 文件传输操作#

操作	方法	说明
上传	拖拽文件到右侧 / 选中后点击上传按钮	从本地上传文件到服务器
下载	拖拽文件到左侧 / 选中后点击下载按钮	从服务器下载文件到本地
新建文件夹	右键 → 新建文件夹	在当前目录创建文件夹
删除	右键 → 删除 / 选中后按Delete键	删除选中的文件或文件夹
重命名	右键 → 重命名 / 选中后按F2键	重命名文件或文件夹
编辑文件	右键 → 用记事本编辑	对文件内容进行编辑
修改权限	右键 → 更改权限	修改文件权限（chmod）

2.6 常用场景#

场景1：上传Java应用包

在左侧本地目录找到打包好的 .jar 文件
在右侧服务器目录切换到目标部署目录（如 /opt/app）
拖拽文件到右侧，或选中后点击「上传」按钮
等待传输完成

场景2：下载日志文件

在右侧服务器目录找到日志文件（如 /opt/logs/app.log）
在左侧本地目录选择保存位置
拖拽文件到左侧，或选中后点击「下载」按钮
等待传输完成

场景3：批量传输

选中多个文件（按住Ctrl键多选，或按住Shift键连续选）
拖拽或使用上传/下载按钮
可以看到批量传输进度

2.7 XShell 与 XFTP 配合使用#

在实际工作中，XShell和XFTP通常配合使用：

XShell 用于执行命令、查看日志、管理服务
XFTP 用于上传部署包、下载日志文件、修改配置文件

典型工作流程：

1
1. 使用XFTP上传应用包到服务器
2
   ↓
3
2. 使用XShell连接服务器，进入部署目录
4
   ↓
5
3. 使用XShell停止旧服务、备份旧版本
6
   ↓
7
4. 使用XShell启动新服务
8
   ↓
9
5. 使用XShell查看运行日志（tail -f）
10
   ↓
11
6. 如需下载日志分析，使用XFTP下载

三、常用命令#

3.1 目录结构#

Linux只有一个根目录 /，采用层级式的目录结构。

重要目录说明：

目录	说明
/bin -> /usr/bin	系统的可执行文件，可以在任何目录下执行
/usr/local/bin	用户自己的可执行文件，可以在任何目录下执行
/etc	存放配置文件，配置环境变量(/etc/profile)
/home	每一个用户的根目录，用来保存用户私人的数据，默认目录名和用户名相同
/opt	存放额外安装的软件，相当于Windows系统的Program Files目录
/var	存放经常变化的文件，如日志文件(/var/log)
/tmp	存放临时文件
/root	系统管理员（root用户）的根目录

目录结构图：

1
/
2
├── bin
3
├── etc
4
├── home
5
│   ├── user1
6
│   └── user2
7
├── opt
8
├── root
9
├── tmp
10
└── var

3.2 基本指令#

3.2.1 Linux服务器信息#

操作	命令	说明
查看IP地址	ifconfig 或 ip addr	查看服务器IP地址
查看系统性能	top	运行的进程和系统性能信息（CPU、内存等）
查看内存使用	free -h	以人类可读的方式显示内存使用情况
查看磁盘使用	df -h	查看各个分区的磁盘使用情况
查看系统版本	cat /etc/redhat-release	查看CentOS版本
查看内核版本	uname -r	查看Linux内核版本

防火墙相关操作：

Terminal window

1
# 查看防火墙状态
2
systemctl status firewalld
3

4
# 启动防火墙
5
systemctl start firewalld
6

7
# 停止防火墙
8
systemctl stop firewalld
9

10
# 开机自启动
11
systemctl enable firewalld
12

13
# 禁用开机自启动
14
systemctl disable firewalld

注意：所有的系统服务都可以使用 systemctl 进行管理，命令格式为：systemctl start|stop|status|restart [服务名]
有些版本的服务器可能使用 iptables 而不是 firewalld，两者都是设置和管理网络防火墙规则的工具。

开放端口操作（了解）：

Terminal window展开收起

1
# 开放3306端口（MySQL常用端口）
2
firewall-cmd --permanent --zone=public --add-port=3306/tcp
3

4
# 重新加载防火墙配置（必须执行，否则规则不生效）
5
firewall-cmd --reload
6

7
# 查看已开放的端口
8
firewall-cmd --zone=public --list-ports
9

10
# 查看防火墙所有规则
11
firewall-cmd --zone=public --list-all
12

13
# 移除已开放的端口
14
firewall-cmd --permanent --zone=public --remove-port=3306/tcp
15
firewall-cmd --reload

展开收起

3.2.2 文本编辑：vi/vim#

vi和vim是Linux中的文本编辑器，用来在Linux中创建、查看或者编辑文本文件，相当于Windows中的记事本。

三种模式：

1
一般模式（默认模式）
2
    ↓ 按 i 或 a
3
编辑模式
4
    ↓ 按 Esc
5
命令行模式（按 shift+: 进入）

模式	说明	常用操作
一般模式	打开文件的默认模式	gg：跳到文件首行G：跳到文件末行yy：复制当前行p：粘贴dd：删除当前行u：撤销
编辑模式	编辑文件内容	按 i 或 a 进入，可编辑文件内容
命令行模式	保存、退出、搜索等	按 : 进入，输入命令

常用命令：

命令	说明
	退出编辑器（未修改时）
!	不保存强制退出编辑器
	保存并且退出编辑器
	保存但不退出
nu	显示行号
nonu	取消行号
/搜索内容	搜索内容，小写 n 向下查找，大写 N 向上查找
?搜索内容	向上搜索内容

3.2.3 文件和目录操作#

1. 查看和切换目录

命令	说明
ll 或 ls -l	查看当前目录下所有目录和文件（详细信息）
ls	查看当前目录下所有目录和文件（简单列表）
ls -a	查看所有文件（包括隐藏文件）
pwd	显示当前所在目录的完整路径
cd /opt	切换到opt目录下（绝对路径）
cd ..	切换到上级目录
cd bin	切换到当前目录的bin目录下（相对路径）
cd ~	切换到当前用户的根目录
cd -	切换到上一次所在的目录

2. 创建和复制

命令	说明
mkdir data	在当前目录下创建目录data
mkdir -p data/mysql	递归创建目录（一次创建多级目录）
mkdir /opt/data	在opt目录下创建目录data
cp gateway.jar gateway-bak.jar	复制文件并重命名（备份常用）
cp -r dir1 dir2	递归复制目录
cp app.jar /opt/	复制文件到指定目录

3. 删除操作（⚠️ 谨慎使用）

命令	说明
rm file.txt	提示后删除文件
rm -f file.txt	强制删除文件（不提示）
rm -r data	提示后递归删除目录
rm -rf data	强制递归删除目录（不提示）

⚠️ 危险命令警告：rm -rf / 会删除整个系统的所有文件，千万不要执行！

4. 查看文件内容（Java开发常用）

命令	说明
cat file.txt	查看文件全部内容，一次性显示
more file.txt	分页查看文件内容，空格翻页，q退出
less file.txt	分页查看文件内容，支持上下翻页，q退出
head -n 50 file.log	查看文件前50行
tail -n 50 file.log	查看文件后50行
tail -f file.log	实时监控文件末尾内容（查看日志常用）
`tail -f file.log	grep error`
grep “mysql” file.log	查看文件中包含”mysql”的内容
grep -n “error” file.log	查看文件中包含”error”的内容，并显示行号
grep -i “error” file.log	忽略大小写搜索
grep -C 5 “error” file.log	显示匹配行及其前后5行

5. 查找文件

命令	说明
find / -name file.txt	从根目录查找名为file.txt的文件
find /opt -name “*.java”	查找opt目录下所有.java文件
find /opt -name “*.java” \| grep user	查找opt目录下名称包含user的.java文件
find /opt -type d -name “logs”	查找名为logs的目录

3.2.4 用户相关操作#

说明：在公司中，用户创建一般由运维人员负责，开发人员主要使用 su 切换用户命令。

命令	说明
useradd zhuoye	添加用户zhuoye（在/home目录下创建用户根目录）
useradd -d /home/zhuoyun zhuoye	创建用户并指定根目录
passwd zhuoye	给用户zhuoye设置密码
userdel zhuoye	删除用户zhuoye
id zhuoye	查看用户zhuoye的信息
su zhuoye	切换到用户zhuoye
su -	切换到root用户

用户切换说明：

从权限高的用户切换到权限低的用户：不需要密码验证
从权限低的用户切换到权限高的用户：必须密码验证

3.2.5 压缩和解压操作#

1. gzip/gunzip（单个文件）

命令	说明
gzip file.txt	压缩单个文件，生成.gz压缩包，并删除原文件
gunzip file.txt.gz	解压.gz压缩包，并删除原压缩包

2. zip/unzip（多个文件和目录）

命令	说明
zip archive.zip file1.txt file2.txt	把多个文件压缩为zip文件
zip -r archive.zip dir/	递归压缩目录
unzip archive.zip	解压zip文件到当前目录
unzip archive.zip -d /opt/data	解压zip文件到指定目录

3. tar（Java开发最常用）

命令	说明
tar -zcvf archive.tar.gz file1 file2 dir/	打包并压缩
tar -zxvf archive.tar.gz	解压到当前目录
tar -zxvf archive.tar.gz -C /opt/data	解压到指定目录

参数说明：

-z：使用gzip压缩/解压

-c：创建压缩包

-x：解压

-v：显示详细过程

-f：指定文件名（必须放在最后）

-C：指定解压目录

3.2.6 权限相关操作#

1. 修改文件所有者

命令	说明
chown zhuoye file.txt	修改文件的所有者为zhuoye用户
chown -R zhuoye data/	递归修改目录及其内部文件的所有者
chown zhuoye file.txt	同时修改所有者和所属组

2. 文件权限控制

命令	说明
chmod 777 file.txt	将文件权限设置为777（所有用户可读写执行）
chmod 755 file.txt	所有者可读写执行，其他用户可读执行
chmod 644 file.txt	所有者可读写，其他用户只读

权限说明：

Linux中每个文件或目录都有三部分权限：所有者权限、同组用户权限、其他组用户权限。

权限	r（读）	w（写）	x（执行）	数字表示
说明	可查看内容	可修改内容	可执行/进入目录	4 / 2 / 1

权限组合	说明	数字
rwx	读写执行	7 (4+2+1)
r-x	读和执行	5 (4+1)
r—	只读	4
---	无权限	0

权限表示示例：

1
-rwxr-xr--  file.txt
2
 ││││││││││
3
 │││││││││└─ 其他用户：只读(4)
4
 │││││││└──── 同组用户：读执行(5)
5
 │││││└─────── 所有者：读写执行(7)

3.2.7 进程管理（Java开发必备）#

命令	说明
`ps -ef	grep mysql`
`ps -ef	grep java`
jps	查看当前运行的Java进程（JDK自带，最常用）
lsof -i <3306>	查看占用3306端口的进程
`netstat -tunlp	grep 8080`
kill -9 PID	强制关闭指定PID的进程
kill -15 PID	正常关闭指定PID的进程

Java应用部署常用操作：

Terminal window展开收起

1
# 1. 查看Java进程
2
jps
3
# 或
4
ps -ef | grep java
5

6
# 2. 查看应用占用的端口
7
lsof -i :8080
8

9
# 3. 停止应用
10
kill -15 <PID>
11

12
# 4. 后台启动Java应用（常用）
13
nohup java -jar app.jar > app.log 2>&1 &
14

15
# 5. 查看应用日志
16
tail -f app.log

展开收起

3.2.8 软件包安装#

1. RPM包安装

命令	说明
rpm -ivh package.rpm	安装rpm包（i-安装，v-显示详情，h-进度条）
rpm -ivh —force package.rpm	强制安装
rpm -e package.rpm	卸载rpm软件包
rpm -qa \| grep java	查看已安装的软件

2. YUM安装（推荐）

命令	说明
yum install firefox	安装软件
yum list installed \| grep firefox	查看已安装的软件
yum remove firefox.x86_64	卸载软件
yum update	更新所有软件包
yum search keyword	搜索软件包

3.3 拓展指令#

3.3.1 文件上传下载#

命令	说明
rz -y	上传本地文件到Linux服务器（-y表示覆盖同名文件）
sz filename	下载服务器文件到本地电脑

说明：如果提示命令不存在，需要先安装：yum install lrzsz

3.3.2 执行可执行文件#

Terminal window

1
# 方式1：使用相对路径或绝对路径
2
./script.sh
3

4
# 方式2：使用sh命令
5
sh script.sh
6

7
# 方式3：使用bash命令
8
bash script.sh

3.3.3 网络相关（Java开发调试必备）#

命令	说明
ping www.baidu.com	测试网络连通性
telnet ip port	测试端口是否连通（如：telnet 192.168.1.100 3306）
curl http://api.example.com	测试HTTP接口
wget http://example.com/file.zip	下载文件

3.3.4 环境变量#

命令	说明
echo $JAVA_HOME	查看JAVA_HOME环境变量
echo $PATH	查看PATH环境变量
export JAVA_HOME=/opt/jdk11	临时设置环境变量
source /etc/profile	使配置文件生效

永久配置环境变量：

Terminal window

1
# 1. 编辑配置文件
2
vim /etc/profile
3

4
# 2. 在文件末尾添加
5
export JAVA_HOME=/opt/jdk11
6
export PATH=$JAVA_HOME/bin:$PATH
7

8
# 3. 使配置生效
9
source /etc/profile

四、实战练习#

4.1 日常操作流程练习#

任务：部署一个Java应用

Terminal window展开收起

1
# 1. 连接服务器（使用XShell）
2

3
# 2. 进入应用部署目录
4
cd /opt/app
5

6
# 3. 查看当前目录内容
7
ll
8

9
# 4. 查看是否有Java进程在运行
10
jps
11

12
# 5. 如果有旧进程，先停止（假设PID是12345）
13
kill -15 12345
14

15
# 6. 备份旧版本
16
cp app.jar app-bak-$(date +%Y%m%d).jar
17

18
# 7. 使用XFTP上传新版本app.jar到当前目录
19

20
# 8. 后台启动应用
21
nohup java -jar app.jar > app.log 2>&1 &
22

23
# 9. 查看启动日志
24
tail -f app.log
25

26
# 10. 确认启动成功后，按Ctrl+C退出日志查看（应用继续运行）

展开收起

4.2 问题排查练习#

问题1：应用无法启动

Terminal window

1
# 检查Java环境
2
java -version
3

4
# 检查端口是否被占用
5
lsof -i :8080
6

7
# 查看错误日志
8
tail -100 app.log | grep ERROR
9

10
# 检查磁盘空间
11
df -h

问题2：无法访问应用

Terminal window

1
# 检查应用是否运行
2
jps
3

4
# 检查端口监听
5
netstat -tunlp | grep 8080
6

7
# 检查防火墙
8
firewall-cmd --zone=public --list-ports
9

10
# 如果没有开放端口，添加端口
11
firewall-cmd --permanent --zone=public --add-port=8080/tcp
12
firewall-cmd --reload

Maven的基本使用

Sat, 01 Aug 2026 00:00:00 GMT

一、什么是maven#

Maven的主要作用是简化了Java项目的构建过程。它通过一个名为pom.xml的核心配置文件来管理项目的依赖关系、编译设置、打包和部署等操作。使用Maven，开发者不需要手动下载和管理依赖的jar包，只需在pom.xml文件中声明所需的依赖项及其版本，Maven会自动从仓库中下载并添加到项目中。

此外，Maven还提供了许多插件，支持项目的开发、测试、打包和部署等一系列活动。这些插件可以扩展Maven的功能，使其能够满足不同项目的需求。

总的来说，Maven是一个强大的自动化构建工具，它通过标准化的项目结构和生命周期管理，提高了开发效率，降低了项目维护的复杂性。

Maven

中央仓库的地址：https://mvnrepository.com/

二、maven的基本操作#

1、idea配置maven#

设置maven

需要注意的是，如果公司有使用私仓的话，settings.xml配置文件一定要使用包含私仓信息的，可以直接问同事要一份！

2、引入新的依赖#

2.1、依赖在远程仓库中#

maven仓库存在的依赖，直接引入，刷新maven即可

1
        <dependency>
2
            <groupId>org.springframework</groupId>
3
            <artifactId>spring-webmvc</artifactId>
4
            <version>5.1.6.RELEASE</version>
5
        </dependency>

groupld：用于定义当前Maven项目所隶属的组织名称，一般按照域名反写规则来确定，比如“com.zcloud”。 artifactld：用来定义当前Maven项目的名称，通常为具体的模块名称，比如“user-service”“admin-service”等。 version：用于设定当前项目的版本号。

2.2、依赖不在远程仓库中#

使用 system 作用域

将需要引入的jar包放到pom文件同级目录lib下，如果没有这个目录可以新建一个目录，然后使用如下方式引入，坐标信息自定义即可，但最后和jar包实际信息保持一致或者能够正确反映该jar包信息！

1
       <dependency>
2
            <groupId>com.alibaba</groupId>
3
            <artifactId>alicrypto-java-aliyun</artifactId>
4
            <version>1.0.4</version>
5
            <scope>system</scope>
6
            <systemPath>${project.basedir}/lib/alicrypto-java-aliyun-1.0.4.jar</systemPath>
7
       </dependency>

如果想要在打包的时候也要把本地system的jar包打进来的话，就需要在maven插件中配置一个includeSystemScope属性：

1
<plugin>
2
    <groupId>org.springframework.boot</groupId>
3
    <artifactId>spring-boot-maven-plugin</artifactId>
4
    <configuration>
5
      <!--设置为true，打包的时候把本地的system的jar包也打包进来-->
6
        <includeSystemScope>true</includeSystemScope>
7
    </configuration>
8
</plugin>

注：project.basedir 就是pom文件所在的目录。

scop标签的的值有下面几个：

compile	默认值，适用于所有阶段（测试、运行，编译）
provided	期望容器或使用者会提供这个依赖。如servlet-api.jar；适用于（测试，编译）
runtime	只在运行时使用，如 mysql的驱动jar
test	只在测试时使用，如 junit.jar
system	Maven不会在仓库中查找对应依赖，在本地磁盘目录中查找；适用于（编译，测试，运行）

安装到本地仓库

安装本地仓库直接使用如下命令安装即可！

Terminal window

1
mvn install:install-file -Dfile=alicrypto-java-aliyun-1.0.4.jar -DgroupId=com.alibaba -DartifactId=alicrypto-java-aliyun -Dversion=1.0.4 -Dpackaging=jar -DlocalRepositoryPath=D:\Learning_Document\Maven\repository

说明，-Dfile就是你需要安装的jar的路径，可以是绝对路径，也可以是当前命令执行目录下的相对路径。-DlocalRepositoryPath就是需要jar包需要安装到的maven本地仓库的路径！

如下图，就是在对应需要安装的jar包目录下打开cmd的执行成功的结果：

命令安装本地jar包

如下，在本地仓库对应目录存在我们安装的jar包，即是成功！

命令安装本地jar包-2

3、maven打包等功能说明#

maven工具栏

4、maven的多环境管理#

Maven 多环境管理能够实现多环境配置文件之间的灵活切换，以及对配置文件中不同环境变量值的精准替换。在一些公司的实际项目中会运用到这一功能，了解并知晓其存在即可，当所在公司采用这种方式时，能及时想到即可。当使用maven多环境管理功能的时候，在maven工具栏会出现Profiles项，如下图所示：

maven多环境管理

pom文件里面会有如下配置：

1
<project>
2
   <profiles>
3
        <profile>
4
            <id>dev</id>
5
            <dependencies>
6
                <dependency>
7
                    <groupId>org.springframework.boot</groupId>
8
                    <artifactId>spring-boot-devtools</artifactId>
9
                </dependency>
10
            </dependencies>
11
            #设置该配置为默认生效
12
            <activation>
13
                <activeByDefault>true</activeByDefault>
14
            </activation>
15
            <properties>
16
                <env>dev</env>
17
                <server.port>8081</server.port>
18
                <log.level>INFO</log.level>
19
            </properties>
20
        </profile>
21
        <profile>
22
            <id>prod</id>
23
            <properties>
24
                <env>prod</env>
25
                <server.port>9090</server.port>
26
                <log.level>WARN</log.level>
27
            </properties>
28
        </profile>
29
    </profiles>
30
</project>

展开收起

application.yml配置文件里面会有如下配置：

1
# 开发环境配置
2
server:
3
  # 服务器的HTTP端口，默认为8080
4
  port: ${server.port}
5
# 日志配置
6
logging:
7
  level:
8
    com.ruoyi: ${log.level}
9
    org.springframework: ${log.level}

5、maven的私服#

5.1 maven私服的介绍#

maven 私有仓库的搭建，通常都是使用 Nexus 这一主流工具。通过使用maven 私仓，我们为您能够构建专属于公司内部使用的依赖仓库。一方面，我们可以在这个私仓中高效管理公司自己开发的各类 Jar 包，实现内部组件的统一存储与版本管控；另一方面，还能将项目所需的中央仓库 Jar 包缓存到私仓中，既可以提升依赖下载的稳定性与速度，也能解决内网开发环境下的项目构建的需求。

maven私仓

上面有四个maven仓库类型，含义如下：

仓库类型	比喻	功能
maven-central (代理仓库)	海外代购仓库	代理Maven中央仓库，首次购买从国外运来，之后存在本地仓库，下次直接拿
maven-releases (宿主仓库)	公司正式产品仓库	存放公司正式发布的版本（打包时不带-SNAPSHOT）
maven-snapshots (宿主仓库)	公司测试产品仓库	存放公司正在开发的版本（打包时带-SNAPSHOT）
maven-public (组仓库)	总服务台	把上面三个仓库整合成一个统一入口，你只需要记住这个地址

5.2 maven私服的使用#

maven私服对于我们来说主要就是有以下两个常见的使用

发布jar包

直接点击maven工具栏的deploy发布即可！
引入jar包

maven私仓2

三、常见问题#

1、依赖冲突#

当两条依赖路径把同一个坐标的 jar 引了进来，但版本不同，JVM 只能选一个，于是“选错”的那个就把代码搞炸，这也就是依赖冲突。

1.1 如何查看依赖冲突#

命令的形式

不建议用，依赖多的时候，不好查找
```
1
mvn -Dverbose dependency:tree
```
使用插件 (建议使用该方式)

依赖冲突1

如果搜索插件的时候，没有任何结果的时候，可进行如下设置后，再进行搜索

依赖冲突2

安装完成之后，pom文件下方就会出现 Dependency Analyzer ，点击即可对当前pom文件引入的依赖进行分析。

maven-helper

1.2 解决依赖冲突#

1）使用maven的依赖传递原则来解决

路径最短优先原则

主要根据依赖的路径长短来决定引入哪个依赖

最先声明优先原则

如果两个依赖的路径一样，声明在前的则优先选择。

2）手动排除依赖

使用exclusion标签来排除依赖

1
      <dependency>
2
            <groupId>nl.basjes.parse.useragent</groupId>
3
            <artifactId>yauaa</artifactId>
4
            <exclusions>
5
                <exclusion>
6
                    <artifactId>commons-collections4</artifactId>
7
                    <groupId>org.apache.commons</groupId>
8
                </exclusion>
9
            </exclusions>
10
        </dependency>

可以自己手动在pom文件添加，也可以使用Maven Helper插件来快速排除依赖！

排除依赖

3）封装成rpc服务（了解）

当同一个Java程序里必须同时加载两份不兼容的 jar包的时候，这个时候只能把其中一方单独拆成一个RPC服务，主应用通过 Feign/Dubbo/gRPC等进行远程调用！

2、maven的pom文件未被正确识别#

pom文件为蓝色的m标识的时候，为正确识别。

pom文件识别

未被识别的时候，右击pom文件点击 Add as Maven Project 添加为maven工程：

pom文件识别2

3、maven工具栏消失#

未启用maven插件

maven工具栏消失

pom文件未被正确识别

maven工具栏消失2

4、依赖未正确加载#

依赖未正确加载

Navicat的使用

Sat, 01 Aug 2026 00:00:00 GMT

一、Navicat是什么？#

Navicat 是一款数据库管理可视化工具，不是数据库本身。

打个比方：

Navicat 就像是 Xshell，是连接数据库的工具
MySQL 就像是 Linux服务器，是真正的数据库服务

⚠️ 常见误区：很多新人误以为Navicat就是数据库，其实它只是一个管理工具，就像用Xshell连接Linux服务器一样。

二、Navicat的使用#

1、连接数据库、创建库#

1.1 连接数据库#

步骤：

点击左上角 「连接」 按钮
选择数据库类型（如 MySQL）

新建数据库连接-1
填写连接信息：
- 连接名：自定义名称，方便识别，最好包含IP信息，方便通过连接名就可以知道对应的服务器的IP是什么（如：本地测试库-127.0.0.1、生产环境库-10.3.8.221）
- 主机：数据库服务器地址（localhost 或 127.0.0.1 表示本机，如果不是本机，就填写对应服务器的ip）
- 端口：MySQL默认 3306
- 用户名：数据库用户名（如：root）
- 密码：数据库密码
点击 「测试连接」 验证配置是否正确
点击 「确定」 完成连接

新建数据库连接

1.2 创建数据库#

方法一：右键菜单

在连接名上右键 → 选择 「新建数据库」
填写数据库信息：
- 数据库名：输入数据库名称，安装公司规范命名，公司没有相关规范，就按照通用规范，比如小写优先、下划线分割、命名反应业务等。
- 字符集：可以看你们别的库的字符集设置的什么，跟别的库保持一致的字符集。如果，没有其他可参考的库，推荐选择 utf8mb4
- 排序规则：同字符集，没有可参考的推荐选择 utf8mb4_general_ci 或 utf8mb4_unicode_ci
点击 「确定」

新建数据库

2、导出SQL脚本和执行SQL脚本#

2.1 导出SQL脚本（备份表结构/数据）#

步骤：

选中要导出的 数据库 或表
右键 → 选择 「转储SQL文件」
选择导出范围：
- 结构和数据：导出表结构+所有数据（完整备份）
- 仅结构：只导出表结构（不包含数据）
选择保存位置，点击 「保存」

转储sql

💡 使用场景：

部署到新环境时导出表结构

数据迁移时导出结构和数据

备份重要数据

2.2 执行SQL脚本（导入）#

步骤：

选中目标 数据库
「右键」 → 「运行SQL文件」

执行sql脚本-1

选择本地要执行的 .sql 文件
点击 「开始」 执行导入
等待导入完成，点击 「关闭」

执行sql脚本-2

⚠️ 注意：

导入前未选中目标数据库，导致找不到表

SQL文件编码不对，导致中文乱码

大文件导入超时，需要调整 max_allowed_packet 参数

3、新建表、修改表#

3.1 新建表#

步骤：

选中 数据库 → 「新建表」

新建表

在如下界面，设置新建表的字段、索引、注释等。设置字段的时候不要有空格等特殊字符！

新建表2

新建表界面部分内容说明

在设计视图中添加字段说明：

设置项	说明	常用选项
名	字段名称	一般规范就是使用小写字母+下划线，如 user_name
类型	数据类型	VARCHAR、INT、DATETIME、DECIMAL 等
长度	字段长度	VARCHAR常用255、500、1000
小数点	小数位数	DECIMAL类型使用，如 DECIMAL(10,2)
不是null	是否允许NULL	主键字段通常不勾选,因为主键字段本身就不会为NULL
主键	设为主键	通常设为自增ID
自增	自动增长	主键ID勾选此项
默认值	默认值	如当前时间、0等

设置索引

设置索引
点击 「保存」（或 Ctrl+S），填写表名。

填写表名

常用字段类型参考：

1
-- 字符串
2
VARCHAR(255)      -- 变长字符串
3
TEXT              -- 长文本
4

5
-- 数字
6
INT               -- 整数
7
BIGINT            -- 长整数
8
DECIMAL(10,2)     -- 金额字段
9

10
-- 日期时间
11
DATETIME          -- 日期时间
12
TIMESTAMP         -- 时间戳
13
DATE              -- 日期
14
TIME              -- 时间
15

16
-- 其他
17
TINYINT(1)        -- 布尔值（0或1）

展开收起

💡 命名规范：
如果公司有命名规范就按照公司的命名规范。如果没有的话，就可以遵循如下一般规范即可。

表名：t_模块名 或 tb_模块名，如 t_user、tb_order

字段名：小写字母+下划线，如 user_name、create_time

3.2 修改表结构#

进入设计视图：

选中表 → 右键 → 「设计表」

常见修改操作：

操作	步骤
添加字段	在最后空白行直接输入
修改字段	直接修改类型、长度等
删除字段	选中字段 → 右键 → 「删除字段」
调整顺序	选中字段 → 拖动到目标位置

⚠️ 注意：

修改已存在字段的类型可能导致数据丢失

删除字段前请确认没有代码在使用

修改表结构最好先备份！

4、数据筛选和排序#

数据筛选和排序

5、执行SQL语句#

选中数据库 → 点击顶部 「查询」 → 「新建查询」,然后在如下界面写要执行的sql点击运行即可！

执行sql语句

⚠️ 新人踩坑点：

忘记加WHERE条件，导致更新/删除了全部数据！

没有先SELECT查询，直接执行UPDATE/DELETE

💡 安全操作习惯：

先SELECT查询确认数据

再UPDATE/DELETE修改

执行前务必检查WHERE条件

6、导出Excel、导入Excel#

6.1 导出Excel#

步骤：

选中你要导出的表右键 → 「导出向导」

导出excel-1
选择导出格式：Excel 文件

导出excel-2
选择要导出的表以及要导出的目录。默认就是第一步你选中的那个表，不需要重新设置要导出的表或者也不需要添加其他要导出的表，就直接下一步即可。

导出excel-3
选择要导出的字段（可全选或部分选择），点击 「下一步」

导出excel-4
点击 「下一步」→直到如下界面，点击 「开始」

导出excel-5

其他导出格式：

Excel 文件（*.xlsx）
CSV 文件
JSON 文件
XML 文件

💡 使用场景：

导出数据给业务人员核对

生成报表进行分析

数据迁移

6.2 导入Excel#

步骤：

选中目标表 → 右键 → 「导入向导」

导入excel-1
选择导入格式：Excel 文件

导入excel-2
选择要导入的Excel文件

导入excel-3
设置开始导入行、时间格式等信息

导入excel-4
下一步到如下界面，配置字段映射（Excel列 ↔ 表字段）

导入excel-5
设置导入模式

导入excel-6
点击 「开始」 执行完成点击 「关闭」

导入excel-7

⚠️ 新人踩坑点：

Excel列顺序与表字段不匹配，导致数据错乱

Excel数据类型与字段类型不一致

Excel中有空行，导入失败

💡 导入前检查：

确认Excel列名与表字段一致

检查数据格式（日期、数字等）

删除Excel中的空行

7、表数据截断和清空#

清空和截断表

这两个操作都会清空表中所有数据，但有以下区别：

7.1 截断表（TRUNCATE）#

特点：

重置自增ID
速度快（不记录日志）
不可回滚

步骤：

选中表 → 右键 → 「截断表」
确认操作

SQL语句：

1
TRUNCATE TABLE t_user;

7.2 清空表（DELETE）#

特点：

不重置自增ID
速度较慢（逐行删除，记录日志）
可回滚
可加WHERE条件删除部分数据

步骤：

选中表 → 右键 → 「清空表」
确认操作

SQL语句：

1
-- 删除所有数据
2
DELETE FROM t_user;
3

4
-- 删除指定条件数据
5
DELETE FROM t_user WHERE create_time < '2024-01-01';

⚠️ 新人踩坑点：

混淆清空和删除，导致自增ID不符合预期

操作前未备份数据，数据无法恢复

误操作清空了生产环境数据

💡 安全建议：

重要数据先备份（导出SQL或Excel）

测试环境先验证

确认使用清空还是删除

清空前先SELECT确认数据量

8、将表里面部分记录复制成sql语句#

当你需要把表里新增的记录或者表记录的更改以sql语句导出来的时候。

步骤：

选中你要操作的记录 → 「右键」
根据你的需求选择 Insert语句 或者 Update语句

将表里面部分记录复制成sql语句

推荐命名规范

类型	规范	示例
表名	t_模块名	t_user、t_order
字段名	小写+下划线	user_name、create_time
索引名	idx_字段名	idx_user_name
主键	id（自增）	id
外键	fk_关联表_字段	fk_order_user_id

Postman的使用

Sat, 01 Aug 2026 00:00:00 GMT

一、Postman是什么？#

Postman是一款强大的API开发与测试工具，在Java后端开发中主要用于模拟HTTP客户端，用来调试和测试你开发的RESTful API或WebService接口。

它的重要性在于：

独立验证：不依赖前端页面，单独测试后端接口的请求、响应、业务逻辑和异常处理是否正确。
问题排查：快速定位问题是出在前端调用、网络传输还是后端服务本身。
协作与文档：生成并分享接口文档和测试用例，方便团队协作。

官网下载地址：https://www.postman.com/downloads/

二、Postman的基本使用#

1、登录#

Postman是需要登录的，如果不登录，则无法使用Postman的更多功能。比如，保存请求，创建工作空间等功能都无法使用。登录的时候会跳转默认浏览器。如果跳转的默认浏览器不是谷歌浏览器的话，可以按照下图点击 copy the URL 将登录路径复制到谷歌浏览器登录即可！

2、界面介绍#

Postman的主界面主要包含以下几个部分：

界面介绍

区域	功能说明
请求区	设置请求方法（GET/POST等）、URL、参数、Headers、Body等
响应区	查看服务器返回的响应数据、状态码、响应时间等
侧边栏	管理Collections（集合）、Environments(环境变量)、History（历史记录）等

3、新建工作空间#

通过新建工作空间，可以对请求接口做分类管理。比如你可以去一家公司就新建一个工作空间。当然，你也可以每一个项目就新建一个工作空间。

新建工作空间

进入如下界面，填写，工作空间名称、描述、可见性等信息。

新建工作空间2

4、新建集合#

新建集合，也可以简单的理解就是建立目录。跟目录不同的是，集合他可以独立导出、生成文档、Mock 与自动化测试。通过合理的目录结构，可以清晰、有序地对接口请求进行分类管理。若你的工作空间以公司维度划分，则集合可直接用项目名称命名；其下再按功能模块细分子目录。若工作空间已按项目维度隔离，则集合无需再出现项目名，直接以功能模块命名即可。

新建集合

5、新建请求#

新建请求

出出现如下界面

新建请求2

注意：在 Postman 里，只要新建或修改了请求，不保存就等于“本地草稿”。不ctrl s保存，变更不会上传到云端，账号里仍是旧版本；换电脑、重新登录后，看到的只能是上次保存时的状态——新改的内容全没了。

5.1 GET请求#

GET请求用于从服务器获取数据，参数通常通过URL传递。

GET请求

URL参数设置方式：

方式一：直接在URL中拼接参数

1
http://localhost:81/dev-api/system/user/list?pageNum=1&pageSize=10

方式二：使用Params面板（推荐）

点击 Params 按钮
在Key-Value表格中输入参数名和值
Postman会自动拼接到URL中

2.2 POST请求#

POST请求用于向服务器提交数据，数据通常放在请求体（Body）中。

类型	使用场景	示例
form-data	文件上传、表单提交	multipart/form-data
x-www-form-urlencoded	普通表单提交	键值对格式
raw	JSON/XML等格式数据	application/json
binary	二进制文件上传	文件流

JSON格式请求(最常用）：

JSON请求体

文件上传，一般使用form-data：

form-data

2.3 PUT请求#

PUT请求用于更新资源，用法与POST类似，数据也放在Body中。

2.4 DELETE请求#

DELETE请求用于删除资源，通常参数通过URL传递。

6、请求Headers设置#

有些接口需要特定的请求头，如Content-Type、Authorization等。

步骤：

点击 Headers 标签
添加Key-Value对

Headers设置

常用请求头：

Header	说明	示例值
Content-Type	请求内容类型	application/json
Authorization	认证信息	Bearer xxxxx
Accept	期望的响应类型	application/json
Token	自定义令牌	xxxxx

7、环境变量管理#

环境变量可以让同一套请求在不同环境（开发、测试、生产）下快速切换。

7.1 创建环境#

创建环境

7.2 使用环境变量#

在URL、Params、Headers中使用 {{变量名}} 格式：

1
{{baseUrl}}/api/user/list

使用环境变量

注意：创建完环境变量之后，一定要ctrl s保存一下。否则，可能在使用该环境变量的时候出现无法使用的情况！

8、导出、导入功能#

导出、导入功能。可以让你很方便的将别人新建好的接口请求，导入到你自己的postman里面。

5.1 导出#

导出

进入如下界面,点击 Export,便可以导出一份json文件。

导出2

5.2 导入#

拿到上一步导出的json文件，按照下图在对应工作区间导入即可！

导入

9、代码生成#

Postman可以生成各种语言的调用代码，方便直接复制到项目中。

点击请求右侧的 </> 图标
选择目标语言（如 Java - OkHttp）
复制生成的代码

代码生成

10、复制key-vlaue参数#

复制参数-1

进入如下界面复制即可。

复制参数-2

五、常见问题#

1、CORS跨域问题#

Postman作为独立工具，不受浏览器同源策略限制，不会出现CORS问题。这是Postman相比浏览器直接请求的优势。

2、SSL证书验证#

如果接口使用自签名证书，可以设置中关闭SSL验证

关闭ssl

3、请求超时#

默认超时时间为0（无限），可以在设置中修改：

Settings → Request timeout in ms

4、中文乱码#

响应出现中文乱码时：

检查响应Headers中的Content-Type
确保包含 charset=utf-8

Swagger的使用

Sat, 01 Aug 2026 00:00:00 GMT

一、Swagger是什么？为什么需要Swagger？#

1、Swagger是什么#

Swagger是一款RESTful API文档自动生成和测试工具，在Java后端开发中主要用于自动生成API接口文档，并提供在线测试接口的功能。

简单的说，Swagger就是帮你的接口自动生成文档的工具。以前写接口需要手动写Word文档或者Excel表格来记录接口地址、参数、返回值等，现在只需要在代码上加几个注解，Swagger就能自动生成漂亮的网页版接口文档。

官方网站：https://swagger.io/

2、为什么需要Swagger#

对个人开发：

不用手写文档：通过注解自动生成接口文档，大大减少文档编写工作量
在线测试：直接在浏览器中测试接口，不需要打开Postman等额外工具
文档与代码同步：代码变了，文档自动更新，不会出现文档过时的问题

对团队协作：

前端同事很高兴：前端开发人员可以直接查看接口文档，了解接口参数和返回值
提高沟通效率：不用反复问”这个接口什么参数？”、“这个接口返回什么？”
便于接口交接：新入职的同事可以通过Swagger文档快速了解项目接口

二、Swagger的基本使用#

1、Swagger版本区分（了解）#

工作中常见的是以下几种情况：

版本	Swagger路径	注解包	说明
Swagger 2	/swagger-ui.html	io.swagger.annotations	老版本
Swagger 3	/swagger-ui/index.html	io.swagger.v3.oas.annotations	新版本，也叫 OpenAPI 3.0
Swagger 3（兼容模式）	/swagger-ui/index.html	io.swagger.annotations	使用Swagger 2注解，生成Swagger 3文档 ✅
Knife4j（Swagger 2增强版）	/doc.html	io.swagger.annotations	中文增强版，界面美观，国内常用
Knife4j（Swagger 3增强版）	/doc.html	io.swagger.v3.oas.annotations	基于Swagger 3的增强版

如何快速判断项目用的是Swagger 2还是Swagger 3？

看访问地址：

/swagger-ui.html → Swagger 2
/swagger-ui/index.html → Swagger 3 ✅
/doc.html → Knife4j（增强版）

什么是Knife4j？

Knife4j 是 Swagger 的中文增强版，主要特点：

界面更美观：全新的UI设计，比原生Swagger更好看
中文友好：原生支持中文，无需额外配置
功能增强：增加了很多实用功能，如离线文档、接口排序等
国内流行：在国内项目中使用非常广泛

Knife4j 本质上是 Swagger 的皮肤增强，底层还是 Swagger，只是界面更好看。

本节以**Swagger 3（兼容模式）**为主进行讲解。

什么是”兼容模式”？

使用 Swagger 2 的注解（@Api, @ApiOperation 等）
生成 Swagger 3 的文档（OpenAPI 3.0 规范）

这样写的好处：可以继续用熟悉的 Swagger 2 注解，享受 Swagger 3 的新特性。

2、引入Swagger依赖（了解）#

使用Swagger 3（兼容模式，推荐用于Spring Boot 2.x）

在pom.xml中添加依赖：

1
<!-- Springfox Swagger 3.0 -->
2
<dependency>
3
    <groupId>io.springfox</groupId>
4
    <artifactId>springfox-boot-starter</artifactId>
5
    <version>3.0.0</version>
6
</dependency>

其他版本参考：

Swagger 2（老版本）：

1
<dependency>
2
    <groupId>io.springfox</groupId>
3
    <artifactId>springfox-swagger2</artifactId>
4
    <version>2.9.2</version>
5
</dependency>
6
<dependency>
7
    <groupId>io.springfox</groupId>
8
    <artifactId>springfox-swagger-ui</artifactId>
9
    <version>2.9.2</version>
10
</dependency>

Knife4j（Swagger增强版，推荐）：

1
<!-- Knife4j 3.x（基于Swagger 2，适用于Spring Boot 2.x）-->
2
<dependency>
3
    <groupId>com.github.xiaoymin</groupId>
4
    <artifactId>knife4j-spring-boot-starter</artifactId>
5
    <version>3.0.3</version>
6
</dependency>
7

8
<!-- Knife4j 4.x（基于Swagger 3，适用于Spring Boot 2.x/3.x）-->
9
<dependency>
10
    <groupId>com.github.xiaoymin</groupId>
11
    <artifactId>knife4j-openapi3-jakarta-spring-boot-starter</artifactId>
12
    <version>4.1.0</version>
13
</dependency>

Springdoc OpenAPI（用于Spring Boot 3.x）：

1
<dependency>
2
    <groupId>org.springdoc</groupId>
3
    <artifactId>springdoc-openapi-starter-webmvc-ui</artifactId>
4
    <version>2.8.14</version>
5
</dependency>

3、配置Swagger(了解)#

创建配置类，配置Swagger的基本信息。

RuoYi-Vue项目中的SwaggerConfig配置（实际使用）：

1
package com.zcloud.web.core.config;
2

3
import java.util.ArrayList;
4
import java.util.List;
5
import org.springframework.beans.factory.annotation.Value;
6
import org.springframework.context.annotation.Bean;
7
import org.springframework.context.annotation.Configuration;
8
import io.swagger.annotations.ApiOperation;
9
import io.swagger.models.auth.In;
10
import springfox.documentation.builders.ApiInfoBuilder;
11
import springfox.documentation.builders.PathSelectors;
12
import springfox.documentation.builders.RequestHandlerSelectors;
13
import springfox.documentation.service.ApiInfo;
14
import springfox.documentation.service.ApiKey;
15
import springfox.documentation.service.AuthorizationScope;
16
import springfox.documentation.service.Contact;
17
import springfox.documentation.service.SecurityReference;
18
import springfox.documentation.spi.DocumentationType;
19
import springfox.documentation.spi.service.contexts.SecurityContext;
20
import springfox.documentation.spring.web.plugins.Docket;
21

22
/**
23
 * Swagger3的接口配置
24
 * 虽然使用Swagger 2的注解（@ApiOperation等），但生成的是Swagger 3（OpenAPI 3.0）文档
25
 */
26
@Configuration
27
public class SwaggerConfig {
28

29
    /** 是否开启swagger */
30
    @Value("${swagger.enabled}")
31
    private boolean enabled;
32

33
    /** 设置请求的统一前缀 */
34
    @Value("${swagger.pathMapping}")
35
    private String pathMapping;
36

37
    /**
38
     * 创建API
39
     */
40
    @Bean
41
    public Docket createRestApi() {
42
        return new Docket(DocumentationType.OAS_30)  // ← OAS_30表示Swagger 3
43
                .enable(enabled)
44
                .apiInfo(apiInfo())
45
                .select()
46
                // 扫描所有有@ApiOperation注解的方法（Swagger 2注解风格）
47
                .apis(RequestHandlerSelectors.withMethodAnnotation(ApiOperation.class))
48
                .paths(PathSelectors.any())
49
                .build()
50
                /* 设置安全模式，支持token认证 */
51
                .securitySchemes(securitySchemes())
52
                .securityContexts(securityContexts())
53
                .pathMapping(pathMapping);
54
    }
55

56
    /**
57
     * 安全模式，token通过Authorization请求头传递
58
     */
59
    private List<SecurityScheme> securitySchemes() {
60
        List<SecurityScheme> apiKeyList = new ArrayList<>();
61
        apiKeyList.add(new ApiKey("Authorization", "Authorization", In.HEADER.toValue()));
62
        return apiKeyList;
63
    }
64

65
    /**
66
     * 安全上下文
67
     */
68
    private List<SecurityContext> securityContexts() {
69
        List<SecurityContext> securityContexts = new ArrayList<>();
70
        securityContexts.add(
71
                SecurityContext.builder()
72
                        .securityReferences(defaultAuth())
73
                        .operationSelector(o -> o.requestMappingPattern().matches("/.*"))
74
                        .build());
75
        return securityContexts;
76
    }
77

78
    /**
79
     * 默认的安全上引用
80
     */
81
    private List<SecurityReference> defaultAuth() {
82
        AuthorizationScope authorizationScope = new AuthorizationScope("global", "accessEverything");
83
        AuthorizationScope[] authorizationScopes = new AuthorizationScope[1];
84
        authorizationScopes[0] = authorizationScope;
85
        List<SecurityReference> securityReferences = new ArrayList<>();
86
        securityReferences.add(new SecurityReference("Authorization", authorizationScopes));
87
        return securityReferences;
88
    }
89

90
    /**
91
     * 添加摘要信息
92
     */
93
    private ApiInfo apiInfo() {
94
        return new ApiInfoBuilder()
95
                .title("若依管理系统_接口文档")
96
                .description("用于管理集团旗下公司的人员信息")
97
                .contact(new Contact("若依", null, null))
98
                .version("版本号:3.9.1")
99
                .build();
100
    }
101
}

展开收起

配置说明：

DocumentationType.OAS_30：这是Swagger 3（OpenAPI 3.0规范）
RequestHandlerSelectors.withMethodAnnotation(ApiOperation.class)：扫描@ApiOperation注解（Swagger 2注解风格）
securitySchemes()：配置Token认证

配置文件（application.yml）：

1
# Swagger配置
2
swagger:
3
  # 是否开启swagger
4
  enabled: true
5
  # 请求前缀
6
  pathMapping: /dev-api

4、访问Swagger UI#

只需要启动后端项目，无需启动前端项目，就可以在浏览器中访问Swagger UI界面。

swagger界面

不同版本的访问地址：

版本	Swagger路径	判断依据	特点
Swagger 2	/swagger-ui.html	地址中没有 index.html	老版本，界面较简陋
Swagger 3	/swagger-ui/index.html	地址中有 index.html	新版本，功能更强
Knife4j	/doc.html	地址是 doc.html	增强版，界面美观，中文友好 ✅

如何快速记住：

看到 swagger-ui/index.html → Swagger 3
看到 swagger-ui.html → Swagger 2
看到 doc.html → Knife4j（增强版）✅

访问地址的构成说明（重点）：

实际工作中，访问地址需要根据项目配置来拼接：

1
http://[域名或IP]:[端口][项目前缀][Swagger路径]

如何找到正确的访问地址：

确认项目端口：查看application.yml中的server.port
确认项目前缀：查看application.yml中的server.servlet.context-path
在地址后加上 /swagger-ui/index.html（Swagger 3）

当然，有时候，Swagger路径也可以改的！正常情况，如果更改的话就是在项目配置文件里面去配置这个路径！如果默认路径都无法访问的话，就去配置文件里面去看，有没有自定义swagger路径。

5、常用注解（了解）#

Swagger 3（兼容模式）使用 Swagger 2 的注解风格。了解就行，不同版本注解可能有差异，需要使用的时候对应看别人代码用的什么注解就行！

常用注解：

注解	使用位置	作用
@Api	Controller类	标识接口分组，描述模块功能
@ApiOperation	方法	描述接口的具体功能
@ApiModel	实体类	描述实体类的信息
@ApiModelProperty	字段	描述字段的信息

三、Swagger的高级配置（了解）#

1、环境控制#

通常只在开发环境和测试环境启用Swagger，生产环境需要禁用。

项目中的配置：

application.yml

1
swagger:
2
  # 是否开启swagger
3
  enabled: true

通过配置文件控制（推荐）：

1
# application-dev.yml（开发环境）
2
swagger:
3
  enabled: true
4

5
# application-prod.yml（生产环境）
6
swagger:
7
  enabled: false

2、Token认证配置#

通过Authorization请求头传递token。

配置方式（已在SwaggerConfig中配置）：

1
/**
2
 * 安全模式，token通过Authorization头请求头传递
3
 */
4
private List<SecurityScheme> securitySchemes() {
5
    List<SecurityScheme> apiKeyList = new ArrayList<>();
6
    apiKeyList.add(new ApiKey("Authorization", "Authorization", In.HEADER.toValue()));
7
    return apiKeyList;
8
}

使用方式：

登录后获取token
在Swagger UI界面点击右上角的 Authorize 按钮
输入：Bearer {token} 或直接输入 {token}
之后所有接口请求都会自动带上这个请求头

四、在Swagger中测试接口#

1、测试GET请求#

步骤：

点击接口名称，展开接口详情
点击 Try it out 按钮
填写请求参数（如果有）
点击 Execute 执行请求
查看响应结果

get请求

2、测试POST请求#

步骤：

点击接口名称，展开接口详情
点击 Try it out 按钮
在Request body中填写JSON格式的请求数据
点击 Execute 执行请求
查看响应结果

post请求

3、设置Token认证#

步骤：

使用登录接口或者token或者登录对应前端平台F12获取别的接口传的Token
点击页面右上角的 Authorize 按钮

获取token
输入token，点击 Authorize 确认

获取token2

MDX 格式文章示例

Fri, 02 Jan 1970 00:00:00 GMT

Tip

Firefly 支持 MDX 和 Markdown 两种类型的文章，你可以在文章中混合使用两种格式，如果没有特别复杂内容和需求，推荐使用 Markdown 格式就够了。

Markdown 和 MDX 的区别#

Markdown (MD) 是一种轻量级标记语言，允许用户使用纯文本格式编写文档，然后将其转换为格式化的HTML。它因其简洁易用的语法而广受欢迎，特别适合编写文档和博客文章。
MDX 是一种扩展了 Markdown 语法的格式，允许在 Markdown 文档中无缝地插入 JSX 代码。通过 MDX，用户可以在文档中嵌入 React 组件，从而实现更丰富的交互性和动态性。

特性	Markdown	MDX
基础语法	支持 (CommonMark)	支持 (CommonMark)
HTML 标签	支持	支持 (作为 JSX)
组件导入	不支持	支持 (import)
动态数据	不支持	支持 (JS 表达式)
样式定制	有限 (class/style)	灵活 (className/CSS-in-JS)

使用组件#

这是一个图标组件：

1
import { Icon } from 'astro-icon/components'
2

3
<div class="flex items-center gap-2 my-4">
4
  <Icon name="fa7-solid:rocket" class="text-4xl text-red-500" />
5
  <span>火箭发射！</span>
6
</div>

火箭发射！

使用 JSX#

你也可以直接写 HTML/JSX：

1
<div className="p-4 bg-blue-100 dark:bg-blue-900 rounded-lg my-4">
2
  这是一个自定义样式的 div 块，使用了 Tailwind CSS 类。
3
</div>

这是一个自定义样式的 div 块，使用了 Tailwind CSS 类。

简单的变量导出#

1
export const year = new Date().getFullYear()
2

3
今年是 {year} 年。

今年是 2026 年。

更多信息，请查看 MDX 文档

我的学习小铺

到底什么问题该问同事

一、 大胆开口：哪些问题该问同事？#

1. 缺乏文档支持的“开发流程”问题#

2. 缺乏文档支持的“环境配置”问题#

3. 公司专属的“业务与需求”问题#

二、 职场红线：哪些问题绝对不要问？#

1. 随手可查的“懒人问题”#

2. 宽泛、空洞的“情绪化问题”#

3. 同一个问题多次问#

三、 提问的艺术：如何高效向同事请教？#

定时任务Quartz框架的使用

一、基础概述#

1、什么是Quartz？#

2、为什么学Quartz？#

3、Quartz三个核心概念#

二、快速入门（最简内存版 Demo）#

第一步：引入依赖#

第二步：创建任务类（🔥 优雅写法）#

第三步：创建配置类（老板分配工作）#

三、两种核心 Trigger（触发器）#

1、SimpleTrigger（简单触发器）#

2、CronTrigger（Cron触发器）#

四、高阶必杀技：并发控制（极度重要）#

五、动态管理任务（企业级真实场景）#

六、企业级生产实战（持久化配置）#

1、准备数据库表#

2、修改 application.yml#

七、新人避坑指南#

八、技术选型对比（我该用哪个？）#

定时任务Scheduled注解的使用

一、基础概述#

1、什么是定时任务？#

2、Spring Scheduled是什么？#

二、快速入门#

第一步：开启定时任务支持#

第二步：创建定时任务#

三、@Scheduled注解参数详解#

1、cron表达式（最常用）#

2、fixedDelay（固定延迟）#

3、fixedRate（固定频率）#

4、initialDelay（首次延迟）#

5、参数对比#

四、实际工作中的示例#

示例1：每天凌晨同步数据#

示例2：每5分钟检查超时订单#

示例3：定时清理临时文件#

示例4：带有任务开关的定时任务（真实工作场景必备）#

五、多线程配置（进阶）#

问题：默认单线程#

解决方案：配置线程池#

六、常见问题#

1、定时任务不执行？#

2、任务执行时间过长影响其他任务？#

3、多台服务器都会执行怎么办？#

七、注意事项#

该如何正确处理异常信息

一、什么时候 try-catch#

1、隐藏异常，不让调用者感知异常，并做降级处理#

2、对原始异常进行包装#

二、什么时候抛出异常#

三、总结#

该以什么心态面对工作中的困难

该以什么心态面对工作中的困难#

一、先接受困难是工作的一部分#

二、不要一遇到问题就自我否定#

1、容易陷入自我否定的状态#

2、很多问题的产生并不一定是因为你能力不够#

三、学会拆解问题，而不是被问题压住#

1、拆解问题的例子#

2、一步步解决小问题#

四、不要长时间自己硬扛#

1、不愿意问别人的原因#

2、不会问问题比问问题更严重#

3、更好的处理方式#

五、把困难当成学习机会#

1、真正让你成长的是困难#

2、每解决一个问题就是一次成长#

六、保持耐心，不要急于求成#

1、新人常见的心态#

一、大胆开口：哪些问题该问同事？#

二、职场红线：哪些问题绝对不要问？#

三、提问的艺术：如何高效向同事请教？#