服务端面试题手册

useQuery 用来读数据，useMutation 用来改数据。读数据通常自动执行、会按 queryKey 缓存，并处理 loading、error、重试和后台刷新；改数据不会因为组件渲染就自动执行，需要调用 mutate，成功后通常 invalidateQueries 让相关列表重新获取，或者做乐观更新。追问为什么 useMutation 不像 useQuery 那样自动缓存？因为写操作的重点不是展示“这次提交的返回值”，而是让服务器状态发生变化。变化后要么让相关 query 失效重新拉取，要么手动更新缓存。提交表单应该用哪个？用 useMutation。表单提交是创建或更新资源，应该由用户动作触发，而不是组件一挂载就执行。删除一条数据后列表怎么刷新？常见做法是在 onSuccess 里调用 queryClient.invalidateQueries，让列表 query 重新获取。体验要求高时可以先做乐观删除，失败再回滚。queryKey 在 useQuery 里为什么重要？它决定缓存身份。列表、详情、筛选条件都应该进 queryKey，否则容易拿到旧数据或串数据。写段代码const todos = useQuery({ queryKey: ['todos'], queryFn: fetchTodos });const addTodo = useMutation({ mutationFn: createTodo, onSuccess: () => { queryClient.invalidateQueries({ queryKey: ['todos'] }); },});addTodo.mutate({ title: 'learn query' });

React Query 管服务器状态，Redux 管客户端状态。服务器状态来自后端，会过期、要缓存、要重试、要和接口同步；客户端状态只存在前端，比如弹窗开关、主题、复杂表单流程。项目里常见做法不是二选一，而是用 React Query 处理接口数据，用 Redux、Zustand 或 Context 处理真正的全局 UI 状态。追问React Query 能替代 Redux 吗？只能替代一大部分“把接口数据塞进 Redux”的写法。购物车草稿、权限后的菜单展开状态、跨页面编辑流程这类客户端状态，React Query 不负责。为什么接口数据不适合直接放 Redux？你要自己写 loading、error、缓存过期、重复请求合并、重试和失效逻辑。React Query 把这些变成默认能力，代码量少很多。什么时候还应该用 Redux？当状态更新规则复杂、多个模块共享同一份前端状态、需要严格可追踪的状态变更时，Redux 仍然合适。已经重度使用 Redux Toolkit 的项目，也可以考虑 RTK Query。两者一起用会不会混乱？不会，边界划清就行：接口返回的数据归 React Query，用户在页面上的交互状态归客户端状态库。最怕的是同一份数据两边各存一份。写段代码const { data: user } = useQuery({ queryKey: ['user', id], queryFn: () => fetchUser(id),});const theme = useSelector(state => state.ui.theme);

React Query 的高级特性主要解决三个问题：按条件发请求、同时发多个请求、让缓存数据在合适时机变新。依赖查询用 enabled 控制执行时机；并行查询用多个 useQuery 或 useQueries；窗口聚焦重新获取用 refetchOnWindowFocus 保证页面回来时数据不过期。回答时要补一句：这些能力都围绕服务器状态，不是替代本地 UI 状态。追问依赖查询为什么不用 if 包住 useQuery？Hook 不能放进条件语句里，否则调用顺序会变。正确做法是始终调用 useQuery，用 enabled: !!id 控制是否真正请求。多个 useQuery 和 useQueries 怎么选？数量固定时直接写多个 useQuery，可读性更好。数量来自数组时用 useQueries，例如按一批 id 拉详情。refetchOnWindowFocus 会不会导致请求太多？会，所以后台管理页、实时看板适合开启；编辑表单、低频静态数据可以关闭，或配合 staleTime 降低重复请求。无限滚动靠什么实现？用 useInfiniteQuery，关键是 getNextPageParam 返回下一页参数，返回 undefined 表示没有更多。写段代码const user = useQuery({ queryKey: ['user', id], queryFn: getUser });const posts = useQuery({ queryKey: ['posts', user.data?.id], queryFn: () => getPosts(user.data.id), enabled: !!user.data?.id, staleTime: 60_000, refetchOnWindowFocus: true,});const results = useQueries({ queries: ids.map(id => ({ queryKey: ['todo', id], queryFn: () => getTodo(id) }))});

React Query 的错误处理要分两层：组件里展示用户能看懂的错误，全局里做日志和兜底通知。重试不要一刀切，网络抖动和 5xx 可以重试，401、403、404、表单校验这类 4xx 通常不该重试；否则只是把错误请求重复打到服务端。追问retry 默认是几次？浏览器端查询默认会重试 3 次，并使用退避延迟；服务端渲染场景通常不建议重试太多，否则会拖慢响应。retry 和 refetch 有什么区别？retry 是一次请求失败后的自动补救，refetch 是用户或程序主动重新拉取。错误页里的“再试一次”通常调用 refetch 或 reset error boundary。Mutation 失败要怎么处理？如果做了乐观更新，onMutate 里先保存旧数据，onError 里回滚，再提示用户。不要只弹 toast，却让缓存停在错误状态。全局 onError 适合做什么？适合上报 Sentry、统一 toast、处理登录过期。具体页面文案仍应在业务组件里判断。写段代码useQuery({ queryKey: ['todos'], queryFn: getTodos, retry: (count, error: any) => { if ([400, 401, 403, 404].includes(error.status)) return false; return count < 3; }, retryDelay: i => Math.min(1000 * 2 ** i, 30_000),});

React Query 接入 Suspense 后，加载状态交给 Suspense fallback，错误交给 Error Boundary。实际项目里优先用 useSuspenseQuery，而不是在每个组件里判断 isLoading。注意：开启 Suspense 不代表不用管错误，网络失败会抛给最近的错误边界；如果要让“重试”按钮生效，还要配 QueryErrorResetBoundary。追问useSuspenseQuery 和 useQuery 有什么区别？useSuspenseQuery 成功返回时 data 一定有值，加载中会挂起组件。你少写了 loading 分支，但必须准备好 Suspense 和错误边界。Error Boundary 应该放在哪里？放在页面块级别通常最合适。太外层会导致整页白掉，太内层又会让错误处理重复。有缓存时还会进入 fallback 吗？已有可用缓存时通常直接渲染；queryKey 改变触发新请求时，可能再次 fallback。交互更新可用 startTransition 降低界面闪烁。SSR 里能直接用吗？要谨慎。Next.js 等场景通常配合预取、dehydrate/hydrate，或使用框架推荐的 Suspense 数据方案。写段代码<QueryErrorResetBoundary> {({ reset }) => ( <ErrorBoundary onReset={reset} fallbackRender={({ resetErrorBoundary }) => ( <button onClick={resetErrorBoundary}>重试</button> )}> <Suspense fallback={<Spinner />}> <UserPanel /> </Suspense> </ErrorBoundary> )}</QueryErrorResetBoundary>

项目里不要把 useQuery 散落在组件里。更稳的做法是按业务域组织：API 函数只负责请求，自定义 Hook 负责暴露查询，query key 工厂负责命名和失效。query key 用数组，从宽到窄写，比如 ['users', 'detail', id]；凡是 queryFn 依赖的参数都必须进 key，否则缓存可能串数据。追问为什么不建议直接写字符串 key？字符串很难表达层级，也不方便批量失效。数组 key 可以让你失效整个用户域、某个详情页，或某个筛选列表。API 函数和 Hook 为什么要分开？API 函数可独立测试，也能被预取、SSR、mutation 复用。Hook 里再放 staleTime、enabled、select 等 React Query 配置。项目结构按 api、hooks 分，还是按 feature 分？小项目都可以；中大型项目更推荐 feature 分组，例如 features/user/api.ts、queries.ts、keys.ts，修改用户模块时不用跨目录找文件。命名上最容易踩什么坑？列表和详情共用一个 key、筛选条件没放进 key、mutation 成功后失效范围太大。这些都会造成脏数据或无意义重请求。写段代码export const userKeys = { all: ['users'] as const, detail: (id: string) => [...userKeys.all, 'detail', id] as const,};export function useUser(id: string) { return useQuery({ queryKey: userKeys.detail(id), queryFn: () => getUser(id), staleTime: 60_000, });}

WebRTC 是浏览器里的实时音视频和数据通信能力，核心价值是不用插件就能让两个端建立低延迟连接。它主要由三块组成：媒体采集用 getUserMedia 拿摄像头、麦克风；连接与协商用 RTCPeerConnection 处理 SDP、ICE、加密和媒体传输；任意数据传输用 RTCDataChannel。另外要记住：WebRTC 不自带信令服务，房间、呼叫、offer/answer 和 candidate 交换通常由业务用 WebSocket 或 HTTP 自己实现。追问WebRTC 是完全点对点吗？不一定。能直连时媒体可以 P2P；直连失败会走 TURN 中继；多人会议通常还会用 SFU 转发媒体流，所以“WebRTC 等于 P2P”这个说法不准确。RTCPeerConnection 具体负责什么？它负责创建 offer/answer、管理 ICE 候选、建立 DTLS/SRTP 安全传输，并把本地媒体轨道发送给对端。简单说，它是 WebRTC 连接的核心对象。信令为什么不算 WebRTC 标准的一部分？因为不同业务的房间模型、鉴权、重连和消息格式差异很大。标准只规定浏览器如何生成 SDP 和 candidate，至于怎么传给对端，由业务决定。getUserMedia 和 RTCDataChannel 有什么区别？getUserMedia 采集音视频流，适合通话、录制、屏幕共享。RTCDataChannel 传任意数据，适合聊天、白板同步、文件分片或游戏状态同步。写段代码const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true })const pc = new RTCPeerConnection({ iceServers })stream.getTracks().forEach(track => pc.addTrack(track, stream))const channel = pc.createDataChannel('chat')

WebRTC 的 NAT 穿透不是靠某一个协议硬打洞，而是由 ICE 统一调度：先收集本地地址，再用 STUN 拿到公网映射地址，最后在直连失败时走 TURN 中继。面试里可以这样答：STUN 负责“我在公网看起来是谁”，TURN 负责“直连不通时替我转发”，ICE 负责“把所有候选路径试一遍，选能通且质量最好的”。生产环境只配 STUN 不够，遇到对称 NAT、企业防火墙或 UDP 被限制时，必须有 TURN 兜底。追问STUN 和 TURN 有什么区别？STUN 只参与建连阶段，帮助发现公网 IP 和端口，媒体流通常仍然点对点传输。TURN 会一直在媒体路径上转发数据，成功率高，但延迟、带宽成本和服务器压力都更大。ICE 候选者有哪些？常见有 host、srflx、relay 三类。host 是本机局域网地址，srflx 是 STUN 得到的公网映射地址，relay 是 TURN 分配的中继地址。为什么有 STUN 还需要 TURN？因为 STUN 依赖 NAT 映射可预测。对称 NAT 或严格防火墙下，对端无法直接打到这个映射端口，TURN 中继就成了最后的可用路径。实际项目里怎么配置？至少配置一个 STUN 和一个带鉴权的 TURN，TURN 建议靠近用户部署。监控里要看 relay 占比、ICE 失败率、连接耗时和 RTT，relay 占比突然升高通常说明网络或 STUN 可用性出问题。写段代码const pc = new RTCPeerConnection({ iceServers: [ { urls: 'stun:stun.l.google.com:19302' }, { urls: 'turn:turn.example.com:3478', username: 'u', credential: 'p' } ]})pc.onicecandidate = e => sendToPeer(e.candidate)

Canvas 图像处理就是四步：drawImage 把图片、视频帧或另一个 Canvas 画上去；getImageData 读出像素；修改 data 里的 RGBA；再用 putImageData 写回。data 是 Uint8ClampedArray，每个像素 4 个值，位置从 i * 4 开始。九参数 drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh) 可同时裁剪和缩放，雪碧图截帧、头像裁剪常用。跨域图必须服务端开 CORS，并给图片设置 crossOrigin="anonymous"，否则读像素会抛 SecurityError。追问Canvas 橡皮擦怎么做？把 globalCompositeOperation 设成 destination-out，新画的区域会从旧内容里挖掉。蒙版常用 source-in，发光叠加可用 lighter。灰度滤镜为什么不用 RGB 平均值？人眼对绿色更敏感，常用 0.299R + 0.587G + 0.114B 算亮度，视觉效果比简单平均自然。大图逐像素处理很卡怎么办？用 OffscreenCanvas + Worker，把像素循环放到子线程；静态图层先离屏缓存；只改局部时用 putImageData 的脏矩形参数，别全画布回写。处理后的图片怎么导出？推荐 canvas.toBlob(cb, "image/jpeg", 0.92)，异步且省内存。toDataURL() 同步生成 Base64，只适合小图预览。写段代码function grayscale(imageData) { const d = imageData.data; for (let i = 0; i < d.length; i += 4) { const gray = d[i] * 0.299 + d[i + 1] * 0.587 + d[i + 2] * 0.114; d[i] = d[i + 1] = d[i + 2] = gray; } return imageData;}

if 适合判断条件真假，比如文件是否存在、变量是否为空、命令是否执行成功；case 适合一个变量匹配多个模式，比如菜单选项、文件后缀、运行环境。写 Shell 条件判断时，变量要加引号，复杂字符串判断优先用 [[ ]]，数字计算用 (( ))。追问[ ] 和 [[ ]] 有什么区别？[ ] 是传统 test 写法，兼容性好但限制多；[[ ]] 是 Bash 扩展，支持 &&、||、模式匹配和正则，变量未加引号时也更不容易出错。写 Bash 脚本通常优先用 [[ ]]。if 能直接判断命令结果吗？可以。if grep -q "ERROR" app.log; then ... fi 判断的是命令退出码，0 表示成功，非 0 表示失败。这比手动判断 $? 更清晰。case 适合替代多个 elif 吗？当你围绕同一个变量做多分支匹配时，case 更清楚。它支持通配符，比如 *.log)、start|restart)，最后用 *) 兜底。常见坑是什么？[ $name = foo ] 在变量为空时会语法错误，应该写 [ "$name" = "foo" ]。另外 -a、-o 可读性差，建议拆成 [ cond1 ] && [ cond2 ]。写段代码file="$1"if [[ -f "$file" && -r "$file" ]]; then echo "readable file"ficase "$file" in *.sh) echo "shell script" ;; *.log) echo "log file" ;; *) echo "unknown" ;;esac

Shell 文本处理常用四件套：grep 负责找行，sed 负责按规则改行，awk 负责按列计算和格式化，cut 负责简单切字段。判断工具时别背命令，先看问题：是搜索、替换、列处理，还是固定分隔符提取。追问grep 适合什么？适合按关键字或正则筛选行。常用参数是 -i 忽略大小写、-n 显示行号、-r 递归目录、-v 反向过滤。sed 和 awk 怎么区分？sed 更像“流式编辑器”，擅长替换、删除、打印某段行；awk 更像“小型报表工具”，擅长按字段取列、条件过滤、求和统计。cut 还有必要学吗？有。字段分隔很固定时，cut -d ':' -f1 比 awk 更直接。但它不擅长复杂条件，也不适合多空格混合的文本。实际排日志会怎么组合？先用 grep 缩小范围，再用 awk 提取字段，最后用 sort | uniq -c 统计。管道里每一步只做一件事，脚本会更好查错。写段代码# 查 ERROR，提取第 5 列 IP，统计出现次数grep "ERROR" app.log | awk '{print $5}' | sort | uniq -c | sort -nr# 批量替换配置sed -i.bak 's/port=8080/port=9090/' app.conf

Shell 数组主要分两类：普通数组和关联数组。普通数组用数字下标，适合保存文件名、参数列表；关联数组用字符串 key，适合保存配置。写脚本时最重要的一点是：访问数组尽量用双引号包住 "${arr[@]}"，否则遇到空格文件名会翻车。追问普通数组怎么定义和读取？普通数组用空格分隔定义，索引从 0 开始。${arr[0]} 取第一个元素，${arr[@]} 取全部元素，${#arr[@]} 取长度。${arr[@]} 和 ${arr[*]} 有什么区别？加双引号时区别最大："${arr[@]}" 会保留每个元素的边界，"${arr[*]}" 会把所有元素拼成一个字符串。遍历数组时优先用 "${arr[@]}"。关联数组怎么用？Bash 4+ 支持关联数组，必须先 declare -A map。例如 map[host]=localhost，读取用 ${map[host]}，遍历 key 用 ${!map[@]}。删除数组元素会重新编号吗？不会。unset arr[1] 只删除该位置，其他索引不变，所以遍历稀疏数组时用 ${!arr[@]} 更稳。写段代码arr=("a.txt" "b file.txt")arr+=("c.txt")for i in "${!arr[@]}"; do echo "$i => ${arr[$i]}"donedeclare -A conf=([host]="127.0.0.1" [port]="3306")echo "${conf[host]}:${conf[port]}"

OpenCV.js 在浏览器里不能只看 script onload，真正可用要等 WASM 运行时初始化完成。常见方式有三种：CDN 引入、本地静态文件、npm 包。最稳的判断是监听 cv.onRuntimeInitialized，否则很容易出现 cv.imread is not a function 或方法尚未挂载的问题。追问CDN 怎么写才安全？script 的 onload 只代表文件下载完成，不代表 OpenCV 运行时准备好了。应在 onload 里设置 cv.onRuntimeInitialized，初始化完成后再启用按钮或调用图像处理逻辑。npm 包适合什么场景？适合工程化项目，比如 React、Vue。@techstark/opencv-js 用起来方便，但仍要处理异步初始化，不能在模块导入后立刻假设所有 API 都可用。加载慢怎么办？OpenCV.js 体积通常较大，建议使用 CDN 缓存、gzip/br 压缩、按需加载，并把初始化状态做成 Promise，避免多个组件重复加载。浏览器兼容要注意什么？OpenCV.js 依赖 WebAssembly，老旧浏览器支持不好。读取跨域图片时还要配置 CORS，否则 cv.imread 背后的 Canvas 读取会因为安全策略失败。写段代码<script async src="https://docs.opencv.org/4.x/opencv.js" onload="initCv()"></script><script>function initCv() { cv.onRuntimeInitialized = () => { console.log('OpenCV.js ready'); document.querySelector('#run').disabled = false; };}</script>

OpenCV.js 是把 OpenCV 编译到 WebAssembly/JavaScript 后在浏览器或 Node.js 里运行；原生 OpenCV 通常指 C++、Python、Java 版本，跑在桌面、服务器或移动端。两者算法体系相近，但运行环境、性能、内存管理和部署方式差异很大：前者胜在纯前端和隐私，后者胜在性能、硬件能力和完整生态。追问API 一样吗？很多函数名接近，比如 cvtColor、GaussianBlur、Canny，但写法不完全一样。OpenCV.js 使用 cv.Mat、cv.MatVector，更像 C++ API 的 JS 绑定，不是普通前端库那种链式风格。性能差多少？OpenCV.js 借助 WebAssembly 已经很快，但仍受浏览器、设备、内存和线程限制。大图批处理、高清视频流、GPU/硬件加速场景，原生 OpenCV 通常更稳。内存管理有什么坑？OpenCV.js 的 cv.Mat 不靠 JS 垃圾回收释放，必须手动 delete()。忘记释放会造成 WASM 内存泄漏，长时间视频处理时尤其明显。浏览器里还有哪些限制？跨域图片会污染 Canvas，导致无法读像素；摄像头需要用户授权；大文件和大分辨率图像会受浏览器内存限制。原生 OpenCV 访问文件、摄像头和硬件更直接。实际怎么选？网页端预览、滤镜、轻量识别、隐私敏感场景选 OpenCV.js；服务器批处理、高性能视频分析、工业视觉、模型训练或硬件加速场景选原生 OpenCV。写段代码const mat = cv.imread(image);try { cv.cvtColor(mat, mat, cv.COLOR_RGBA2GRAY); cv.imshow('canvas', mat);} finally { mat.delete();}

OpenCV.js 适合做“看懂图像”的任务，比如边缘检测、轮廓识别、模板匹配、视频帧处理；Fabric.js、p5.js、Three.js 更偏“画出来”和交互展示；TensorFlow.js 适合跑模型做分类、检测、分割。选型不要只看库名，先看需求是图像处理、交互编辑、3D 渲染，还是机器学习推理。追问OpenCV.js 相比 Fabric.js 强在哪？OpenCV.js 强在传统计算机视觉算法，能做滤波、形态学、特征点、轮廓等处理。Fabric.js 强在 Canvas 对象模型、拖拽、缩放、文字和图形编辑，适合做海报编辑器，不适合复杂视觉算法。和 p5.js 怎么区分？p5.js 更适合创意编程、教学和视觉实验，API 友好，上手快。OpenCV.js 学习成本高，但处理边缘检测、透视变换、实时视频分析时更专业。和 TensorFlow.js 是竞争关系吗？不完全是。OpenCV.js 负责图像预处理和传统视觉算法，TensorFlow.js 负责模型推理。实际项目里常见组合是：OpenCV.js 裁剪、灰度化、归一化，再交给 TensorFlow.js 做识别。OpenCV.js 最大的坑是什么？包体大、API 偏 C++ 风格、cv.Mat 要手动 delete()，否则浏览器内存会涨。移动端实时视频处理还要控制分辨率，否则帧率很容易掉。项目里怎么选？图像编辑器选 Fabric.js；创意互动选 p5.js；3D 场景选 Three.js；AI 识别选 TensorFlow.js；需要浏览器里做专业图像处理，再选 OpenCV.js。写段代码const src = cv.imread(img);const gray = new cv.Mat();try { cv.cvtColor(src, gray, cv.COLOR_RGBA2GRAY); cv.imshow('canvas', gray);} finally { src.delete(); gray.delete();}

Spring Boot 启动本质上是 SpringApplication.run() 创建并刷新 Spring 容器的过程。主线可以记成：创建 SpringApplication、准备 Environment、创建 ApplicationContext、刷新容器、启动 WebServer、执行 Runner、发布 ready 事件。真正初始化 Bean、自动配置和启动内嵌 Tomcat 的核心都发生在 refreshContext() 里的 ApplicationContext.refresh()。追问SpringApplication 实例化时做了什么？它会推断应用类型：Servlet、Reactive 或普通应用；再加载 ApplicationContextInitializer、ApplicationListener，并推断 main 方法所在主类。这一步还没创建业务 Bean，只是在准备启动所需的元信息。Environment 是什么时候准备的？在创建 ApplicationContext 之前。Spring Boot 会合并命令行参数、系统属性、环境变量、application.yml/properties 和 profile 配置，再发布 ApplicationEnvironmentPreparedEvent。refresh() 为什么最关键？因为它会加载 BeanDefinition、执行 BeanFactoryPostProcessor、注册 BeanPostProcessor、实例化非懒加载单例 Bean。Servlet 应用的内嵌 Tomcat/Jetty 通常也在刷新过程的 onRefresh() 阶段创建并启动。Runner 在什么时候执行？ApplicationRunner 和 CommandLineRunner 在容器刷新完成、ApplicationStartedEvent 发布后执行。它们适合做启动后的初始化任务，但不要放耗时阻塞逻辑，否则应用迟迟到不了 ready 状态。启动失败会发生什么？Spring Boot 会发布 ApplicationFailedEvent，销毁已创建的 Bean，并把异常继续抛出。排查启动问题时，重点看 Environment、自动配置条件和 Bean 创建异常。写段代码@SpringBootApplicationpublic class App { public static void main(String[] args) { SpringApplication.run(App.class, args); }}

Axios 拦截器就是请求发出前、响应返回后统一插一层处理逻辑。请求拦截器常用来加 token、加请求 ID、处理 loading；响应拦截器常用来拆 data、统一处理业务错误、401 登录失效和网络异常。项目里一般不要直接改全局 axios，而是 axios.create() 建实例，再给实例挂拦截器，避免多个后端服务互相污染配置。追问请求拦截器和响应拦截器分别适合做什么？请求拦截器改 config，比如加 Authorization、baseURL、防缓存参数。响应拦截器处理 response 或 error，比如把 { code, data, message } 统一拆成 data 返回。多个拦截器的执行顺序是什么？请求拦截器后添加的先执行，响应拦截器先添加的先执行。排查问题时要注意顺序，否则 token 还没加上，请求日志就已经打印了旧配置。loading 为什么不能简单请求开始显示、结束隐藏？并发请求会出问题。第一个请求结束就隐藏 loading，但其他请求还没回来。常见做法是维护计数器，请求加一，响应或错误减一，减到 0 再隐藏。什么时候要移除拦截器？临时调试、微前端子应用卸载、某个页面单独加拦截逻辑时要 eject，否则重复注册会导致同一个错误提示弹很多次。写段代码const api = axios.create({ baseURL: '/api', timeout: 10000 });api.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) config.headers.Authorization = `Bearer ${token}`; return config;});api.interceptors.response.use( res => res.data, err => Promise.reject(err.response?.data || err));

Axios 错误处理先看三类：error.response 表示服务端返回了非 2xx 状态码，重点处理 400、401、403、404、5xx；error.request 表示请求发出但没收到响应，多半是网络、超时、CORS；两者都没有通常是请求配置写错。实际项目里建议：业务层只处理当前页面关心的错误，全局拦截器统一做登录失效、错误提示、日志和重试。追问error.response 和 error.request 有什么区别？response 说明后端有响应，只是状态码失败；request 说明请求发出去了但没有拿到响应。前者看 status 和 data.message，后者看 code，比如 ECONNABORTED 或 ERR_NETWORK。401 应该在每个接口里处理吗？不要。401 属于全局认证问题，放响应拦截器里统一清 token、跳登录页或刷新 token。页面里只关心业务错误，比如表单校验失败。超时和 5xx 要不要自动重试？可以，但只重试幂等请求，比如 GET。POST、支付、下单这类接口不能盲目重试，否则可能造成重复提交。实际项目里最容易踩什么坑？拦截器里 return Promise.reject(error) 忘了写，外层 catch 拿不到错误；另一个坑是把所有错误都弹 toast，导致 401 跳转时还弹一堆无意义提示。写段代码axios.interceptors.response.use(r => r.data, error => { if (error.response) { const { status, data } = error.response; if (status === 401) { localStorage.removeItem('token'); location.href = '/login'; } return Promise.reject(new Error(data?.message || `HTTP ${status}`)); } if (error.code === 'ECONNABORTED') { return Promise.reject(new Error('请求超时')); } return Promise.reject(new Error(error.message || '网络错误'));});

Android 内存泄漏本质是对象生命周期结束了，却还被 GC Roots 间接引用，导致无法回收。高频场景有：静态变量持有 Activity、非静态 Handler 或匿名内部类持有外部类、监听器/广播未注销、线程或网络请求未取消、Cursor/IO 流未关闭、集合缓存长期保存 View 或 Context。检测优先用 LeakCanary 看引用链，复杂问题再用 Android Studio Memory Profiler 抓 Heap Dump。避免原则很简单：谁注册谁注销，谁启动谁取消，长生命周期对象不要持有短生命周期 Context。追问为什么静态变量持有 Activity 会泄漏？静态变量生命周期接近进程，Activity 销毁后如果仍被它引用，GC 无法回收整个 Activity 以及关联 View 树。需要 Context 时优先传 applicationContext。Handler 为什么容易泄漏？非静态内部 Handler 会隐式持有 Activity，消息队列里的 Message 又持有 Handler。Activity 销毁后消息没执行完，就会延长 Activity 生命周期。LeakCanary 主要看什么？重点看泄漏对象到 GC Root 的引用链，找到第一个不该长期持有它的对象。不要只看类名，要结合页面生命周期判断是不是误报。项目里怎么避免监听器泄漏？在 onStart/onStop 或 onCreate/onDestroy 成对注册和注销。使用 LifecycleObserver、协程 lifecycleScope、Flow repeatOnLifecycle 可以减少手动清理遗漏。写段代码static class SafeHandler extends Handler { private final WeakReference<Activity> ref; SafeHandler(Activity activity) { ref = new WeakReference<>(activity); } @Override public void handleMessage(Message msg) { Activity a = ref.get(); if (a == null || a.isFinishing()) return; }}@Override protected void onDestroy() { handler.removeCallbacksAndMessages(null); super.onDestroy();}

View 的绘制流程一句话就是：从 ViewRootImpl 发起，依次执行 measure、layout、draw。measure 负责算宽高，核心是父 View 传下来的 MeasureSpec；layout 负责确定 left、top、right、bottom；draw 负责真正画到 Canvas 上。自定义 View 里最常见的问题是只重写 onDraw，却忘了在 onMeasure 处理 wrap_content。尺寸或位置变化用 requestLayout，内容变化用 invalidate，别混着用。追问MeasureSpec 有哪几种模式？EXACTLY 表示确定尺寸，常见于固定 dp 或 matchparent；ATMOST 表示最大不能超过某个值，常见于 wrap_content；UNSPECIFIED 表示父容器不限制，ScrollView 测子 View 时可能出现。ViewGroup 和普通 View 的绘制有什么区别？ViewGroup 在 measure 阶段要测量子 View，在 layout 阶段摆放子 View，在 draw 阶段通过 dispatchDraw 绘制子 View。普通 View 通常只关心自己的测量和 onDraw。requestLayout 和 invalidate 有什么区别？requestLayout 会重新走 measure、layout，必要时再 draw；invalidate 只触发重绘。改文字大小、宽高、位置用 requestLayout，改颜色、进度、选中态通常用 invalidate。实际项目里容易踩什么坑？自定义 View 如果 wrap_content 不设置默认尺寸，可能测出来是 0 或不符合预期。另一个坑是在 onDraw 里频繁 new Paint、Path、Rect，会造成 GC 抖动和掉帧。写段代码@Overrideprotected void onMeasure(int widthSpec, int heightSpec) { int defaultW = dp(120); int defaultH = dp(48); int w = resolveSize(defaultW, widthSpec); int h = resolveSize(defaultH, heightSpec); setMeasuredDimension(w, h);}@Overrideprotected void onDraw(Canvas canvas) { super.onDraw(canvas); canvas.drawCircle(getWidth() / 2f, getHeight() / 2f, radius, paint);}