面试题手册

axios 是基于 Promise 的 HTTP 客户端，相比原生 fetch 的核心优势在于：请求/响应拦截器（统一添加 token、错误处理）、自动 JSON 转换（fetch 需手动 .json()）、请求超时配置（fetch 需封装 AbortController+setTimeout）、上传进度监控、XSRF 防护，以及 4xx/5xx 自动 reject（fetch 只在网络故障时才 reject）。但 fetch 是浏览器原生 API，零体积开销，且正逐步补齐能力（AbortController 已支持取消）。追问axios 的拦截器机制是怎么实现的？内部维护请求和响应两个拦截器数组（数组链），发送请求时按序执行请求拦截器，收到响应后按序执行响应拦截器，本质是 Promise 链式调用。fetch 如何实现请求超时？用 AbortController 创建 signal，配合 setTimeout 调用 controller.abort()，fetch 接收 signal 参数，超时后抛出 AbortError。axios 直接配置 timeout 字段即可。axios 在浏览器和 Node.js 端分别用什么发送请求？浏览器端基于 XMLHttpRequest，Node.js 端基于 http/https 模块，通过适配器模式统一 API。fetch 在 Node 18+ 才原生支持。axios 如何实现 XSRF 防护？读取指定 cookie（默认 XSRF-TOKEN）的值，自动写入请求头（默认 X-XSRF-TOKEN），配合后端双重 cookie 验证机制防跨站请求伪造。写段代码const instance = axios.create({ baseURL: '/api', timeout: 5000,});instance.interceptors.request.use(cfg => { cfg.headers.Authorization = `Bearer ${token}`; return cfg;});instance.interceptors.response.use( res => res.data, err => { if (err.response?.status === 401) redirectToLogin(); });

Spring Boot 通过 Profile 机制实现多环境配置。核心做法是创建 application-{profile}.yml 文件（如 application-dev.yml、application-prod.yml），公共配置放 application.yml，环境特有配置放对应 Profile 文件，同名属性 Profile 文件覆盖默认值。激活方式包括配置文件中 spring.profiles.active、启动参数 --spring.profiles.active=prod、环境变量 SPRING_PROFILES_ACTIVE。代码层面用 @Profile 注解按环境条件注册 Bean，Spring Boot 2.4+ 还支持 spring.profiles.group 将多个 Profile 组合激活。配置优先级为：命令行参数 > 环境变量 > Profile 文件 > 默认文件。追问application.yml 和 application-dev.yml 同名属性如何取舍？ Profile 文件优先，覆盖默认文件中的同名配置；若同时激活多个 Profile，后激活的覆盖先激活的。@Profile 注解标注在类和方法上有什么区别？ 标注在 @Configuration 类上整个配置类按条件加载，标注在 @Bean 方法上只控制单个 Bean 的注册。单文件多文档块（---分隔）和多文件方式如何选择？ 多文档块适合配置较少的项目，管理简单；多文件适合配置量大、环境差异明显的项目，避免单文件过长且减少合并冲突。生产环境敏感信息如何保护？ 使用环境变量 ${DB_PASSWORD} 引用，或通过 Jasypt 对配置值加密存储为 ENC(密文)，运行时由加密器解密。Profile 分组解决了什么问题？ 一个环境可能需要同时激活多个维度（如 prod + prod-db + prod-mq），分组将它们聚合为一个名称，简化启动参数。写段代码@Configurationpublic class DataSourceConfig { @Bean @Profile("dev") public DataSource devDs() { return new HikariDataSource(new HikariConfig() {{ setJdbcUrl("jdbc:mysql://localhost/dev"); }}); } @Bean @Profile("prod") public DataSource prodDs() { HikariConfig c = new HikariConfig(); c.setJdbcUrl("jdbc:mysql://prod-db/prod"); c.setUsername(System.getenv("DB_USER")); return new HikariDataSource(c); }}

Workbox 是 Google 推出的 Service Worker 工具库，将常见的缓存策略、路由匹配、预缓存等能力封装为开箱即用的模块，大幅降低 SW 开发复杂度。核心提供三种缓存策略：CacheFirst（缓存优先，适合静态资源）、NetworkFirst（网络优先，适合API数据）、StaleWhileRevalidate（先用缓存再后台更新，适合非关键资源）。配合 workbox-precaching 可在 install 阶段批量预缓存，配合 ExpirationPlugin 可控制缓存条目数和过期时间。追问CacheFirst 和 StaleWhileRevalidate 分别适合什么场景？CacheFirst 适合字体、样式等不变资源，命中缓存直接返回，速度最快；StaleWhileRevalidate 适合图片或第三方脚本，先返回缓存保证响应速度，同时后台更新缓存，下次请求拿到新版本。workbox-precaching 和运行时缓存有什么区别？precache 在 SW install 时一次性缓存资源清单（self._WBMANIFEST），确保离线可用；运行时缓存在 fetch 事件触发时按策略写入，首次请求仍需网络。Workbox 如何与构建工具集成？Webpack 用 workbox-webpack-plugin（GenerateSW 自动生成或 InjectManifest 注入清单）；Vite 用 vite-plugin-pwa，在构建时自动生成 SW 并注入运行时缓存配置。Workbox 的 BackgroundSyncPlugin 解决了什么问题？当 POST 请求因离线失败时，自动将请求放入队列，待网络恢复后重试，确保数据不丢失。适用于表单提交、数据上报等场景。写段代码import { registerRoute } from 'workbox-routing';import { CacheFirst, StaleWhileRevalidate } from 'workbox-strategies';registerRoute( ({ request }) => request.destination === 'style', new CacheFirst({ cacheName: 'styles' }));registerRoute( ({ request }) => request.destination === 'image', new StaleWhileRevalidate({ cacheName: 'images' }));

Zustand 是一个极简 React 状态管理库，核心 API 只有 create()：传入一个返回状态对象的函数，返回一个 hook，组件通过 const count = useStore(s => s.count) 按需订阅，未变化的部分不会触发重渲染。不需要 Provider 包裹，不需要 reducer/action 分发，setState 直接更新。体积约 1KB，零依赖。追问Zustand 的 selector 如何避免不必要的重渲染？useStore(selector) 只订阅 selector 返回的切片，内部用 Object.is 浅比较判断是否变化。引用类型可传第二个参数 shallow 比较函数，或用 useShallow。和 Jotai/Recoil 的原子化方案有什么区别？Zustand 是单一 store（可拆分），状态集中管理；Jotai/Recoil 是原子化，每个状态独立。Zustand 更适合关联性强的状态，原子化适合独立派生状态。没有 Provider 怎么实现组件间共享状态？Zustand store 本质是一个模块级闭包，所有引用同一 useStore 的组件共享同一个状态引用，不依赖 React Context 传递。create() 返回的 hook 能在组件外使用吗？可以。useStore.getState() 获取快照、useStore.setState() 更新状态，均可在非组件代码（如 axios 拦截器、WebSocket 回调）中使用，这是相比 useContext 的显著优势。多 store 还是单 store？Zustand 不限制，实践中按领域拆分多个 store 更常见，避免单个 store 臃肿，也便于按需加载和测试。写段代码import { create } from 'zustand'const useStore = create((set) => ({ count: 0, inc: () => set((s) => ({ count: s.count + 1 })),}))function Counter() { const count = useStore((s) => s.count) return <button onClick={useStore.getState().inc}>{count}</button>}

Spring Boot 通过 @RestControllerAdvice + @ExceptionHandler 实现全局异常处理。前者是 AOP 组件，拦截所有 Controller 抛出的异常；后者按异常类型匹配处理方法，返回统一的响应体。典型做法是定义自定义 BusinessException 携带错误码和消息，在异常处理类中分别处理业务异常、参数校验异常（MethodArgumentNotValidException）和兜底异常（Exception），对外返回结构化的错误响应，对内记录日志并隐藏堆栈细节。RFC 7807 的 application/problem+json 是业界推荐的错误响应格式。追问@RestControllerAdvice 和 @ControllerAdvice 有何区别？ 前者是后者的 @ResponseBody 组合注解，方法返回值直接序列化为 JSON；后者适用于返回 ModelAndView 的传统 MVC 场景。多个 @ExceptionHandler 匹配同一个异常时如何选择？ Spring 选择异常类型最具体的那个方法，即继承链中最靠近抛出异常类型的处理器优先。如何处理 404 异常？ 默认 Spring Boot 不抛出 404 异常而是返回白标签页，需设置 throw-exception-if-no-handler-found=true 并关闭 add-mappings=false，再用 @ExceptionHandler(NoHandlerFoundException.class) 捕获。BusinessException 为什么用 RuntimeException 而非 Checked Exception？ 避免 try-catch 侵入业务代码，全局处理器统一兜底，保持代码整洁。参数校验异常 MethodArgumentNotValidException 和 ConstraintViolationException 分别在何时触发？ 前者发生在 @RequestBody + @Valid 校验请求体时，后者发生在 @RequestParam + @Validated 校验单参数时。写段代码@RestControllerAdvicepublic class GlobalExHandler { @ExceptionHandler(BusinessException.class) public ResponseEntity<Result<Void>> onBiz(BusinessException e) { return ResponseEntity.badRequest().body(Result.error(e.getCode(), e.getMessage())); } @ExceptionHandler(Exception.class) public ResponseEntity<Result<Void>> onEx(Exception e) { return ResponseEntity.status(500).body(Result.error(500, "系统繁忙")); }}

Service Worker 是运行在浏览器后台的独立 JS 线程，充当应用与网络之间的代理服务器。它能拦截所有网络请求、管理缓存资源，从而实现离线访问、推送通知和后台同步等能力，是 PWA 的核心技术。其生命周期为 register → install → activate → fetch，浏览器会在空闲时自动终止 SW 线程以节省资源。SW 无法直接操作 DOM，只能通过 postMessage 与主线程通信，且必须在 HTTPS 环境下运行。追问SW 的 install 和 activate 阶段分别适合做什么？install 阶段适合预缓存关键资源（App Shell），调用 event.waitUntil() 确保资源缓存完成后才完成安装；activate 阶段适合清理旧版本缓存，避免残留数据冲突。SW 如何拦截和处理网络请求？通过监听 fetch 事件，可以决定从缓存返回、从网络请求或组合策略（如 Stale-While-Revalidate）。event.respondWith() 用于返回自定义响应。为什么 SW 必须在 HTTPS 下运行？因为 SW 能拦截和篡改所有网络请求，若在 HTTP 下运行，中间人攻击者可注入恶意 SW 劫持全部流量。localhost 是唯一例外。SW 与 Web Worker 有什么区别？Web Worker 由页面创建且随页面销毁，用于 CPU 密集计算；SW 生命周期独立于页面，由浏览器管理，专门处理网络代理和后台任务。写段代码self.addEventListener('install', (e) => { e.waitUntil( caches.open('v1').then(c => c.addAll(['/index.html', '/app.js'])) );});self.addEventListener('fetch', (e) => { e.respondWith( caches.match(e.request).then(r => r || fetch(e.request)) );});

引入 mybatis-spring-boot-starter 后，通过 @MapperScan 扫描接口、XML 或注解编写 SQL 即可完成整合。核心三要素：Mapper 接口（定义方法签名）、映射文件（编写 SQL 与 ResultMap）、自动配置（驼峰映射、数据源）。简单 CRUD 用注解（@Select/@Insert），复杂动态 SQL 用 XML（where/set/foreach）。PageHelper.startPage 即可实现分页，@Transactional 管理事务。追问@Mapper 和 @MapperScan 有什么区别？@Mapper 逐个标注接口，适合 Mapper 少的场景；@MapperScan 在启动类统一指定包路径，批量注册，推荐使用。两者二选一，不可重复注册。#{} 和 ${} 的区别是什么？{} 使用预编译参数（PreparedStatement 占位符），防止 SQL 注入；${} 直接字符串拼接，有注入风险，仅用于表名、列名等不可预编译的位置。ResultMap 和 ResultType 怎么选？字段名与属性一致时用 resultType 自动映射（配合 map-underscore-to-camel-case）；不一致或有关联查询（association/collection）时必须用 resultMap 手动映射。动态 SQL 的 where 标签解决了什么问题？自动去除首个多余 AND/OR，并在条件全空时不生成 WHERE 子句，避免语法错误。set 标签同理，自动去除末尾多余逗号。PageHelper 分页的原理和坑是什么？PageHelper 基于 MyBatis Interceptor 拦截 SQL，自动拼接 LIMIT。坑：startPage 必须紧挨查询语句，中间不能有其他查询，否则分页错乱；只对紧跟的第一条查询生效。写段代码@SpringBootApplication@MapperScan("com.example.mapper")public class App { public static void main(String[] args) { SpringApplication.run(App.class, args); } }// XML 动态查询<select id="selectByCondition" resultMap="BaseMap"> SELECT * FROM user <where> <if test="name != null">AND name LIKE CONCAT('%',#{name},'%')</if> </where></select>

Spring Boot 通过 spring-boot-starter-security 集成 Spring Security，核心流程为：请求进入 SecurityFilterChain，依次经过认证过滤器（如 UsernamePasswordAuthenticationFilter 或自定义 JWT Filter），由 AuthenticationManager 委托 UserDetailsService 加载用户并校验凭证，认证成功后将 Authentication 存入 SecurityContextHolder；授权阶段通过 @PreAuthorize 或 URL 规则判断权限。JWT 场景下需自定义 Filter 从 Header 提取 Token 并验证，同时将 SessionCreationPolicy 设为 STATELESS。追问SecurityFilterChain 的执行顺序如何控制？ 通过 http.addFilterBefore()/after() 指定过滤器位置，Spring Security 内置过滤器有固定顺序（如 UsernamePasswordAuthenticationFilter 位于 BasicAuthenticationFilter 之前）。UserDetailsService 和 UserDetails 的职责分别是什么？ UserDetailsService 负责从数据源加载用户信息，UserDetails 是用户信息的载体接口，包含密码、权限和账户状态。JWT 无状态方案下如何实现 Token 注销？ 可维护黑名单（Redis 存储已注销 Token 直至过期）或采用短期 Token + Refresh Token 轮换机制。@PreAuthorize 和 URL 授权规则各自适合什么场景？ URL 规则适合粗粒度的路径级控制，@PreAuthorize 适合方法级细粒度控制，支持 SpEL 表达式如 @userSecurity.canAccess(authentication, #id)。为什么密码必须用 BCrypt 而非 MD5？ BCrypt 内置盐值且计算成本可调，抗彩虹表和暴力破解；MD5 是快速哈希，易被暴力穷举。写段代码@BeanSecurityFilterChain chain(HttpSecurity http) throws Exception { http.csrf(c -> c.disable()) .sessionManagement(s -> s.sessionCreationPolicy(SessionCreationPolicy.STATELESS)) .authorizeHttpRequests(a -> a .requestMatchers("/api/auth/**").permitAll() .requestMatchers("/api/admin/**").hasRole("ADMIN") .anyRequest().authenticated()) .addFilterBefore(jwtFilter, UsernamePasswordAuthenticationFilter.class); return http.build();}

服务注册与发现是微服务架构的基础设施：服务启动时将自身地址注册到注册中心，消费方从注册中心拉取可用实例列表并调用。主流方案有 Eureka（AP、已停维）、Nacos（AP/CP 可切换、国产生态）、Consul（CP、云原生友好）。核心流程三步：注册（实例启动时上报 IP/端口）、心跳（定时续约保活）、拉取（客户端缓存实例列表并定时刷新）。Nacos 是当前新项目首选，临时实例走客户端心跳，持久实例走服务端探活，还内置配置中心。追问Eureka 自我保护机制触发后，实例下线能否被感知？不能立即感知。自我保护模式下 Eureka 不再剔除过期实例，客户端可能拿到已下线的地址，需配合 Ribbon 重试或熔断兜底。Nacos 临时实例和持久实例的区别是什么？临时实例（ephemeral=true）由客户端发心跳，不续约则自动剔除，适合微服务；持久实例由服务端主动探活，不会自动删除，适合数据库等基础设施。客户端发现与服务端发现有什么区别？客户端发现：消费方从注册中心拉取列表，本地负载均衡（Eureka/Nacos）；服务端发现：请求先到网关/代理，由代理侧转发（Consul + Nginx）。前者少一跳，后者解耦消费方。注册中心选型时 CAP 如何取舍？Eureka 牺牲一致性保可用（AP），适合网络分区时仍需可用的场景；Consul/ZK 保一致性（CP），适合不能容忍脏数据的场景；Nacos 支持按实例切换 AP/CP。优雅下线如何避免请求打到已注销实例？先从注册中心注销，再等待正在处理的请求完成（如 5s），最后关闭服务。Spring Boot 可监听 ContextClosedEvent 触发注销，配合 sleep 等待在途请求。写段代码@SpringBootApplication@EnableDiscoveryClientpublic class OrderApp { public static void main(String[] args) { SpringApplication.run(OrderApp.class, args); } }@FeignClient(name = "user-service")public interface UserClient { @GetMapping("/users/{id}") User getById(@PathVariable Long id);}

Starter 是 Spring Boot 提供的依赖聚合与自动配置的组合机制。它将某项功能所需的所有依赖打包成一个 POM 依赖描述符，同时通过 @EnableAutoConfiguration 扫描 META-INF/spring.factories（或 2.7+ 的 AutoConfiguration.imports）中注册的自动配置类，配合 @ConditionalOnClass、@ConditionalOnMissingBean 等条件注解，实现按需装配 Bean。因此引入一个 starter 即可获得完整的依赖集合和零配置的功能启用。追问@ConditionalOnClass 和 @ConditionalOnMissingBean 分别解决什么问题？ 前者在 classpath 存在指定类时才装配，避免缺少依赖导致启动失败；后者在容器中无同名 Bean 时才创建，允许用户覆盖默认配置。官方 starter 和第三方 starter 的命名规范有何不同？ 官方为 spring-boot-starter-*，第三方为 *-spring-boot-starter，反过来便于区分来源。Spring Boot 2.7 后为什么用 AutoConfiguration.imports 替代 spring.factories？ spring.factories 职责过重，AutoConfiguration.imports 专用于自动配置注册，加载更高效且语义更清晰。自定义 starter 时 @ConfigurationProperties 有什么作用？ 将 application.yml 中以指定前缀开头的属性映射到 Java 对象，实现外部化配置的类型安全绑定。Starter 依赖传递和 BOM 版本管理是什么关系？ Starter 聚合依赖但不管理版本，版本由 spring-boot-dependencies BOM 统一控制，确保兼容性。写段代码@Configuration@ConditionalOnClass(DataSource.class)@EnableConfigurationProperties(MyProps.class)public class MyAutoConfiguration { @Bean @ConditionalOnMissingBean public MyService myService(MyProps p) { return new MyService(p.getHost(), p.getPort()); }}