服务端面试题手册

区块链是一种分布式账本技术，通过密码学将数据区块按时间顺序链式连接，实现去中心化存储与验证。核心特点：去中心化（无单点控制，全网节点共持账本）、不可篡改（每个区块头包含前一区块哈希，篡改任一区块需重算后续所有区块哈希）、透明性（交易公开可验证）、安全性（共识机制防恶意攻击）。去中心化原理：传统系统依赖中心服务器，区块链中所有节点对等存储完整账本，通过共识算法（PoW/PoS/PBFT）对新区块达成一致。公有链任何人可参与，联盟链需授权，私有链由单一组织控制。追问哈希指针如何保证区块不可篡改？如果攻击者控制了51%算力会发生什么？PoW、PoS、PBFT 三种共识机制分别适用于什么场景？它们的吞吐量和最终确认时间有何差异？默克尔树在区块链中起什么作用？轻节点如何利用默克尔证明验证交易？公有链、联盟链、私有链在去中心化程度上有什么区别？各自适合什么业务？区块链的"不可能三角"指什么？为什么无法同时满足去中心化、安全性和可扩展性？写段代码// 简化版区块链：哈希链与工作量证明class Block { constructor(data, prevHash) { this.data = data; this.prevHash = prevHash; this.nonce = 0; this.hash = this.mine(); } mine() { let h; do { this.nonce++; h = sha256(this.prevHash + this.data + this.nonce); } while (!h.startsWith('0000')); // 难度：前4位为0 return h; }}class Chain { constructor() { this.blocks = [new Block('genesis', '0')]; } add(data) { this.blocks.push(new Block(data, this.blocks.at(-1).hash)); } isValid() { return this.blocks.every((b,i) => i===0 || b.prevHash === this.blocks[i-1].hash); }}

WebGL 阴影的主流实现方式是阴影贴图（Shadow Mapping）：先从光源视角渲染场景生成深度图，再从相机视角渲染时将每个片段变换到光源空间，比较其深度与深度图中的值——若片段深度更大则处于阴影中。软阴影通过 PCF（Percentage Closer Filtering）对深度图多次采样取平均实现。两大典型问题：阴影痤疮（shadow acne）由深度精度误差导致，用基于法线-光线夹角的 bias 修复；彼得潘效应（peter panning）由 bias 过大导致阴影脱离物体，改用正面剔除渲染深度图解决。大场景用级联阴影贴图（CSM）按距离分配不同分辨率。追问为什么阴影贴图会产生阴影痤疮？bias 值如何根据表面法线和光线方向动态计算？PCF 软阴影的采样半径越大越模糊，但会带来什么性能问题？Poisson Disk 采样有何优势？级联阴影贴图（CSM）如何划分级联？级联接缝处的接缝问题怎么处理？点光源阴影为什么用立方体贴图？渲染立方体阴影贴图需要几次 draw call？WebGL 1.0 没有深度纹理附件，如何用 RGBA 编码深度值？精度损失如何补偿？写段代码// PCF 软阴影核心逻辑float calcShadow(vec4 lightPos, sampler2D shadowMap, vec3 normal, vec3 lightDir) { vec3 proj = lightPos.xyz / lightPos.w * 0.5 + 0.5; float bias = max(0.05 * (1.0 - dot(normal, lightDir)), 0.005); float shadow = 0.0; vec2 texel = 1.0 / vec2(textureSize(shadowMap, 0)); for (int x = -1; x <= 1; x++) for (int y = -1; y <= 1; y++) { float d = texture(shadowMap, proj.xy + vec2(x,y)*texel).r; shadow += proj.z - bias > d ? 1.0 : 0.0; } return shadow / 9.0;}

WebGL 是基于 OpenGL ES 的浏览器端 3D 图形 API，关系链为 OpenGL → OpenGL ES → WebGL。WebGL 继承了 OpenGL ES 的可编程渲染管线，通过 GLSL 编写顶点着色器和片段着色器控制 GPU 渲染，但运行在浏览器沙箱中，用 JavaScript 调用，且去除了 OpenGL 的固定管线。核心渲染流程：顶点数据经顶点着色器变换 → 图元装配 → 光栅化 → 片段着色器着色 → 帧缓冲输出。WebGL 1.0 基于 OpenGL ES 2.0，WebGL 2.0 基于 OpenGL ES 3.0。追问WebGL 和 Canvas 2D 的本质区别是什么？Canvas 2D 能调用 GPU 吗？顶点缓冲对象（VBO）的作用是什么？为什么不用 CPU 每帧传顶点数据？WebGL 的统一变量（uniform）和属性变量（attribute）分别在什么阶段使用？WebGL 2.0 相比 1.0 新增了哪些关键能力？VAO 和 3D 纹理对开发有什么影响？浏览器如何保证 WebGL 的安全性？哪些 OpenGL ES 特性被有意移除了？写段代码// WebGL 初始化：创建着色器程序并绘制三角形const gl = canvas.getContext('webgl');const vs = gl.createShader(gl.VERTEX_SHADER);gl.shaderSource(vs, 'attribute vec2 a_pos; void main(){ gl_Position=vec4(a_pos,0,1); }');gl.compileShader(vs);const fs = gl.createShader(gl.FRAGMENT_SHADER);gl.shaderSource(fs, 'precision mediump float; void main(){ gl_FragColor=vec4(1,0,0,1); }');gl.compileShader(fs);const prog = gl.createProgram();gl.attachShader(prog, vs); gl.attachShader(prog, fs);gl.linkProgram(prog); gl.useProgram(prog);const buf = gl.createBuffer();gl.bindBuffer(gl.ARRAY_BUFFER, buf);gl.bufferData(gl.ARRAY_BUFFER, new Float32Array([0,0.5, -0.5,-0.5, 0.5,-0.5]), gl.STATIC_DRAW);const loc = gl.getAttribLocation(prog, 'a_pos');gl.enableVertexAttribArray(loc);gl.vertexAttribPointer(loc, 2, gl.FLOAT, false, 0, 0);gl.drawArrays(gl.TRIANGLES, 0, 3);

DNS（Domain Name System）是将域名映射为 IP 地址的分布式数据库系统，是互联网基础设施的核心组件。当浏览器访问域名时，解析流程为：浏览器缓存 → 系统缓存（hosts）→ 本地 DNS 服务器 → 根域名服务器 → 顶级域服务器 → 权威 DNS 服务器，逐级查询直到获得最终 IP。其中客户端到本地 DNS 是递归查询（服务器代为完成全部查询），本地 DNS 到根/TLD/权威服务器是迭代查询（每级只返回下一级地址，由本地 DNS 继续追问）。追问常见的 DNS 记录类型有哪些？A 记录映射域名到 IPv4，AAAA 到 IPv6，CNAME 将域名指向另一个域名（别名），MX 指定邮件服务器，NS 指定域名服务器，TXT 用于验证和配置（如 SPF、DKIM）。TTL 在 DNS 中起什么作用？TTL（Time To Live）决定解析结果的缓存有效期。短 TTL 可加快 DNS 变更生效（如故障切换），但增加查询量；长 TTL 减少查询但变更传播慢。CDN 切换节点时需要权衡 TTL 设置。DNS 劫持是什么？DNSSEC 如何防护？DNS 劫持是中间人篡改 DNS 响应返回恶意 IP。DNSSEC 通过对 DNS 响应数字签名验证数据来源和完整性，客户端可验证响应未被篡改。CDN 如何利用 CNAME 实现就近访问？用户域名 CNAME 到 CDN 域名后，CDN 的权威 DNS 根据用户 IP 返回最近的边缘节点 IP。部分服务商采用 CNAME Flattening，在权威 DNS 层直接返回 A 记录，避免 CNAME 链过长影响性能。写段代码# 常用 DNS 查询命令dig example.com A # 查 A 记录dig example.com CNAME # 查 CNAMEnslookup example.com # 简单查询host -t MX example.com # 查邮件记录

Zustand 中间件以函数组合方式包裹 create 的回调，从内到外依次嵌套。内置三个核心中间件：persist（状态持久化到 localStorage/sessionStorage）、devtools（接入 Redux DevTools 调试）、immer（简化不可变更新，可直接写 state.user.name = 'new'）。组合顺序：devtools 在最外层，persist 在内层，中间件顺序影响 set/get 的拦截链。追问persist 的 partialize 怎么过滤不需要持久化的字段？partialize: (state) => ({ user: state.user }) 只持久化 user，token 等敏感或临时字段不会写入存储。反序列化时缺失字段会使用 create 中的初始值填充。immer 中间件解决了什么问题？React 要求状态不可变更新，深层嵌套需逐层展开 {…s, user: {…s.user, name: 'new'}}，代码冗长易出错。immer 让你直接赋值 state.user.name = 'new'，内部通过 Proxy 生成新对象。中间件组合顺序有影响吗？有。devtools(persist(fn)) 中 persist 在内层，持久化后的状态变化才会被 devtools 捕获；反过来的话 devtools 记录的是持久化前。一般推荐 devtools 在外、persist 在内。如何自定义中间件？中间件本质是高阶函数：(config) => (set, get, api) => config(fnSet, fnGet, api)，在 fnSet/fnGet 中插入自定义逻辑（如日志、节流、权限校验），然后调用原 set/get。persist 持久化的状态怎么版本迁移？persist 配置中提供 migrate 函数：migrate: (persisted, version) => { if (version === 0) return { …persisted, newField: 'default' }; return persisted; }，配合 version 字段标识当前版本，自动执行迁移。写段代码import { create } from 'zustand'import { persist, devtools } from 'zustand/middleware'const useStore = create( devtools( persist( (set) => ({ token: '', setToken: (t: string) => set({ token: t }), }), { name: 'auth', partialize: (s) => ({ token: s.token }) } ), { name: 'AuthStore' } ))

Babel 是 JavaScript 转译器，将 ES6+ 语法转为向后兼容的 ES5 代码，确保在旧浏览器中正常运行。编译流程分三步：parse（@babel/parser 将源码转 AST）→ transform（插件遍历 AST 并修改节点）→ generate（@babel/generator 将 AST 还原为代码）。注意 Babel 只转换语法，不补齐新 API（如 Promise、Array.includes），需要 polyfill 方案配合。追问Babel 的 plugin 和 preset 是什么关系？plugin 是最小转换单元（如 @babel/plugin-transform-arrow-functions），preset 是插件集合（如 @babel/preset-env 包含所有 ES6+ 转换插件）。执行顺序：plugins 先于 presets，plugins 正序执行，presets 逆序执行。@babel/preset-env 的工作原理是什么？根据 browserslist 配置的目标环境，按需引入转换插件和 polyfill，避免对已支持语法的多余转换。配合 useBuiltIns: 'usage' 可实现按需注入 polyfill。polyfill 方案有哪些？core-js 和 transform-runtime 有什么区别？core-js 直接在全局注入缺失 API，适合应用项目；@babel/plugin-transform-runtime 将 polyfill 抽离为模块引用（不污染全局），适合库开发，还能避免 helpers 重复打包。Babel 能替代 Webpack 吗？不能。Babel 只做语法转译，不做模块打包、代码分割、Tree Shaking、资源处理，这些是 bundler 的职责。两者配合使用。写段代码// babel.config.jsmodule.exports = { presets: [ ['@babel/preset-env', { targets: '> 0.25%, not dead', useBuiltIns: 'usage', corejs: 3 }] ], plugins: ['@babel/plugin-transform-runtime']};

Spring Boot 通过 @EnableAsync + @Async 实现声明式异步编程。在配置类上标注 @EnableAsync 开启支持，在方法上标注 @Async 即可在独立线程执行；默认使用 SimpleAsyncTaskExecutor（每次新建线程），生产环境应自定义 ThreadPoolTaskExecutor 并通过 @Async("executorName") 指定线程池。有返回值的方法返回 CompletableFuture，调用方可通过 future.get() 或 CompletableFuture.allOf() 组合多个异步结果。异常处理方面，返回 CompletableFuture 的方法异常会传播到 future，void 方法需实现 AsyncUncaughtExceptionHandler。注意同类内部调用 @Async 方法不生效（绕过代理）。追问ThreadPoolTaskExecutor 的核心参数如何设置？ IO 密集型核心线程数可设为 CPU 核数 * 2，队列容量适当放大；CPU 密集型核心线程数为 CPU 核数 + 1，队列不宜过大；拒绝策略推荐 CallerRunsPolicy 由提交线程执行降速。@Async 方法为什么同类调用不生效？如何解决？ @Async 依赖 AOP 代理，this.method() 绕过代理直接调用原始方法；解决方案是注入自身代理 @Lazy private XxxService self 后通过 self.method() 调用。CompletableFuture 的 thenCombine 和 thenCompose 有何区别？ thenCombine 将两个独立异步结果合并（BiFunction），thenCompose 用于异步结果串联（flatMap 语义，前一步结果决定后一步操作）。@Async 和 @Transactional 一起使用有什么陷阱？ 事务上下文绑定 ThreadLocal，异步方法在新线程执行导致事务不传播；应在异步方法内部调用另一个 Bean 的事务方法，而非叠加注解。如何将 RequestContext 传播到异步线程？ 使用 TaskDecorator 在任务提交时捕获主线程的 RequestAttributes，在异步线程执行前设置，执行后清除。写段代码@EnableAsync@Configurationpublic class AsyncConfig implements AsyncConfigurer { @Override public Executor getAsyncExecutor() { ThreadPoolTaskExecutor ex = new ThreadPoolTaskExecutor(); ex.setCorePoolSize(5); ex.setMaxPoolSize(20); ex.setQueueCapacity(100); ex.setThreadNamePrefix("async-"); ex.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); ex.initialize(); return ex; }}

定义一个包含状态和方法的 interface，作为 create 的泛型参数传入即可：create((set, get) => ({…}))。TypeScript 会自动推断 set 回调中 state 的类型，方法参数也能正确约束。关键点：状态和方法写在同一个 interface 中，方法参数可引用自身类型（如 setUser: (user: StoreState['user']) => void）。追问中间件会改变 store 类型，怎么处理类型组合？persist/devtools 等中间件会向 store 注入额外属性（如 persist.clearStorage），需定义扩展类型 type Store = StoreState & StorePersist，再用 create() 包裹。zustand v4+ 的中间件泛型签名已支持自动推断，大部分场景无需手动拼接。StateCreator 泛型怎么用？StateCreator 用于拆分 store 逻辑时约束每个切片的类型，Mutators 描述中间件链对 set/get 的改写，U 是未包装的原始类型。手动组合切片时需要用到。selector 的返回类型怎么保证？useStore(s => s.count) 自动推断为 number。自定义 selector 返回派生值时，TypeScript 能推断返回类型；如果需要显式标注，写 useStore((s) => s.items.length)。泛型 store 怎么定义？function createSlice() 返回 StateCreator>，通过泛型参数让切片适配不同实体（如 createSlice()、createSlice()），避免为每个实体写重复逻辑。set 的 partial 参数类型为什么不是 Partial？set 接受 Partial 或 (state) => Partial，但嵌套对象是浅合并，深层更新需展开：set(s => ({ user: { …s.user, name: 'new' } }))，否则丢失同级字段。写段代码interface BearState { bears: number inc: (n: number) => void}const useBearStore = create<BearState>((set) => ({ bears: 0, inc: (n) => set((s) => ({ bears: s.bears + n })),}))// 组件中const bears = useBearStore((s) => s.bears) // number

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()); }}

React Query 最大性能陷阱是组件过度渲染：query 数据变化时所有订阅组件都重渲染。解法是用 select 提取组件关心的子字段，select 返回值用浅比较去重，相等则跳过渲染。第二陷阱是缓存策略不当：staleTime 控制数据何时标记为过期触发重新请求（默认0即立即过期），gcTime（v5 前叫 cacheTime）控制未使用的缓存何时被垃圾回收（默认5分钟）。不常变的数据应设较长 staleTime 避免无谓请求。第三是 queryKey 设计：key 变化就触发新请求，key 中包含频繁变化的值（如时间戳）会导致缓存失效。queryKey 应稳定且分层：['users', 'list', { status: 'active' }]。追问staleTime 和 gcTime 有什么区别？staleTime 决定数据是否需要重新获取（过期前用缓存，过期后下次挂载或窗口聚焦时 refetch）；gcTime 决定缓存数据在内存中保留多久，观察者归零后开始倒计时，到期彻底删除。一个管新鲜度，一个管生命周期。select 怎么避免不必要的渲染？select 每次查询都会执行，但只有返回值与上次浅比较不同时才触发渲染。返回新对象/数组每次都是新引用会失效，需确保返回原始值或用结构化分享的子集。useInfiniteQuery 如何优化？每页数据独立缓存，默认所有页面变化都触发渲染。可用 select 只取当前视口需要的数据；配合虚拟滚动（如 react-virtual）避免渲染长列表；getNextPageParam 返回 undefined 自动停止加载。如何实现乐观更新？用 useMutation 的 onMutate 在请求发出前乐观修改缓存（queryClient.setQueryData），onError 时用 onMutate 保存的快照回滚，onSettled 时 invalidate 相关 query 保证最终一致。写段代码// select + staleTime 减少渲染和请求const { data: name } = useQuery({ queryKey: ['user', id], queryFn: () => fetchUser(id), staleTime: 5 * 60 * 1000, select: (data) => data.name,});

SSH 故障按报错分四类：Connection refused 说明目标端口未监听（sshd 未运行或防火墙阻断）；Connection timeout 说明网络不可达（路由/防火墙丢弃包）；Permission denied 是认证失败（密钥不匹配或权限错误）；Host key verification failed 是 knownhosts 中记录的指纹与服务器当前密钥不一致。排查第一步始终是 ssh -vvv 看详细握手过程，日志会精确显示卡在哪个阶段。密钥权限是最常见的低级错误：私钥必须 600，.ssh 目录 700，authorizedkeys 600，权限过宽 sshd 会拒绝认证。追问ssh -vvv 输出中各阶段分别对应什么？三个 v 递增详细度。-v 显示连接建立、密钥交换、认证尝试；-vv 增加配置解析和 IO 细节；-vvv 再增加包级调试。重点关注 debug1: Authentications that can continue 和 debug1: Offering public key 两行，前者看服务端支持哪些认证方式，后者看客户端尝试了哪些密钥。连接频繁断开怎么解决？通常是 NAT/防火墙空闲连接超时淘汰。客户端配置 ServerAliveInterval 60（每60秒发心跳），服务端配置 ClientAliveInterval 300。autossh 可自动重连断开的会话。known_hosts 冲突一定是重装系统吗？不一定。IP 被复用、服务器更新了主机密钥、或中间人攻击都会导致。确认安全后用 ssh-keygen -R host 删除旧记录，不可盲目忽略否则失去 MITM 保护。如何不用密码只允许密钥登录？服务端 /etc/ssh/sshd_config 设置 PasswordAuthentication no 和 PubkeyAuthentication yes，改完 sshd -t 验证语法再 systemctl restart sshd。写段代码# 客户端 SSH 配置 ~/.ssh/configHost myserver HostName 10.0.0.1 User deploy Port 2222 IdentityFile ~/.ssh/deploy_key ServerAliveInterval 60