服务端面试题手册

YAML 和 JSON 都是数据序列化格式，核心区别在于设计目标不同：YAML 追求人类可读，JSON 追求机器解析效率。YAML 用缩进表示层级，支持注释、多行字符串、对象引用（&/*）和更丰富的数据类型（日期、二进制等）；JSON 用大括号和方括号表示结构，语法严格但不支持注释，数据类型只有字符串、数字、布尔、null、对象和数组六种。选择依据很简单：需要人手写和阅读的用 YAML（配置文件、CI/CD、K8s 清单），需要机器快速解析和跨系统传输的用 JSON（API 响应、日志、数据存储）。性能上 JSON 解析速度通常是 YAML 的 5-10 倍，因为 YAML 规范复杂（1.2 规范 80+ 页），解析器要做更多推断。兼容性方面，YAML 是 JSON 的超集——合法的 JSON 一定是合法的 YAML，反过来不行。追问YAML 解析为什么比 JSON 慢那么多？YAML 规范支持大量隐式类型推断（比如 true/false/yes/no 都能识别为布尔值）、锚点和别名、多文档流等特性，解析器必须处理这些边界情况。JSON 只有 6 种数据类型，语法规则简单到可以用一个状态机完整描述，解析路径几乎是确定性的。实际项目中 YAML 解析耗时通常是 JSON 的 5-10 倍，配置文件体积大的时候差距更明显。YAML 的缩进坑踩过吗？踩过。最常见的是 Tab 和空格混用——YAML 只允许空格缩进，混入一个 Tab 就会报解析错误，而且报错信息往往指向错误的行号。另一个坑是冒号后面没加空格，key:value 在 YAML 里不会被识别为键值对，必须写成 key: value。还有布尔值陷阱：yes/no/on/off 在 YAML 1.1 里会被解析为 true/false，如果你本意是字符串，得加引号。Kubernetes 和 CI/CD 配置里这些问题特别容易踩。项目里有没有 YAML 和 JSON 混用的场景？有。Spring Boot 项目里 application.yml 写配置，但外部化配置覆盖时用环境变量或 JSON 格式的配置中心下发；CI/CD 流水线的触发配置是 JSON（比如 GitHub webhook payload），但流水线定义文件是 YAML。还有些工具支持两种格式互转，比如 yq 处理 YAML、jq 处理 JSON，管道组合着用。YAML 的锚点和别名实际用在哪？Kubernetes 的 ConfigMap 和 Secret 复用场景。用 & 定义一个锚点，后面用 * 引用，避免同一份配置写多遍。比如多个 Deployment 引用同一个环境变量块：common-env: &common-env DB_HOST: db.example.com DB_PORT: "5432"deployment-a: env: *common-envdeployment-b: env: *common-env不过不是所有 YAML 解析器都支持锚点，Docker Compose 支持但有些轻量解析器不支持，用之前先确认。什么时候 JSON 反而比 YAML 更适合做配置文件？配置需要程序生成和修改的场景。比如 VS Code 的 settings.json——由扩展程序读写，JSON 格式方便序列化/反序列化，不需要注释（注释需求可以通过 _$comment 之类的字段变通解决）。还有需要严格 Schema 校验的场景，JSON Schema 生态比 YAML 的校验工具成熟得多，AJV 等库能做编译时校验，出错了能精确定位到行和字段。

YAML 1.1 和 YAML 1.2 的核心差异在于类型推断规则。YAML 1.1 对隐式类型推断非常激进——yes/no/on/off 全部解析为布尔值，010 解析为八进制 8，3:25:45 解析为六十进制秒数。YAML 1.2 砍掉了这些"聪明"的推断，只认 true/false 为布尔值，八进制必须写 0o10，六十进制格式直接移除。1.2 的目标是和 JSON 完全兼容——任何合法 JSON 都是合法的 YAML 1.2，但 1.1 做不到这点。最典型的坑是"Norway Problem"：用 YAML 1.1 写国家代码 NO（挪威），解析出来是布尔值 false。这在处理国际化数据时是真实踩过的坑。1.2 修复了这个问题，NO 就是字符串 "NO"。版本兼容性处理的关键：不要指望声明 %YAML 1.2 就万事大吉——PyYAML、LibYAML 这些主流库至今默认走 1.1 规则。实际做法是写配置时始终用 true/false 表布尔值、用引号包裹可能有歧义的字符串、八进制加 0o 前缀，这样不管解析器用的是哪个版本都不会出问题。追问YAML 1.2 具体移除了哪些 YAML 1.1 的类型？移除了五个类型标签：!!pairs（有序键值对序列）、!!omap（无重复有序映射）、!!set（集合）、!!timestamp（时间戳）、!!binary（二进制数据）。另外 merge key << 和 value key = 这两个特殊映射键也移除了。<< 在 1.1 里用来做锚点合并，很多人依赖它做配置继承，迁移时要改成显式写法。为什么 PyYAML 还在用 YAML 1.1？历史包袱太重。PyYAML 基于 LibYAML（C 实现），改动底层类型推断会影响大量现有配置文件的解析结果。社区有 ruamel.yaml 作为 1.2 的替代方案，但 PyYAML 因为存量用户太多不敢贸然切换默认行为。实际项目中如果需要 1.2，用 ruamel.yaml 并指定 version=(1, 2) 即可。同一份 YAML 文件在 1.1 和 1.2 下解析结果不同，怎么排查？重点检查三类值：布尔值（yes/no/on/off）、以 0 开头的数字（八进制 vs 十进制）、以及六十进制时间格式。用两个解析器分别加载同一文件，对比输出差异。Python 里可以同时用 PyYAML 和 ruamel.yaml 跑一遍，JavaScript 的 js-yaml 默认走 1.2 规则可以直接对比。YAML 1.1 的 sexagesimal 格式是什么？六十进制数字，写成 3:25:45 这种形式，解析为 12345 秒。YAML 1.2 移除了这个格式，同样的写法在 1.2 里就是普通字符串。如果你的配置里用了时间格式如 12:30:00，在 1.1 下会被解析成数字 45000，1.2 下是字符串 "12:30:00"——这也是迁移时容易踩的坑。

获取 Canvas 2D 上下文通过 canvas.getContext('2d') 获取 2D 渲染上下文，返回 CanvasRenderingContext2D 对象：const canvas = document.getElementById('myCanvas');const ctx = canvas.getContext('2d');实际开发中建议做兼容性检查：const canvas = document.querySelector('canvas');if (!canvas?.getContext) { throw new Error('当前浏览器不支持 Canvas');}const ctx = canvas.getContext('2d');注意：同一个 Canvas 元素多次调用 getContext('2d') 返回的是同一个上下文对象，不会重复创建。基本绘制方法分类Canvas 2D 的绘制方法可以按用途分为以下几类：矩形绘制矩形是 Canvas 中唯一可以直接绘制的图形，不需要路径：| 方法 | 说明 ||------|------|| fillRect(x, y, w, h) | 绘制填充矩形 || strokeRect(x, y, w, h) | 绘制矩形边框 || clearRect(x, y, w, h) | 清除矩形区域（变为透明） |路径绘制所有非矩形图形都需要通过路径来绘制：ctx.beginPath(); // 开始新路径ctx.moveTo(50, 50); // 移动画笔到起点ctx.lineTo(200, 50); // 画直线到 (200, 50)ctx.arc(150, 100, 40, 0, Math.PI * 2); // 画圆弧ctx.closePath(); // 闭合路径ctx.fill(); // 填充ctx.stroke(); // 描边核心路径方法：beginPath() — 开始新路径（不会清除已有路径）moveTo(x, y) / lineTo(x, y) — 移动/画直线arc(x, y, r, startAngle, endAngle) — 画圆弧或圆closePath() — 从当前点回到路径起点fill() / stroke() — 填充或描边当前路径样式设置绘制前设置样式，影响后续所有绘制操作：ctx.fillStyle = '#ff6600'; // 填充颜色ctx.strokeStyle = 'rgba(0,0,255,0.8)'; // 描边颜色ctx.lineWidth = 3; // 线宽ctx.lineCap = 'round'; // 线帽样式：butt | round | squarectx.lineJoin = 'miter'; // 连接样式：miter | round | bevel文本绘制ctx.font = '24px sans-serif';ctx.textAlign = 'center';ctx.textBaseline = 'middle';ctx.fillText('Hello Canvas', 100, 100); // 填充文本ctx.strokeText('Hello Canvas', 100, 100); // 描边文本配合 measureText() 可以精确计算文本宽度：const metrics = ctx.measureText('Hello');console.log(metrics.width); // 文本像素宽度图像绘制drawImage() 支持三种调用方式：// 基础：原尺寸绘制ctx.drawImage(img, dx, dy);// 缩放：指定目标尺寸ctx.drawImage(img, dx, dy, dWidth, dHeight);// 裁剪：从源图裁剪区域绘制到目标区域ctx.drawImage(img, sx, sy, sWidth, sHeight, dx, dy, dWidth, dHeight);状态保存与恢复这是面试高频考点。Canvas 通过栈结构管理绘制状态：ctx.save(); // 将当前状态（样式、变换等）压入栈// ... 修改样式、变换 ...ctx.restore(); // 从栈中弹出并恢复最近一次 save 的状态典型场景：绘制多个不同样式的图形时，用 save/restore 避免样式互相污染。一个完整示例把上面的方法组合起来，绘制一个带标题的彩色柱状图：const canvas = document.getElementById('chart');const ctx = canvas.getContext('2d');const data = [ { label: 'A', value: 120, color: '#ff6600' }, { label: 'B', value: 80, color: '#0066ff' }, { label: 'C', value: 150, color: '#00cc66' },];const barWidth = 60;const gap = 30;const baseY = 250;data.forEach((item, i) => { const x = 40 + i * (barWidth + gap); const height = item.value; // 绘制柱子 ctx.fillStyle = item.color; ctx.fillRect(x, baseY - height, barWidth, height); // 绘制标签 ctx.save(); ctx.fillStyle = '#333'; ctx.font = '14px sans-serif'; ctx.textAlign = 'center'; ctx.fillText(item.label, x + barWidth / 2, baseY + 20); ctx.fillText(String(item.value), x + barWidth / 2, baseY - height - 8); ctx.restore();});常见追问Q：Canvas 和 SVG 的区别是什么？Canvas 是像素级绘制，适合高频重绘场景（游戏、图表动画）；SVG 是矢量图形，通过 DOM 操作，适合交互式静态图形。Canvas 绘制后无法单独操作某个图形元素，SVG 可以。Q：如何实现 Canvas 动画？核心思路是清空画布 + 重绘。用 clearRect 清除上一帧，再绘制新帧，配合 requestAnimationFrame 控制帧率。需要避免在每帧中创建对象，减少 GC 压力。Q：Canvas 绘制模糊怎么解决？这是高 DPI 屏幕的常见问题。需要将 Canvas 的实际像素尺寸设为 CSS 尺寸的 devicePixelRatio 倍，再用 ctx.scale(dpr, dpr) 缩放上下文。

在 Cypress 测试中，动态内容（AJAX 请求、异步渲染、第三方 API）是最常见的测试不稳定来源。核心解法是两个机制：cy.wait() 精确等待网络请求，以及 Cypress 内置的重试能力（retry-ability）。下面逐一说明。cy.wait()：精确等待网络请求cy.wait() 的正确用途是等待已拦截的网络请求完成，而非硬编码等待时间。基本用法// 先拦截，再触发，最后等待cy.intercept('POST', '/api/login').as('loginReq');cy.get('#login-btn').click();cy.wait('@loginReq'); // 等到该请求完成才继续关键参数timeout：超时时间，默认 5000ms，可按场景调整response：可直接断言响应内容cy.wait('@loginReq', { timeout: 8000 }) .its('response.statusCode') .should('eq', 200);等待多个请求cy.intercept('GET', '/api/user').as('userReq');cy.intercept('GET', '/api/profile').as('profileReq');cy.visit('/dashboard');cy.wait(['@userReq', '@profileReq']);常见错误用 cy.wait(3000) 硬编码等待——这是反模式，应改为等待具体请求或元素状态别名未定义就 cy.wait('@xxx')——会直接报错在 cy.wait() 内嵌套其他命令——会导致执行顺序混乱重试能力：Cypress 的核心设计Cypress 的重试机制和很多人理解的不一样。它不是"失败后重试 3 次"，而是查询类命令在超时时间内持续重试直到断言通过。工作原理cy.get()、cy.contains()、.should() 等查询命令会不断重新查询 DOM，直到找到匹配元素或超时。这不是固定的"3 次"，而是在 defaultCommandTimeout（默认 4000ms）内持续尝试。// 这行代码会在 4 秒内不断查询 #result 是否可见cy.get('#result').should('be.visible');配置超时// 全局配置Cypress.config('defaultCommandTimeout', 6000);// 单条命令单独设置cy.get('#slow-element', { timeout: 10000 }).should('exist');不可重试的命令注意，cy.click()、cy.type() 等动作类命令不会重试。如果元素还没出现就 click，会报错。正确做法是先确保元素存在：// 错误：元素可能还没加载cy.get('#submit').click();// 正确：先等待元素可操作cy.get('#submit').should('be.visible').click();实战最佳实践1. 优先用 cy.intercept + cy.wait 处理异步cy.intercept('GET', '/api/data').as('dataReq');cy.visit('/page');cy.wait('@dataReq');// 此刻数据已加载，后续断言稳定可靠2. 用 should 断言代替硬等待// 不要这样cy.wait(2000);cy.get('.item').should('have.length', 5);// 应该这样——Cypress 自动等待直到满足条件cy.get('.item').should('have.length', 5);3. 等待加载状态消失cy.get('.loading-spinner').should('not.exist');cy.get('.data-table').should('be.visible');4. 测试失败自动重试配置// cypress.config.jsmodule.exports = { retries: { runMode: 2, // CI 中失败重试 2 次 openMode: 0, // 本地开发不重试 },};cy.wait() 与重试能力的配合两者解决不同问题：cy.wait() 等待已知网络请求完成，重试能力等待未知时间的元素出现。实际项目中两者配合使用：// 典型模式：拦截请求 → 触发操作 → 等请求完成 → 断言 UIcy.intercept('POST', '/api/submit').as('submitReq');cy.get('#form').within(() => { cy.get('input[name="email"]').type('test@example.com'); cy.get('button[type="submit"]').click();});cy.wait('@submitReq').its('response.statusCode').should('eq', 200);cy.get('.success-msg').should('contain', '提交成功');核心原则：能等请求就等请求，不能等请求就用断言让 Cypress 自动重试，永远不要用固定时间等待。

Cypress 测试中，cy.get() 和 cy.find() 都能查找 DOM 元素，但行为差异很大。混用会导致测试不稳定甚至报错——比如 cy.get('.parent').get('.child') 看似在父元素内查找，实际上重新扫描了整个页面。本文从搜索范围、链式调用行为、性能差异三个维度讲清两者区别，并给出每个场景的选择依据。cy.get() 和 cy.find() 的本质区别核心差异只有一点：搜索起点不同。cy.get() 始终从文档根节点搜索，即使写在链式调用中也是如此cy.find() 从前一个命令返回的元素内部搜索，只查找后代节点// 看起来像在 #modal 内查找，实际不是cy.get('#modal').get('.btn'); // .btn 从整个页面搜索，不限于 #modal 内// 这才是只在 #modal 内查找cy.get('#modal').find('.btn'); // .btn 仅在 #modal 的后代中搜索这是面试中最常考的点：cy.get() 在链式调用中会"重置"搜索范围，而 cy.find() 保持在父元素作用域内。理解这一点后，其他区别都由此派生：搜索范围不同导致性能差异，链式行为不同导致匹配精度差异，独立性不同导致使用方式差异。对比表格| 特性 | cy.get() | cy.find() || ------------ | ------------------------- | -------------------------- || 搜索起点 | 文档根节点（全局） | 前一个命令的元素（局部） || 能否独立调用 | 能，cy.get('.item') | 不能，必须链在前一个命令后 || 链式行为 | 每次都从根节点重新搜索 | 在前一个元素的后代中搜索 || 典型错误 | 链式调用时期望限定范围但未限定 | 未接父元素直接调用，抛出错误 || 底层实现 | 等效于 document.querySelectorAll() | 等效于 element.querySelectorAll() |什么时候用 cy.get()三种典型场景：定位页面级唯一元素：导航栏、页面标题、主容器等。cy.get('nav.main-nav').should('be.visible');cy.get('h1').should('contain', 'Dashboard');测试初始化阶段：在 beforeEach 中确认页面已加载关键元素。beforeEach(() => { cy.visit('/login'); cy.get('form').should('exist'); // 确认表单渲染完成});配合 .within() 限定范围后使用：cy.within() 可以让 cy.get() 在指定容器内搜索，适合需要对同一容器内多个元素操作的场景。cy.get('#login-form').within(() => { cy.get('input[name="email"]').type('test@example.com'); cy.get('input[name="password"]').type('123456'); cy.get('button[type="submit"]').click();});注意 cy.within() 和 cy.find() 的区别：within() 创建一个作用域块，块内所有 cy.get() 都在容器内搜索；find() 只查找一次。如果需要对同一个父元素下的多个子元素操作，within() 更简洁；如果只查找一个子元素，find() 更直观。什么时候用 cy.find()三种典型场景：在已知容器内查找子元素：表单内的输入框、列表内的特定项。// 验证购物车列表中的商品数量cy.get('.cart-items').find('.cart-item').should('have.length', 3);// 查找某个表单内的提交按钮cy.get('#registration-form').find('button[type="submit"]').click();处理重复 class 的元素：页面上有多个 .btn，但只需要某个容器内的。// 页面有多个 .btn，只取 header 内的那个cy.get('header').find('.btn').click();// 对比：如果用 cy.get()，可能匹配到其他区域的 .btncy.get('header').get('.btn'); // 搜索整个页面，可能返回错误的按钮动态渲染的列表定位：滚动加载或异步渲染的内容。// 等待异步列表渲染完成后，在容器内查找最后一个元素cy.get('.infinite-list').find('.list-item:last').scrollIntoView();// 在动态插入的弹窗内查找关闭按钮cy.get('.modal.show').find('.close-btn').click();常见踩坑坑1：误以为 cy.get() 链式调用会限定范围这是最常见的错误。许多开发者认为 cy.get('.parent').get('.child') 等价于"在 .parent 内找 .child"，实际上两个 get() 是独立的全局搜索。// 错误理解：以为只在 .sidebar 内找 .activecy.get('.sidebar').get('.active'); // 实际找到页面上所有 .active// 正确做法cy.get('.sidebar').find('.active'); // 只在 .sidebar 后代中查找这个问题的根源在于 Cypress 的链式调用机制：cy.get() 总是创建一个新的查询，搜索范围重置为文档根节点。而 cy.find() 是在前一个查询结果的基础上继续搜索。坑2：cy.find() 不接父元素直接调用// 报错：cy.find() 必须接在另一个命令后面cy.find('.item'); // TypeError: cy.find() cannot be called standalone// 正确做法cy.get('.container').find('.item');// 也可以用 cy.wrap() 包裹 jQuery 对象后再 findcy.wrap($element).find('.child');坑3：混淆 cy.get() 的 scope 行为在 cy.within() 回调中使用 cy.get()，搜索范围会被限定。但一旦离开 within() 回调，cy.get() 又回到全局搜索。cy.get('.container').within(() => { cy.get('.item'); // 只在 .container 内搜索});cy.get('.item'); // 离开 within 后，又变成全局搜索坑4：忽视性能差异在几十个元素的小型页面上，cy.get() 和 cy.find() 性能差距可忽略。但当 DOM 节点达到上千个时（如长列表、复杂表格），cy.find() 的局部搜索明显更快。实际项目中，将一个有 2000+ DOM 节点的页面测试中的全局 cy.get() 替换为 cy.find()，单次测试执行时间可以从 800ms 降到 500ms 左右。如果测试套件运行时间超过 5 分钟，建议优先检查是否有可以替换为 cy.find() 的 cy.get() 调用。与其他定位方法的配合cy.contains() 结合 cy.find()cy.contains() 按文本内容查找元素，可以和 cy.find() 配合使用：// 在特定容器内按文本查找cy.get('.nav-menu').find('li').contains('Settings').click();.eq() 结合 cy.find()当需要选择第 N 个匹配元素时，用 .eq() 配合 cy.find()：// 选择商品列表中第二个商品的加入购物车按钮cy.get('.product-list').find('.add-to-cart').eq(1).click();cy.get() + .children() vs cy.find().children() 只查找直接子元素，cy.find() 查找所有后代：cy.get('.container').children('.item'); // 只找直接子元素cy.get('.container').find('.item'); // 找所有后代中的 .item根据 DOM 层级深度选择合适的方法：如果目标元素一定是直接子元素，.children() 语义更明确；如果层级不确定，cy.find() 更保险。选择决策记住一个简单规则：能用 cy.find() 就用 cy.find()，需要全局搜索时才用 cy.get()。元素在某个容器内 → cy.get(容器).find(元素)元素是页面级的 → cy.get(元素)需要在容器内连续操作多个元素 → cy.get(容器).within(() => { cy.get(...) })需要按文本内容查找 → cy.contains(文本) 或 cy.get(容器).contains(文本)这样写出的测试代码意图更清晰，也更不容易因为页面结构变化而误匹配。在实际项目中，养成良好的元素定位习惯，不仅减少测试用例的维护成本，也能让团队其他成员更快理解测试逻辑。

你在后端接了第三方 API，返回 200MB JSON。JSON.parse 一跑，进程 OOM 了。或者前端渲染一个 5 万条记录的报表，页面卡了 8 秒。JSON 是小数据时的瑞士军刀，数据一大就变性能杀手。这篇文章按「网络层 → 解析层 → 存储层 → 架构层」逐层拆解，每条策略都给出可运行的代码和适用场景。1. 流式解析：别把整个文件塞进内存传统 JSON.parse 要求完整字符串在内存中。一个 200MB 的 JSON 文件，V8 解析时字符串临时拷贝 + 对象图构建，峰值内存轻松到 1GB+。Node.js 方案：JSONStreamconst fs = require('fs');const JSONStream = require('JSONStream');// 逐条解析大数组，内存占用稳定在 ~50MBconst stream = fs.createReadStream('./large-data.json') .pipe(JSONStream.parse('users.*'));stream.on('data', (user) => { processUser(user);});stream.on('end', () => console.log('解析完成'));浏览器方案：ReadableStream + 增量解析async function* parseStream(response) { const reader = response.body.getReader(); const decoder = new TextDecoder(); let buffer = ''; while (true) { const { done, value } = await reader.read(); if (done) break; buffer += decoder.decode(value, { stream: true }); const lines = buffer.split('\n'); buffer = lines.pop(); for (const line of lines) { if (line.trim()) yield JSON.parse(line); // NDJSON 格式 } }}选型参考：数据是数组且每条记录独立处理 → 用流式解析。数据是全量关联的嵌套结构（如完整的树形图）→ 流式处理不适用，跳至第 3 节。2. 压缩传输：花 50ms 压缩，省 2 秒传输JSON 中键名、空格、引号大量重复，gzip 压缩率通常在 80-95%。服务端开启 gzip（Nginx）gzip on;gzip_types application/json;gzip_min_length 1024;gzip_comp_level 5;Brotli 比 gzip 再小 15-25%Nginx 开启 Brotli（需 ngx_brotli 模块），代价是服务端压缩更慢。静态 JSON 文件推荐 Brotli，动态 API 推荐 gzip。实测参考：一个 50MB 的 JSON 文件，gzip 压缩到约 5MB，传输时间从 ~4s 降到 ~0.5s（10Mbps 网络下）。3. 数据结构优化：少一层嵌套，解析快一倍JSON 嵌套越深，解析器需要回溯的次数越多。对比两种结构：// 差：5 层嵌套，每个用户解析时要创建 5 层对象const bad = { data: { users: [ { profile: { name: "张三", address: { city: "北京" } } } ] }};// 好：扁平化，只有 2 层const good = { users: [ { name: "张三", city: "北京" } ]};实战建议：字段名本身也占体积，用简短字段名（u 代 userName）能减少 10-30% 体积，适合内部 API移除不需要的字段：后端返回了 30 个字段，前端只用了 5 个 → 用 GraphQL 或 fields 参数做字段裁剪同类型集合用数组不用对象：[{id:1},{id:2}] 比 {"1":{...},"2":{...}} 解析更快4. 选对解析器：差距可能出乎意料| 解析器 | 耗时 | 说明 ||--------|------|------|| JSON.parse（原生） | ~35ms | V8 内置，大部分场景够用 || json-bigint | ~55ms | 支持大整数，需额外开销 || lossless-json | ~60ms | 保留数字精度 |绝大多数情况下用原生 JSON.parse 就够了。只有两种场景需要换解析器：JSON 中有超过 Number.MAX_SAFE_INTEGER 的整数（如雪花 ID）→ 用 json-bigint需要保留数字的原始格式（如 1.0 vs 1）→ 用 lossless-json5. 缓存策略：解析一次，用 N 次class JSONCache { constructor(ttlMs = 60000) { this.cache = new Map(); this.ttl = ttlMs; } get(key) { const entry = this.cache.get(key); if (!entry) return null; if (Date.now() - entry.timestamp > this.ttl) { this.cache.delete(key); return null; } return entry.data; } set(key, data) { this.cache.set(key, { data, timestamp: Date.now() }); }}const cache = new JSONCache(5 * 60 * 1000);let data = cache.get('hot-config');if (!data) { data = await fetch('/api/config').then(r => r.json()); cache.set('hot-config', data);}适用场景：配置数据、字典数据等低频变化、高频访问的 JSON；排行榜、热门列表等可容忍短暂不一致的数据。6. 增量更新：别每次都传全量一个 1000 条的列表，用户只改了其中 1 条，没必要把 1000 条全部重传。JSON Patch（RFC 6902）import { compare, applyPatch } from 'fast-json-patch';const original = { name: "张三", age: 30, city: "北京" };const updated = { name: "张三", age: 31, city: "上海" };// 生成 patch：只包含变更字段const patch = compare(original, updated);// [{ op: "replace", path: "/age", value: 31 },// { op: "replace", path: "/city", value: "上海" }]// 客户端只发送 2 个小操作，服务端直接 applyapplyPatch(original, patch);WebSocket 增量推送// 服务端：只推送变更ws.send(JSON.stringify({ type: 'delta', path: '/users/42/status', value: 'offline'}));// 客户端：深度合并import { set } from 'lodash';set(localState, 'users.42.status', 'offline');7. 服务端分段和分页不做分页，一次返回 100 万条等于自杀式操作。// 后端分页app.get('/api/users', async (req, res) => { const { page = 1, size = 100 } = req.query; const offset = (page - 1) * size; const [users, total] = await db.query( 'SELECT * FROM users LIMIT ? OFFSET ?', [Number(size), offset] ); res.json({ data: users, total, page, size });});// 前端游标翻页（适合实时数据，避免 offset 漂移）let cursor = null;async function loadMore() { const url = cursor ? `/api/events?after=${cursor}&limit=50` : '/api/events?limit=50'; const { data, nextCursor } = await fetch(url).then(r => r.json()); cursor = nextCursor; appendToUI(data);}| 方式 | 适用场景 | 注意事项 ||------|----------|----------|| LIMIT/OFFSET | 静态数据、管理后台 | 大 offset 时性能退化 || 游标分页（cursor） | 实时数据、无限滚动 | 实现稍复杂，需有序索引 || keyset 分页 | 时间线、feed 流 | 基于 WHERE id > lastId |8. 二进制格式替代：JSON 不是唯一选择当数据量大到 JSON 成为瓶颈，应该考虑二进制序列化格式。JSON vs Protobuf vs MessagePack 对比| 维度 | JSON | Protobuf | MessagePack ||------|------|----------|-------------|| 体积 | 基准 | 小 60-80% | 小 30-50% || 解析速度 | 基准 | 快 5-10x | 快 2-3x || 可读性 | 人类可读 | 需 .proto 文件 | 不可读 || 前后端改造成本 | 无 | 高（需定义 schema） | 低（JSON 零改造） |选型建议：内部微服务通信 → Protobuf，体积最小、速度最快前端兼容性优先 → MessagePack，和 JSON API 差不多，体积小一半对外开放 API → 保持 JSON，加 gzip 就够了// MessagePack 示例：几乎零改造成本const msgpack = require('@msgpack/msgpack');// 编码const encoded = msgpack.encode({ name: "张三", age: 30 });// encoded 是 Uint8Array，体积比 JSON 小 30-50%// 解码const decoded = msgpack.decode(encoded);9. Web Worker 并行解析：别让 JSON 卡住主线程前端解析大 JSON 时，主线程会完全阻塞，用户看到的就是页面冻结。Web Worker 把解析搬离主线程。// main.jsconst worker = new Worker('json-worker.js');worker.postMessage({ url: '/api/large-data' });worker.onmessage = (e) => { const data = e.data; renderUI(data); // 主线程只负责渲染};// json-worker.jsself.onmessage = async (e) => { const response = await fetch(e.data.url); const text = await response.text(); const data = JSON.parse(text); // Worker 线程解析，不阻塞 UI self.postMessage(data);};注意：postMessage 传递大数据时存在结构化克隆开销。可以用 Transferable Objects（ArrayBuffer）避免拷贝：// Worker 中用 MessagePack 编码后传输const encoded = msgpack.encode(data);self.postMessage(encoded, [encoded.buffer]); // 零拷贝传输10. IndexedDB 存储大型 JSON：别全放内存前端拿到大数据后，如果全存在 JavaScript 变量里，切换页面就丢了，放 localStorage 有 5MB 限制。IndexedDB 没有这个限制。// 存入 IndexedDBasync function saveToIndexedDB(storeName, data) { const db = await openDB('app-db', 1, { upgrade(db) { db.createObjectStore(storeName, { keyPath: 'id' }); } }); const tx = db.transaction(storeName, 'readwrite'); for (const item of data) { await tx.store.put(item); } await tx.done;}// 按需查询，不用全量加载const db = await openDB('app-db', 1);const user = await db.get('users', '42'); // 只取一条const allUsers = await db.getAll('users'); // 或全量适用场景：离线应用、仪表盘数据本地缓存、大量表单草稿自动保存。优化决策速查| 你的瓶颈是 | 优先策略 | 所在层级 ||-----------|---------|---------|| 内存溢出 / OOM | 流式解析（第1节） | 解析层 || 网络传输慢 | 压缩传输（第2节） | 网络层 || 解析本身 CPU 高 | 数据结构优化 + 解析器（第3、4节） | 解析层 || 重复请求相同数据 | 缓存（第5节） | 存储层 || 频繁小幅更新 | 增量更新（第6节） | 网络层 || 数据量太大一次返回 | 分页/分段（第7节） | 架构层 || JSON 体积本身就是瓶颈 | 二进制格式替代（第8节） | 架构层 || 前端主线程卡死 | Web Worker 并行解析（第9节） | 解析层 || 前端大数据持久化 | IndexedDB 存储（第10节） | 存储层 |总结大型 JSON 性能优化的本质是减少不必要的工作：不必要的数据不要传输（压缩、分页、增量更新、二进制格式），不必要的数据不要解析（流式、缓存、Web Worker），不必要的数据不要存内存（扁平化、字段裁剪、IndexedDB）。不必一次性全部优化——从当前项目最大的 JSON 响应入手，按决策速查表定位瓶颈，一次解决一个，效果最明显。面试高频追问Q: JSON 和 Protobuf 怎么选？JSON 人类可读、生态成熟、调试方便，适合对外 API 和小数据场景。Protobuf 体积小 60-80%、解析快 5-10 倍，但需要 schema 定义和代码生成工具链，适合内部微服务高频通信。选型的核心判断：数据量大 + 调用频次高 + 调用方可控 → Protobuf；否则 JSON + gzip 就够了。Q: 流式解析和全量解析的核心区别是什么？全量解析（JSON.parse）先把整个字符串读入内存，再构建完整对象树，内存峰值是数据的 3-10 倍。流式解析（SAX 模式）逐 token 读取，每遇到一个完整元素就回调处理，内存恒定。代价是流式解析只能顺序访问，无法回溯或随机访问某个字段。Q: 前端解析大 JSON 卡 UI 怎么办？三步走：第一步用 Web Worker 把 JSON.parse 移到后台线程；第二步用 Transferable Objects 避免数据从 Worker 传回主线程时的拷贝开销；第三步如果数据还需要分块渲染，配合虚拟滚动（如 react-virtualized）只渲染视口内的 DOM 节点。Q: gzip 和 Brotli 怎么选？动态 API 响应用 gzip，压缩快、延迟低。静态 JSON 文件用 Brotli，压缩率更高（再小 15-25%），可以离线预压缩不计较耗时。两者都只在网络传输环节有效——到达浏览器解压后体积不变，不影响内存占用。

面试官问："useCallback 和 useMemo 有什么区别？什么场景下使用？"——这道题几乎出现在每一场 React 岗位的面试中。答案其实不复杂，但很多人答完区别就卡在使用场景上，要么说"都用上总没错"，要么完全不知道什么时候该用。核心区别：一句话记住useCallback 缓存函数引用，useMemo 缓存计算结果。// 这两行等价const fn = useCallback(() => doSomething(a), [a]);const fn = useMemo(() => () => doSomething(a), [a]);useCallback(fn, deps) 本质上就是 useMemo(() => fn, deps) 的语法糖。记住这个等式，很多困惑会自动消散。| 特征 | useCallback | useMemo ||------|-------------|---------|| 返回值 | 函数本身 | 函数的执行结果 || 缓存对象 | 函数引用 | 任意值（对象、数组、基本类型） || 典型场景 | 传给子组件的回调 | 昂贵计算 / 保持引用稳定 || 一句话 | "别重新创建这个函数" | "别重新算这个值" |为什么需要它们：React 重渲染机制React 函数组件每次渲染都会重新执行整个函数体。你在组件里写的每一行代码——定义变量、创建函数、计算表达式——每次渲染都重新跑一遍：function MyComponent({ items }) { const handleClick = () => console.log("clicked"); // 每次渲染都创建新函数 const filtered = items.filter(item => item.active); // 每次渲染都重新过滤 return <Child onClick={handleClick} data={filtered} />;}如果 items 有 10000 条，而组件每秒渲染 60 次，你就在每秒过滤 60 万次。更麻烦的是，handleClick 每次都是新的引用——如果 Child 用了 React.memo，它期待的"不变引用"就白费了。useCallback 和 useMemo 的作用就是告诉 React："如果依赖没变，把上次的结果还给我。"useCallback：保持函数引用稳定配合 React.memo 阻止子组件无效渲染这是 useCallback 最核心的使用场景：function Parent({ items }) { // ❌ 每次渲染都创建新函数，Child 的 React.memo 白费了 const handleClick = () => { console.log("clicked"); }; // ✅ 函数引用稳定，Child 不会因它而重渲染 const handleClick = useCallback(() => { console.log("clicked"); }, []); return <Child onClick={handleClick} items={items} />;}const Child = React.memo(({ onClick, items }) => { console.log("Child render"); return <button onClick={onClick}>Click</button>;});关键点：useCallback 单独用效果有限，必须配合 React.memo 才能阻止子组件重渲染。如果子组件没有 React.memo 包裹，父组件渲染它就会渲染——useCallback 改变不了这一点。作为 useEffect 的稳定依赖function UserProfile({ userId }) { // ❌ fetchUser 每次都是新引用，useEffect 每次都会执行 const fetchUser = () => { api.getUser(userId); }; // ✅ 只在 userId 变化时重新创建 const fetchUser = useCallback(() => { api.getUser(userId); }, [userId]); useEffect(() => { fetchUser(); }, [fetchUser]);}不过这里有个陷阱：用 useCallback 缓存函数再放进 useEffect 依赖，实际上你是间接依赖了 callback 的真实依赖。对于上面的例子，直接在 useEffect 里写请求逻辑、直接依赖 userId 更直接。这个模式主要用在自定义 Hook 中，函数需要暴露给外部使用：function useUserData(userId) { const fetchUser = useCallback(() => { return api.getUser(userId); }, [userId]); return { fetchUser }; // 调用方拿到的引用是稳定的}自定义 Hook 中的 useCallback这是面试中容易忽略的场景。当你写一个自定义 Hook 返回方法时，如果不加 useCallback，消费方每次拿到的都是新函数，它的 useEffect 会被反复触发：function useTable(pagination) { const refresh = useCallback(() => { fetchData(pagination); }, [pagination]); const reset = useCallback(() => { setFilters({}); setPagination({ page: 1 }); }, []); return { refresh, reset }; // 消费方可以安全地放入依赖数组}useMemo：缓存计算结果避免重复的数组操作function ProductList({ products, filter }) { // ❌ 每次渲染都重新过滤 const filteredProducts = products.filter(p => p.name.includes(filter)); // ✅ 只在 products 或 filter 变化时重新计算 const filteredProducts = useMemo(() => products.filter(p => p.name.includes(filter)), [products, filter] ); return <ul>{filteredProducts.map(p => <li key={p.id}>{p.name}</li>)}</ul>;}复杂计算（排序、聚合、数据转换）function DataTable({ data }) { const sortedData = useMemo(() => { return [...data].sort((a, b) => a.score - b.score); }, [data]); const chartData = useMemo(() => { return data.reduce((acc, item) => { const key = item.category; if (!acc[key]) acc[key] = { total: 0, count: 0 }; acc[key].total += item.value; acc[key].count += 1; return acc; }, {}); }, [data]); return <Chart data={chartData} />;}保持对象和数组的引用稳定这个用法很容易被忽略，但在性能优化中很重要：function Parent({ items }) { // ❌ 每次渲染创建新对象，子组件 React.memo 失效 const style = { color: "red" }; const config = { threshold: 0.5, rootMargin: "0px" }; // ✅ 对象引用稳定 const style = useMemo(() => ({ color: "red" }), []); const config = useMemo(() => ({ threshold: 0.5, rootMargin: "0px" }), []); return <Child style={style} observerConfig={config} />;}useCallback 缓存函数，useMemo 缓存值——这是一个重要的互补关系。当你需要传一个稳定引用的对象或数组给子组件时，用 useMemo。useMemo 和 useRef 的区别面试中经常追加这个问题。两者都能"记住"上一次的值，但机制完全不同：| 特征 | useMemo | useRef ||------|---------|--------|| 触发重渲染 | 依赖变化时返回新值，组件正常重渲染 | 修改 .current 不触发重渲染 || 用途 | 缓存计算结果 | 持久化可变值（DOM 引用、前一次渲染的值等） || 依赖追踪 | 有依赖数组，自动更新 | 无依赖，手动管理 |// useMemo：依赖变了才重算，结果参与渲染const sorted = useMemo(() => data.sort(), [data]);// useRef：记住上一次的值，但不触发重渲染const prevCount = useRef(count);useEffect(() => { prevCount.current = count;}, [count]);如果你只是想跨渲染记住一个值但不影响渲染输出，用 useRef；如果你需要基于依赖缓存计算结果参与渲染，用 useMemo。组合使用：性能优化三层架构在一个复杂的列表组件中，三个 Hook 经常协同工作：function SearchResults({ query, data }) { // 第一层：缓存数据计算结果 const results = useMemo(() => { return data.filter(item => item.name.toLowerCase().includes(query.toLowerCase()) ); }, [data, query]); // 第二层：缓存事件处理函数 const handleItemClick = useCallback((id) => { console.log("Selected:", id); }, []); // 第三层：缓存传递给子组件的 props 对象 const listProps = useMemo(() => ({ items: results, onItemClick: handleItemClick }), [results, handleItemClick]); return <ResultList {...listProps} />;}这种"数据 → 函数 → props 对象"的三层缓存，是 React 性能优化的标准范式。但记住，这是在已经发现性能问题之后的优化手段，不是写代码时的默认操作。用 DevTools 验证优化效果说了这么多"什么时候该用"，那怎么判断你写的 useCallback / useMemo 真的有用？靠猜是不行的，用 React DevTools Profiler：打开 Chrome DevTools → Profiler 标签点击录制按钮，操作你的组件停止录制，查看火焰图找到不必要的重渲染（灰色条表示"没变但重渲染了"）针对性地加 useCallback / useMemo，再录一次对比如果你加了缓存但 Profiler 没有变化，说明这个缓存是多余的——移除它。优化从来不是越多越好。三个最常见的坑坑一：过度使用——简单运算不需要缓存// ❌ 两个数相加也要 useMemo？缓存的成本比计算还大const total = useMemo(() => a + b, [a, b]);// ❌ 简单的字符串拼接也要 useCallback？const label = useCallback(() => `${firstName} ${lastName}`, [firstName, lastName]);// ✅ 直接写const total = a + b;const label = `${firstName} ${lastName}`;经验法则：计算操作耗时 < 1ms 的，不需要 useMemo。只有循环遍历大数组、递归、复杂对象转换才值得。useCallback 同理——如果子组件没被 React.memo 包裹，你加不加 useCallback 效果一样。坑二：闭包陷阱——遗漏依赖// ❌ multiplier 在闭包里但不在依赖数组const multiplier = 2;const result = useMemo(() => value * multiplier, [value]);// ✅ 所有引用的外部变量都要声明const result = useMemo(() => value * multiplier, [value, multiplier]);务必开启 eslint-plugin-react-hooks 的 exhaustive-deps 规则，让 ESLint 帮你检查。闭包陷阱不是"偶尔遇到"的问题，是"迟早遇到"的问题。坑三：useCallback 配合了没 memo 的子组件// ❌ 子组件没有 React.memo，useCallback 基本白用function Parent() { const handleClick = useCallback(() => {}, []); return <PlainChild onClick={handleClick} />;}没有 React.memo 的子组件，父组件渲染它就会渲染——useCallback 改变不了这一点。这是一个非常常见的"写了等于没写"的场景。React 19 Compiler 会取代它们吗？React 19 引入了 React Compiler（实验性），可以自动为代码插入等效的 useMemo 和 useCallback。如果你的项目已经启用了 Compiler，手动写这些 Hook 的需求会大幅减少。但目前绝大多数项目（React 16-18）仍然需要手动优化。而且即使有了 Compiler，理解 useCallback 和 useMemo 的原理，能帮你在遇到性能问题时快速定位根因——Compiler 不是万能的，它也会犯错，这时候你需要知道底层的运作方式来判断是 Compiler 的 bug 还是你代码的问题。面试速答模板面试中被问到这道题，建议这样组织答案：区别：useCallback 缓存函数引用，useMemo 缓存计算结果。useCallback(fn, deps) 等价于 useMemo(() => fn, deps)，是它的语法糖。场景：useCallback 主要配合 React.memo 阻止子组件无效渲染，或作为自定义 Hook 的稳定返回值；useMemo 用于昂贵计算和保持对象/数组引用稳定。注意点：两者都不是"越多越好"。没有 React.memo 的子组件加 useCallback 无效；简单计算加 useMemo 反而更慢；务必开启 exhaustive-deps 规则避免闭包陷阱。追问准备：React 19 Compiler 可以自动处理大部分缓存需求，但理解原理对定位问题仍然必要。useRef 也能"记住"值但不触发重渲染，和 useMemo 的触发机制不同。总结| 你需要 | 用什么 | 关键搭档 ||--------|--------|----------|| 缓存函数给子组件 | useCallback | React.memo || 缓存计算结果 | useMemo | — || 缓存对象/数组引用 | useMemo | React.memo || 防止 useEffect 不必要触发 | useCallback / useMemo | 依赖数组 |记住三点：先写对，再优化。等 React DevTools Profiler 告诉你哪里慢了再动手，不要预先给所有东西加缓存useCallback 是 useMemo 的特例，缓存的是函数引用，不是计算结果没有 React.memo 的子组件，useCallback 基本是自我安慰

DNS 解析是每一次网络请求的第一步——用户输入网址到页面开始渲染，中间首先要过 DNS 这一关。这一步慢了，后面所有优化都是白搭。一次 DNS 查询通常耗时 20-120ms，看着不多，但如果你的页面要解析 10 个域名，光 DNS 就吃掉 200ms-1.2s，这还没算上 TCP 连接和内容下载。更要命的是，DNS 挂了，你的网站就彻底不可达——用户看到的就是"无法访问此网站"。所以 DNS 的性能和可靠性，是整个服务可用性的地基。先搞清楚 DNS 慢在哪里优化之前得知道瓶颈在哪。DNS 查询的延迟主要来自三个环节：本地缓存未命中。浏览器有 DNS 缓存，操作系统也有，但如果 TTL 过期或者用户第一次访问，缓存里就没有，必须走完整查询链路。递归查询链路长。一个域名可能经过 根域名服务器 → 顶级域名服务器(.com) → 权威域名服务器 三级跳，每一跳都有网络延迟。如果中间还有 CNAME 跳转（比如 CDN 域名），链路会更长。权威服务器响应慢。你的权威 DNS 服务器如果部署在单一地区，海外用户查询就要跨洋，延迟直接飙到几百毫秒。知道了瓶颈，接下来的优化就有的放矢了。TTL 设置：最容易调但最常调错TTL（Time To Live）决定了 DNS 记录在缓存中保留多久。设长了，变更生效慢；设短了，缓存命中率低，查询量暴增。实战建议：CDN 域名、静态资源域名：TTL 设 3600-86400 秒。这些几乎不变，长 TTL 大幅减少查询API 服务、动态服务：TTL 设 300-600 秒。需要快速切换 IP 时不会被旧缓存卡住准备做 DNS 变更前：提前 24 小时把 TTL 降到 300 秒，等变更完成后再改回来一个常见错误是所有记录都用同一个 TTL。实际上同一域名的不同记录应该根据变更频率分别设置。; CDN 域名 - 变更极少，TTL 给长cdn.example.com. 86400 IN CNAME cdn.provider.com.; API 服务 - 可能随时切换，TTL 给短api.example.com. 300 IN A 203.0.113.2DNS 缓存：减少重复查询的核心手段缓存分好几个层级，每一层都能拦截大量重复查询。浏览器 DNS 缓存。Chrome 默认缓存 1000 条记录，TTL 大约 60-120 秒。这个你控制不了，但可以通过合理的 TTL 间接影响。操作系统 DNS 缓存。Linux 上用 systemd-resolved 或 nscd 管理，可以调大缓存容量：# systemd-resolved 缓存配置[Resolve]Cache=yesCacheFromInsecure=yes递归 DNS 服务器缓存。这是你能控制的最重要的一层。BIND 的缓存配置：options { recursion yes; max-cache-size 1024m; # 根据服务器内存调整 cleaning-interval 60; # 每 60 分钟清理过期记录};关键是监控缓存命中率。如果命中率低于 80%，要么是 TTL 设太短，要么是查询域名太分散。用 rndc stats 看 BIND 的缓存统计：rndc statsgrep "Cache statistics" /var/named/data/named_stats.txt减少查询次数：前端也能帮上忙页面加载时，浏览器要为页面中引用的每个新域名做一次 DNS 查询。引用了 8 个不同域名的资源？那就是 8 次 DNS 查询，串行执行时就是灾难。dns-prefetch 是最简单的前端优化手段：<link rel="dns-prefetch" href="//cdn.example.com"><link rel="dns-prefetch" href="//api.example.com">浏览器会在空闲时提前解析这些域名，等真正要用的时候缓存已经命中了。但注意别滥用——只有页面确实会用到的域名才做预解析，否则白白消耗用户网络。更进一步的方案是减少域名数量本身。把静态资源集中在 1-2 个域名下，比做 10 个 dns-prefetch 更有效。CDN + CNAME：让解析就近完成把域名 CNAME 到 CDN 是最常见的 DNS 加速手段：www.example.com. 600 IN CNAME example.cdn-provider.com.CDN 的权威 DNS 通常部署了 Anycast，全球有几十个节点，用户的 DNS 查询会被路由到最近的节点响应，延迟从几百毫秒降到几十毫秒。选 CDN 的时候注意看它的 DNS 解析能力——有些 CDN 在亚太地区节点少，国内用户解析还是绕道海外，效果打折。高可用：DNS 挂了怎么办单点 DNS 是定时炸弹。一旦权威 DNS 不可达，所有依赖它的服务全部瘫痪，而且 TTL 没过期之前缓存还能撑一撑，TTL 一过期就彻底断联。主从架构至少部署两台权威 DNS 服务器，放在不同的物理位置（最好不同机房）：; 主服务器zone "example.com" { type master; file "/etc/bind/db.example.com"; allow-transfer { 192.0.2.10; }; also-notify { 192.0.2.10; };};; 从服务器zone "example.com" { type slave; file "/etc/bind/db.example.com.slave"; masters { 192.0.2.1; };};从服务器自动同步区域文件，主服务器挂了从服务器继续提供解析。关键是要确保 allow-transfer 只允许你的从服务器，防止区域传送泄露被利用。DNS 轮询负载均衡最简单的负载均衡——同一个域名配置多条 A 记录：www.example.com. 600 IN A 192.0.2.1www.example.com. 600 IN A 192.0.2.2www.example.com. 600 IN A 192.0.2.3递归服务器每次查询会拿到不同顺序的 IP 列表，客户端通常取第一个，从而达到分发效果。但 DNS 轮询有个硬伤：它不知道后端服务器健不健康。如果 192.0.2.2 挂了，DNS 轮询还是会把流量分给它。所以生产环境要用智能 DNS（如 Route 53、Cloudflare），配合健康检查自动摘除故障节点。Anycast：一个 IP 多个节点Anycast 让多个物理服务器共享同一个 IP，BGP 路由自动把请求导向最近的节点。这是大型 DNS 服务（8.8.8.8、1.1.1.1）的标准做法。好处是：自动负载均衡、自动故障转移、就近响应降低延迟。缺点是配置复杂，需要 BGP 支持，小团队通常直接用云厂商的 Anycast DNS 服务。故障切换脚本对于小规模部署，写个简单脚本监控主 DNS 并自动切换：#!/bin/bashPRIMARY="192.0.2.1"BACKUP="192.0.2.2"DOMAIN="example.com"if ! dig @$PRIMARY $DOMAIN +short > /dev/null 2>&1; then echo "Primary DNS down, switching to backup" echo "nameserver $BACKUP" > /etc/resolv.conf # 发告警通知 curl -s "https://hooks.example.com/alert?msg=DNS+failover+triggered"fi这只是应急手段。真正的生产环境应该用 keepalived 或云厂商的 DNS 故障切换功能，自动检测、自动切换、自动回切。安全：DNS 是最容易被忽视的攻击面DNS 劫持和 DNS 放大攻击是两种最常见的 DNS 安全威胁。DNSSEC 防篡改DNSSEC 给 DNS 响应加上数字签名，客户端可以验证响应是否被篡改。启用 DNSSEC 验证：options { dnssec-validation auto;};部署 DNSSEC 的主要工作量在密钥管理——KSK（密钥签名密钥）和 ZSK（区域签名密钥）需要定期轮换，操作失误会导致域名解析全部失败。建议用自动化工具管理密钥轮换，不要手动操作。DoH/DoT 加密查询传统 DNS 查询是明文的，ISP 或中间人可以看到你查询了什么域名。DoT（DNS over TLS，端口 853）和 DoH（DNS over HTTPS，端口 443）加密了查询过程。# 配置 DoT（systemd-resolved）[Resolve]DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.googleDNSOverTLS=opportunistic对于企业内部，推荐所有客户端统一使用 DoH/DoT 连接内部递归 DNS，防止内网 DNS 查询被窃听。限制递归查询开放递归的 DNS 服务器会被利用做 DNS 放大攻击——攻击者伪造源 IP 发送查询，你的服务器把大量响应发到受害者 IP。一定要限制递归查询只服务可信客户端：acl trusted { 192.0.2.0/24; 10.0.0.0/8;};options { allow-recursion { trusted; }; recursion-clients 1000;};监控：优化效果得靠数据说话做了一堆优化，怎么验证效果？必须建立监控体系。响应时间：用 dig 简单测量，或者用专业工具持续采集：# 简单测量单次查询延迟dig @8.8.8.8 example.com | grep "Query time"缓存命中率：BIND 用 rndc stats 查看，目标 80% 以上。可用性：从多个地域持续探测 DNS 是否可达。Cloudflare 的 1.1.1.1 之所以快，不是因为它运算更快，而是因为全球 200+ 节点保证就近响应。关键指标看板：P50/P95/P99 查询延迟缓存命中率查询失败率递归查询占比（越低越好，说明缓存有效）优化 DNS 没有银弹，它是一个从客户端到服务端、从前端到基础设施的系统工程。先找到瓶颈在哪，再针对性优化——TTL 调优和缓存是最快见效的，Anycast 和智能 DNS 是长期投入但收益最大的，安全加固是容易被忽略但出事就致命的。

iframe 用得最多的就两件事：嵌入第三方内容（视频、地图、广告），和隔离不信任的代码。剩下的场景要么是锦上添花，要么是被逼无奈。嵌入第三方内容，这个没得选。YouTube 给你 iframe 嵌入代码，Google Maps 给你 iframe 嵌入代码——你不会去重新实现一个视频播放器或地图引擎。唯一能做的是优化加载：loading="lazy" 懒加载，title 属性做无障碍，别让 iframe 阻塞首屏渲染。实测一个 YouTube iframe 能增加 200-500KB 的首屏加载量，不懒加载就是在拖慢页面。隔离不可信代码是 iframe 的核心价值。广告、用户提交的 HTML、第三方登录——这些代码你不能让它们直接跑在你的页面上下文里。CSS 样式污染、JS 全局变量覆盖，出过事的团队太多了。iframe + sandbox + postMessage 是目前浏览器原生能提供的最可靠的隔离方案。微前端里 iframe 是兜底方案，不是首选。qiankun、Module Federation 能搞定 90% 的场景，只有子应用技术栈完全不兼容、或者安全隔离要求极高时才上 iframe。代价很实际：路由同步要手写桥接、position: fixed 弹窗相对于 iframe 视口而非主页面、每个 iframe 都是独立浏览器上下文吃内存。一个页面 3 个以上 iframe，低端设备就能感知到卡顿。什么时候不该用 iframe：需要 SEO 收录的内容（搜索引擎基本不索引 iframe 内容）、需要频繁通信的组件（postMessage 序列化有性能开销）、移动端复杂交互（触摸事件跨 iframe 传递有问题）。能用 Web Component 或动态 import 解决的，别上 iframe。追问iframe 和 Web Component 有什么区别？| | iframe | Web Component ||---|---|---|| 隔离级别 | 完全隔离（独立文档） | Shadow DOM 样式隔离 || 通信方式 | postMessage | 属性/事件 || 性能开销 | 高（独立上下文） | 低（同一文档） || SEO 可见 | 不可见 | 可见 || 适用场景 | 跨域嵌入 | 组件封装 |一句话：跨域或强隔离用 iframe，同页面组件封装用 Web Component。sandbox 属性有哪些常见的安全陷阱？sandbox 默认禁止一切，你需要显式开放权限。最常见的陷阱是同时开 allow-scripts 和 allow-same-origin——这等于没隔离，脚本可以 frameElement.removeAttribute('sandbox') 直接移除限制。安全的做法是只开 allow-scripts 不开 allow-same-origin。另一个容易被忽略的是 allow-popups，如果不限制，iframe 内的链接可以弹出新窗口执行钓鱼攻击。postMessage 通信出过什么安全问题？必须校验 event.origin，targetOrigin 绝对不要写 *。真实事故案例：某 SaaS 产品的第三方插件通过 postMessage 向父页面发送伪造的用户操作数据，因为接收端只校验了 event.data.type 没校验 event.origin，导致用户权限被越权提升。微前端里用 iframe 的实际痛点是什么？路由同步是老大难——浏览器前进后退、URL hash 变化都要手动桥接，稍有不慎就不同步。弹窗定位是另一个坑，position: fixed 在 iframe 里是相对于 iframe 视口，不是主页面，导致弹窗遮挡位置完全错乱。还有 cookie 和 localStorage 的隔离问题，子应用登录态拿不到，得通过 postMessage 中转 token。移动端 iframe 有什么坑？iOS Safari 对 iframe 的滚动行为处理和其他浏览器不同，经常出现双滚动条或滚动穿透。触摸事件无法从主页面传递到 iframe 内部，意味着你自己写的滑动手势在 iframe 区域会失效。大部分团队最终选择移动端不用 iframe，改用原生组件或 WebView 方案。写段代码<iframe src="https://example.com/widget" sandbox="allow-scripts" loading="lazy" title="第三方组件"></iframe><script>window.addEventListener('message', (e) => { if (e.origin !== 'https://example.com') return; if (e.data.type === 'ready') { e.source.postMessage({ type: 'init', userId: 123 }, e.origin); }});</script>

NFT 这个词你一定听过——有人花几千万买一张 JPEG，有人靠它月入百万，也有人觉得这就是场骗局。但 NFT 本身既不是骗局也不是暴富工具，它只是一种技术：在区块链上证明"这个东西归你"。NFT 和比特币有什么本质区别？比特币是同质化代币（Fungible Token），你手里 1 个 BTC 和别人手里 1 个 BTC 没有任何区别，可以互换。NFT 则是非同质化代币（Non-Fungible Token），每一个都独一无二，不可互换。打个比方：人民币是同质化的，你兜里的 100 块和我兜里的 100 块完全等价；但蒙娜丽莎只有一幅，即使有人画了一模一样的复制品，原作的价值也无法被替代。NFT 就是区块链上的"蒙娜丽莎"——每个 NFT 都有唯一的 ID 和元数据，谁拥有它、何时转手、谁创造的，全在链上可查。| 特性 | 同质化代币（FT） | 非同质化代币（NFT） ||------|----------------|-------------------|| 可互换 | 可以，1 BTC = 1 BTC | 不可以，每个都不同 || 代表资产 | 货币、积分 | 艺术品、游戏道具、身份凭证 || 典型标准 | ERC-20 | ERC-721、ERC-1155 |两种核心标准：ERC-721 和 ERC-1155ERC-721：一个代币一个身份证ERC-721 是最早的 NFT 标准，也是目前用得最多的。它的逻辑很简单：每个 tokenId 对应一个唯一的 owner，就像每套房子的房产证只能写一个人的名字。核心操作就四个：查余额、查归属、转账、授权。你在 OpenSea 上看到的绝大多数数字艺术品，背后跑的都是 ERC-721。ERC-1155：一个合约管多种资产ERC-1155 是后来者，解决了一个实际问题——游戏里需要同时管理金币（FT）和装备（NFT），如果每种资产都部署一个合约，Gas 费吃不消。ERC-1155 允许一个合约同时管理同质化和非同质化代币，还支持批量转账，省 Gas。举个例子：一个游戏要发 1000 把同样的剑和 1 把独一无二的传说之剑。用 ERC-721 需要两个合约，用 ERC-1155 一个合约就搞定。| 标准 | 代币类型 | Gas 效率 | 适合场景 ||------|---------|---------|---------|| ERC-20 | 同质化 | 高 | 货币、积分 || ERC-721 | 非同质化 | 中 | 艺术品、域名 || ERC-1155 | 混合 | 高 | 游戏、批量发行 |元数据：NFT 的"灵魂"存放在哪？NFT 本体（所有权记录）在链上，但 NFT 的"外观"——图片、名称、属性描述这些元数据，通常不在链上。为什么？因为链上存储太贵了。一张图片 Base64 编码后可能有几百 KB，写入以太坊的 Gas 费可能比 NFT 本身还贵。所以元数据存储有三种方案：中心化服务器：合约里存一个 URL，指向 AWS 或阿里云上的 JSON 文件。问题很明显——服务器关了，你的 NFT 就变成了一个指向 404 的空壳。2022 年就有项目方跑路后 NFT 持有者发现自己的图片全变成了破图。IPFS（推荐）：文件上传到 IPFS 后生成一个内容哈希（CID），合约里存这个哈希。文件内容变了，哈希就变了，所以没人能偷偷替换你的图片。OpenSea 和大多数主流平台都用 IPFS。缺点是 IPFS 节点如果不 pin 你的文件，数据可能丢失，所以通常配合 Pinata 这样的 pinning 服务使用。Arweave：一次性付费，永久存储。比 IPFS 更省心，但费用更高。适合高价值 NFT。元数据的 JSON 格式大致长这样：{ "name": "CryptoPunk #1234", "description": "A unique CryptoPunk character", "image": "ipfs://QmXxx.../image.png", "attributes": [ { "trait_type": "Type", "value": "Female" }, { "trait_type": "Hair", "value": "Mohawk" } ]}attributes 字段是 NFT 的"稀有度"来源——一个 NFT 有多少种属性、每种属性的稀有程度，直接决定了它的市场价值。铸造一个 NFT 分几步？准备元数据：创作图片或 3D 模型，写好 JSON 描述文件上传到 IPFS：获得内容哈希调用合约的 mint 函数：传入接收地址和 tokenURI链上记录：tokenId 自增、映射 owner、存储 tokenURI触发 Transfer 事件：区块链浏览器可查询整个过程的核心就一件事：把"这件数字资产属于你"这个事实写进区块链，且不可篡改。NFT 在元宇宙里怎么用？元宇宙是 NFT 最自然的应用场景——虚拟世界里的所有"东西"都需要确权，而 NFT 天然解决"谁拥有什么"的问题。数字身份：你的钱包地址就是你在元宇宙的身份证，Avatar NFT 是你的外观，徽章 NFT 证明你的资历，成就 NFT 记录你的经历。别人看到你的钱包，就知道你是谁、做过什么。虚拟地产：Decentraland 和 The Sandbox 把虚拟土地做成 NFT，每块地有唯一坐标。2021 年一块 Decentraland 地皮卖到 240 万美元，后来跌了 90% 以上——虚拟地产的炒作泡沫和现实地产一样危险。游戏资产：传统游戏里你花钱买的皮肤归游戏公司所有，关服就没了。NFT 游戏里你的装备是真正的链上资产，游戏关了你还能卖掉。但要注意，大多数 NFT 游戏的经济模型不可持续，2022 年 Axie Infinity 的崩盘就是前车之鉴。社区治理：很多 DAO 用 NFT 作为会员凭证和治理投票权。持有不同等级的 NFT 享有不同的权限，从普通会员到治理委员会，层层递进。市场机制：版税和交易NFT 交易主要有三种模式：挂单定价（卖家标价买家直接买）、拍卖（英式或荷兰式）、聚合器比价（跨平台找最低价）。版税机制是 NFT 对创作者最重要的创新——通过智能合约，每次 NFT 转手时创作者都能自动获得一定比例的分成，通常是 2.5% 到 10%。这意味着艺术家不需要画廊或中间商，也能从作品的后续交易中持续获益。不过现实中，一些平台（如 Blur）为了争夺市场份额降低了版税执行力度，创作者权益保护仍是行业争议话题。NFT 正在往哪走？2021 年的 NFT 狂热已经过去，但技术本身在变得更实用：动态 NFT：元数据可以随外部条件变化，比如根据天气改变外观的 NFT 天气卡灵魂绑定代币（SBT）：不可转让的 NFT，用于学历证书、信用评分等身份凭证，Vitalik 是这个概念的主要推动者碎片化 NFT：把一个昂贵的 NFT 拆成很多份降低参与门槛，类似股票拆分RWA 代币化：把房产、债券等真实世界资产映射为 NFT，这是目前机构资金最关注的方向NFT 的叙事已经从"花几百万买猴子图片"转向了实用场景。市场不会消失，但泡沫会——活下来的会是那些真正解决确权问题的应用。

GORM 的钩子本质上是一组回调接口——只要你的 Model 实现了 BeforeCreate(tx *gorm.DB) error 这样的方法，GORM 就会在对应操作前后自动调用它。底层实现基于 GORM 的 callback 机制：每种操作（Create/Update/Delete/Query）维护一个有序的回调链，钩子函数被注册在链的特定位置，执行时按序逐个调用，任何一个返回 error 就中断并回滚事务。关键执行顺序：Create：BeforeSave → BeforeCreate → INSERT → AfterCreate → AfterSaveUpdate：BeforeSave → BeforeUpdate → UPDATE → AfterUpdate → AfterSaveDelete：BeforeDelete → DELETE → AfterDeleteQuery：AfterFind（查几条触发几次）注意 BeforeSave/AfterSave 是 Create 和 Update 共享的，这也是踩坑高发区。追问BeforeSave 里调用 tx.Save(u) 会怎样？无限循环。BeforeSave → Save → 又触发 BeforeSave → 又 Save ……解决方案是用 tx.Session(&gorm.Session{SkipHooks: true}) 跳过钩子后再操作。同理，AfterCreate 里调 tx.Create 也会循环。Save 方法为什么会触发两次 BeforeSave？这是 GORM 的已知行为（issue #3971）。当主键非空但数据库中无此记录时，Save 内部先尝试 Create 再 Update，BeforeSave 被调用两次。如果你在 BeforeSave 里做累加操作（u.Age += 1），结果会多加一次。解法是改用 Create 或 Update 明确指定操作类型，别用语义模糊的 Save。钩子里怎么拿到当前事务？钩子函数签名 func (u *User) BeforeCreate(tx *gorm.DB) error 中的 tx 就是当前事务。用 tx 而不是全局 db，这样钩子中的操作和主操作在同一个事务里，任何一步失败都会回滚。典型场景——AfterCreate 中创建关联记录：func (u *User) AfterCreate(tx *gorm.DB) error { return tx.Create(&Profile{UserID: u.ID}).Error}批量操作时钩子表现如何？Create 传入切片时，钩子对每条记录逐一执行，数据量大时性能开销显著。用 db.Session(&gorm.Session{SkipHooks: true}).CreateInBatches(...) 跳过钩子批量插入。另外，Create from map 方式（db.Model(&User{}).Create(map[string]interface{}{...})）本身就不触发钩子，因为 map 没有方法可调用。怎么自定义回调顺序或替换默认钩子？GORM 的 callback 链支持 Before("gorm:create")、After("gorm:create")、Replace("gorm:before_create", fn) 等操作。比如在 Create 之前插入自定义逻辑：db.Callback().Create().Before("gorm:create").Register("my:before_create", func(db *gorm.DB) { // 自定义逻辑})注册名必须唯一，后注册的同名回调会覆盖前者。写段代码密码加密 + 软删除保护的实际用法：func (u *User) BeforeSave(tx *gorm.DB) error { if u.Password != "" { u.Password = bcrypt.Hash(u.Password) } return nil}func (u *User) BeforeDelete(tx *gorm.DB) error { if !tx.Statement.Unscoped { return errors.New("请使用软删除") } return nil}

Binder 是 Android 进程间通信的核心机制，系统四大组件的跨进程调用全靠它。Android 不用 Linux 原生的管道、Socket 或共享内存，核心原因三个：只拷贝一次、内核级安全校验、自带服务发现。管道和 Socket 至少两次数据拷贝（用户态→内核态→用户态），Binder 通过 mmap 只拷贝一次。共享内存虽然零拷贝，但进程间没有任何身份验证机制，任何进程都能读写，Android 不敢用。Binder 每次通信都由内核自动附加调用方的 UID/PID，身份无法伪造，这是它最核心的安全优势。再加上 ServiceManager 充当"服务目录"，Client 不需要硬编码 Server 地址，查一下就行。Binder 驱动运行在内核态，暴露 /dev/binder 设备节点。通信流程：Server 向 ServiceManager 注册服务 → Client 查询 ServiceManager 拿到 Binder 代理对象 → Client 通过代理调方法 → Binder 驱动负责数据搬移和线程调度。ServiceManager 本身也是个 Binder 服务，handle 固定为 0。mmap 的具体过程：binderopen 时调用 mmap，在接收方进程的用户空间和内核空间之间建立一块共享映射区（上限 4MB）。发送方通过 copyfrom_user 把数据拷进这块内核映射区，接收方已经映射了同一块物理内存，直接读取——这就是"一次拷贝"的来由。发送方不做映射，因为一次通信只有接收端需要零拷贝读取。追问Binder 线程池默认多大？满了怎么办？默认最大 16 个线程（主线程 + 15 个工作线程）。客户端发起同步 Binder 调用，驱动在服务端线程池取线程执行。16 个都忙，新请求排队。所以主线程上不要做耗时 Binder 调用，否则 ANR——这不是建议，是血泪教训。Binder 通信数据大小限制是多少？异步（oneway）事务约 64KB，同步事务整个缓冲区约 1MB（不同 Android 版本略有差异）。Intent 底层走 Binder 传输，塞大数据会炸 TransactionTooLargeException。传大文件走 ContentProvider 或 SharedMemory，别往 Intent 里硬塞。oneway 和同步调用有什么区别？oneway 是 AIDL 方法修饰符，客户端调用后不阻塞，直接往下走，底层走异步事务。但注意：同一个 Binder 对象的 oneway 调用串行执行，不是并发。踩坑点——oneway 方法里抛异常，客户端完全无感知，线上排查这种问题特别痛苦。为什么发送方不做 mmap 映射？因为一次通信中，数据流是单向的：发送方只需要"写"，接收方只需要"读"。给接收方做映射就能省掉第二次拷贝，给发送方做映射没有收益，还浪费内存。如果双向都需要高效传输，那就建立两个 Binder 通道，各自映射各自的。写段代码// AIDL 定义interface IBookManager { List<Book> getBookList(); void addBook(in Book book); oneway void notifyChange(); // 异步，不阻塞调用方}

iframe 是前端面试中经常被忽视但一问就露馅的知识点——面试官不是考你知不知道 iframe 怎么用，而是看你能不能说清楚它为什么慢、慢在哪、怎么治。iframe 的性能开销来自五个方面。一是独立的文档加载：每个 iframe 都会创建完整的文档环境，触发 HTML 解析、CSS 计算、JS 编译全流程，相当于在页面里再嵌一个页面。二是阻塞 onload 事件：iframe 内所有资源加载完毕之前，主页面的 onload 不触发，直接影响 LCP 等核心指标。三是连接池竞争：浏览器对同一域名的并发连接数有限（HTTP/1.1 下通常 6 个），iframe 和主页面共享配额，iframe 的请求会挤占主页面的资源加载通道。四是重复资源加载：iframe 和主页面如果引用了相同的 CSS/JS 库，浏览器不会共享，各自加载一份，浪费带宽。五是内存占用：每个 iframe 拥有独立的 JS 执行上下文和渲染层，Chrome 中一个空白 iframe 约占 5-10MB 内存，嵌套越多开销越大。追问loading="lazy" 和 JS 延迟设置 src 有什么区别？loading="lazy" 是浏览器原生方案，Chrome 76+、Firefox 75+ 支持，基于视口距离自动触发。JS 延迟设置 src（配合 IntersectionObserver 或 setTimeout）是兼容方案，能在老浏览器上工作，但需要自己处理触发时机。实际项目推荐优先用原生属性，不支持的浏览器降级到 JS 方案。iframe 会影响 Core Web Vitals 吗？具体影响哪些指标？会，而且影响范围不小。LCP——iframe 阻塞 onload 延迟 LCP 产出；CLS——iframe 加载后尺寸变化导致布局偏移，没预设 width/height 时最严重；INP——iframe 内 JS 执行占用主线程，拖慢交互响应。给 iframe 设固定尺寸 + 懒加载是最有效的缓解手段。实际项目里 iframe 有什么坑？两个常见的：一是第三方 iframe 内部 JS 报错会通过 window.onerror 冒泡到父页面，干扰错误监控——解法是在监听 message 事件时做 origin 白名单校验，配合 sandbox 限制权限。二是跨域 iframe 无法读取内部 DOM，通信只能走 postMessage，一定要验证 event.origin 防止伪造消息。有替代 iframe 的方案吗？看场景。嵌入第三方内容（支付、广告）iframe 仍是首选，沙箱隔离是刚需。嵌入自有内容优先用 Web Components（Shadow DOM）——样式隔离、不影响主文档 onload、共享连接池。纯展示内容可以 AJAX 拉取后 innerHTML 渲染，但要防 XSS。sandbox 属性怎么用？sandbox 默认施加最严格限制，再通过属性值逐项放开：allow-scripts 允许 JS、allow-same-origin 允许同源访问、allow-forms 允许表单、allow-popups 允许弹窗。空 <iframe sandbox> 等于禁止一切。原则是只开放最小权限集。写段代码<iframe src="https://third-party.com/widget" loading="lazy" sandbox="allow-scripts allow-same-origin" width="800" height="500" title="第三方组件"></iframe>// postMessage 安全通信iframe.contentWindow.postMessage({ type: 'init' }, 'https://third-party.com');window.addEventListener('message', (e) => { if (e.origin !== 'https://third-party.com') return; // 处理消息});

Mat 的基本概念Mat（Matrix）是 OpenCV.js 中存储图像和矩阵数据的核心结构。底层是一个 n 维数组，支持单通道或多通道数据，常见类型包括：| 类型常量 | 含义 | 典型场景 ||---------|------|---------|| cv.CV_8UC1 | 8位无符号单通道 | 灰度图 || cv.CV_8UC3 | 8位无符号三通道 | RGB 图 || cv.CV_8UC4 | 8位无符号四通道 | RGBA 图 || cv.CV_32FC1 | 32位浮点单通道 | 计算中间结果 |用 mat.type() 可以在调试时确认当前 Mat 的数据类型——OpenCV.js 中大量报错都源于类型不匹配。创建 Mat 的六种方式1. 空矩阵与指定尺寸矩阵let empty = new cv.Mat(); // 空 Matlet black = new cv.Mat(480, 640, cv.CV_8UC3); // 640x480 黑色 RGB 图2. 带初始值的矩阵let blue = new cv.Mat(480, 640, cv.CV_8UC3, new cv.Scalar(255, 0, 0));cv.Scalar 按通道顺序赋值，三通道时依次为 B、G、R（OpenCV 默认 BGR 排列）。3. 特殊矩阵let zeros = cv.Mat.zeros(3, 3, cv.CV_8UC1); // 全零let ones = cv.Mat.ones(3, 3, cv.CV_8UC1); // 全一let eye = cv.Mat.eye(3, 3, cv.CV_32FC1); // 单位矩阵4. 从 JavaScript 数组创建let mat = cv.matFromArray(2, 2, cv.CV_8UC1, [1, 2, 3, 4]);matFromArray 适合将已有数值数据灌入 Mat，在做矩阵运算或构造卷积核时常用。5. 从 ImageData 创建let imgData = ctx.getImageData(0, 0, canvas.width, canvas.height);let mat = cv.matFromImageData(imgData);这种方式可以从任意 Canvas 2D 上下文直接拿到像素数据。6. 从 HTML 图像元素创建let img = document.getElementById('image');img.onload = function() { let mat = cv.imread(img); // 处理 mat... mat.delete();};cv.imread 同时支持 <img> 和 <canvas> 元素。注意图像加载是异步的，必须在 onload 回调里操作 Mat。像素读写与通道操作读取像素值// 单通道灰度图let val = mat.ucharAt(row, col);// 三通道 RGB 图，需逐通道读取let r = mat.ucharAt(row, col * 3);let g = mat.ucharAt(row, col * 3 + 1);let b = mat.ucharAt(row, col * 3 + 2);ucharAt 只适用于 8 位无符号类型。32 位浮点数据用 mat.floatAt(row, col) 读取。获取原始数据指针let data = mat.data; // Uint8Array 视图直接操作 mat.data 在大批量像素遍历时性能远优于逐像素调用 ucharAt。复制 Mat：clone 与 copyTo// 深拷贝，生成完全独立的副本let copy = mat.clone();// 带掩码复制，只复制掩码非零区域let mask = cv.Mat.zeros(mat.rows, mat.cols, cv.CV_8UC1);mat.copyTo(dst, mask);clone() 总是完整深拷贝；copyTo() 支持掩码参数，适合选择性复制。感兴趣区域（ROI）let roi = mat.roi(new cv.Rect(x, y, width, height));ROI 与原始 Mat 共享底层数据，修改 ROI 会同步影响原图。如需独立副本，调用 roi.clone()。类型转换let floatMat = new cv.Mat();mat.convertTo(floatMat, cv.CV_32FC1);在做除法或需要小数精度的运算前，通常需要将 8 位整数 Mat 转为 32 位浮点型。颜色空间转换let gray = new cv.Mat();cv.cvtColor(mat, gray, cv.COLOR_RGBA2GRAY);内存管理：必须手动 deleteOpenCV.js 通过 Emscripten 编译为 WebAssembly，Mat 的内存分配在 WASM 堆上，不受 JavaScript 垃圾回收器管理。不再使用的 Mat 必须手动调用 delete() 释放，否则会造成内存泄漏。推荐的 try-finally 模式let mat = new cv.Mat(100, 100, cv.CV_8UC3);let dst = new cv.Mat();try { cv.cvtColor(mat, dst, cv.COLOR_BGR2GRAY); // 使用 dst 做后续处理...} finally { mat.delete(); dst.delete();}封装辅助函数减少遗漏function withMat(fn) { let mats = []; let wrap = (m) => { mats.push(m); return m; }; try { return fn(wrap); } finally { mats.forEach(m => m.delete()); }}// 使用示例withMat(wrap => { let src = wrap(cv.imread(canvas)); let gray = wrap(new cv.Mat()); cv.cvtColor(src, gray, cv.COLOR_RGBA2GRAY); cv.imshow('output', gray);});常见内存错误| 错误 | 表现 | 修正 ||------|------|------|| 忘记 delete() | 页面长时间运行后卡顿或崩溃 | try-finally 保证释放 || 重复 delete() | 抛出运行时异常 | delete 后将变量置为 null || ROI 未 delete | 原图数据被释放但 ROI 头未释放 | ROI 也是 Mat，必须单独 delete || 返回局部 Mat | 函数返回后 Mat 已 delete，调用方拿到空引用 | 返回 clone() 副本而非引用 |面试追问Q: OpenCV.js 的 Mat 和原生 OpenCV 的 cv::Mat 有什么区别？底层数据结构一致，但 OpenCV.js 的 Mat 通过 Emscripten 暴露给 JavaScript，没有引用计数机制，必须手动 delete()；而原生 C++ 的 Mat 析构时自动递减引用计数，计数归零才释放数据。Q: 为什么 mat.ucharAt 读取三通道图像时要乘以 3？因为 ucharAt(row, col) 按像素索引访问，而三通道图像在内存中每个像素占 3 字节连续存储，所以列号需要乘以通道数再偏移到对应通道。Q: ROI 修改后原图为什么也变了？如何避免？ROI 和原图共享同一块底层数据缓冲区，只是起止位置不同。需要独立副本时调用 roi.clone() 做深拷贝。

在 Solidity 中，storage、memory 和 calldata 是三种数据位置修饰符，决定数据的存储方式、生命周期和 Gas 开销。核心区别：storage 永久存链上，memory 是临时可变内存，calldata 是临时只读调用数据。直接回答| 数据位置 | 持久性 | 可修改 | Gas 成本 | 默认适用 ||---------|--------|--------|---------|---------|| storage | 永久（链上） | 可读写 | 最高 | 状态变量 || memory | 临时（函数内） | 可读写 | 中等 | 函数参数、局部引用类型 || calldata | 临时（函数内） | 只读 | 最低 | external 函数的引用类型参数 |面试一句话总结：storage 是链上持久存储，读写最贵；memory 是临时内存，函数结束即释放；calldata 是只读的调用输入，external 函数参数强制使用，Gas 最省。追问一：赋值时是拷贝还是引用？这是面试最容易踩坑的点：storage → memory：深拷贝，修改 memory 变量不影响原 storagememory → memory：引用传递（引用类型如数组、结构体），修改会互相影响storage → storage：引用传递，指向同一块链上存储memory → storage：深拷贝，写入独立的 storage slotcontract AssignDemo { uint256[] public arr = [1, 2, 3]; function storageToMemory() external view returns (uint256) { uint256[] memory mArr = arr; // 深拷贝 mArr[0] = 99; // 不影响 arr return arr[0]; // 返回 1 } function memoryToMemory() external pure returns (uint256) { uint256[] memory a = new uint256[](3); a[0] = 10; uint256[] memory b = a; // 引用，非拷贝 b[0] = 20; return a[0]; // 返回 20，a 和 b 指向同一内存 }}追问二：默认数据位置规则Solidity 对数据位置有强制约束，不是随便选的：状态变量：强制 storage函数参数（external）：强制 calldata（返回参数除外）函数参数（public/internal）：默认 memory，可显式指定 calldata局部变量：值类型在栈上，引用类型默认 storage 指针指向状态变量mapping 和动态数组：只能存在于 storage，不能声明为 memory 局部变量contract LocationRules { mapping(address => uint256) public balances; // 强制 storage // external 参数强制 calldata function externalFn(uint256[] calldata data) external pure returns (uint256) { return data[0]; } // public 参数默认 memory，也可显式用 calldata 省 Gas function publicFn(uint256[] calldata data) public pure returns (uint256) { return data[0]; } function badLocalMapping() internal pure { // mapping(address => uint256) localMap; // 编译错误！mapping 不能在 memory }}追问三：为什么 calldata 比 memory 省 Gas？calldata 直接读取交易输入的原始 calldata 编码，不需要将数据拷贝到内存。memory 参数则需要 EVM 执行一次从 calldata 到内存的复制操作，对于大型数组或结构体，这个拷贝开销显著。所以当函数参数不需要修改时，用 calldata 替代 memory 是最常见的 Gas 优化手段之一。追问四：storage 指针是什么？在函数内声明一个 storage 类型的局部变量，实际上是一个指向状态变量的指针（引用），不会产生拷贝：contract StoragePointer { struct User { uint256 balance; bool active; } mapping(address => User) public users; function deactivate(address addr) external { User storage u = users[addr]; // storage 指针，不拷贝 u.active = false; // 直接修改链上状态 }}如果误写成 User memory u = users[addr]，修改只会影响内存副本，不会写入链上，这是一个常见的 bug 来源。追问五：EVM 视角下三种位置的本质storage：对应 EVM 的 SLOAD/SSTORE 操作码，读写永久存储（key-value 永久数据库），每次操作 2100+ Gasmemory：对应 MLOAD/MSTORE，线性可扩展内存，按字访问，Gas 随使用量线性增长calldata：对应 CALLDATALOAD/CALLDATASIZE/CALLDATACOPY，只读访问交易输入数据，Gas 成本最低

在 cURL 中，请求头（Request Headers）用于向服务器传递元数据，比如认证凭证、内容类型、客户端标识等。API 调试和接口对接时，设置请求头是最常见的操作之一。基本语法使用 -H 或 --header 参数添加请求头，格式必须为 "Name: Value"：curl -H "Header-Name: Header-Value" https://api.example.com设置多个请求头时，每个 -H 单独写一个：curl -H "Content-Type: application/json" \ -H "Authorization: Bearer token123" \ -H "Accept: application/json" \ https://api.example.com/users常用请求头# Content-Type — 指定请求体格式curl -H "Content-Type: application/json" \ -d '{"name":"test"}' \ https://api.example.com/users# Authorization — 身份认证（Bearer Token）curl -H "Authorization: Bearer your_token_here" \ https://api.example.com/protected# Authorization — HTTP Basic Authcurl -H "Authorization: Basic $(echo -n 'user:pass' | base64)" \ https://api.example.com/protected# Accept — 告诉服务器你期望的响应格式curl -H "Accept: application/json" \ https://api.example.com/users# User-Agent — 标识客户端curl -H "User-Agent: MyApp/1.0" \ https://api.example.com/data# Cookie — 发送 Cookiecurl -H "Cookie: session_id=abc123; user_id=456" \ https://api.example.com/profile| 请求头 | 用途 | 常见值 ||--------|------|--------|| Content-Type | 请求体格式 | application/json, application/x-www-form-urlencoded, multipart/form-data || Authorization | 身份认证 | Bearer token, Basic base64(user:pass) || Accept | 期望的响应格式 | application/json, text/html, / || User-Agent | 客户端标识 | Mozilla/5.0, MyApp/1.0 || Cookie | 发送 Cookie | session_id=abc123 || Cache-Control | 缓存控制 | no-cache, no-store || Referer | 来源页面 | https://example.com/page |快捷选项cURL 为几个常用请求头提供了专用选项，比 -H 更简洁：# -A / --user-agent — 设置 User-Agentcurl -A "MyApp/1.0" https://api.example.com/data# -e / --referer — 设置 Referercurl -e "https://example.com/page" https://api.example.com/data# -b / --cookie — 设置 Cookie（也支持从文件读取）curl -b "session_id=abc123; user_id=456" https://api.example.com/profile# -b 从文件读取 Cookiecurl -b cookies.txt https://api.example.com/profile删除请求头cURL 默认会发送一些内部请求头（如 Host、Accept、User-Agent）。如果想删除某个默认头，将值设为空：# 删除默认的 Accept 头curl -H "Accept:" https://api.example.com# 删除默认的 User-Agent（某些反爬场景需要）curl -H "User-Agent:" https://api.example.com冒号后面没有任何内容，cURL 就不会发送该头部。对于没有值的头部字段，在名称后加分号：curl -H "X-Empty-Header;" https://api.example.com从文件读取请求头请求头较多时，可以写入文件，用 @ 引用：# headers.txt 内容：# Content-Type: application/json# Authorization: Bearer token123# X-Custom-Header: custom-valuecurl -H @headers.txt https://api.example.com/users每行一个请求头，格式与 -H 参数一致。验证请求头是否生效加 -v（verbose）参数可以看到实际发出的请求头，以 > 开头的行就是发出的头部：curl -v -H "Authorization: Bearer token123" \ https://api.example.com/protected# 输出中可以看到：# > GET /protected HTTP/2# > Host: api.example.com# > Authorization: Bearer token123# > User-Agent: curl/8.1.2# > Accept: */*也可以用 httpbin.org 快速验证，它会把收到的请求头原样返回：curl -H "X-Test: hello" https://httpbin.org/headers# 返回 JSON 中会显示你发送的所有请求头如果只想看响应头（以 < 开头的行），用 -I（HEAD 请求）或 -D -（转储响应头到 stdout）。重复头部的处理多次用 -H 设置同一个头部名称时，行为取决于 cURL 的内部实现：# 对标准头部（如 User-Agent），后者覆盖前者curl -H "User-Agent: Agent1" -H "User-Agent: Agent2" URL# 实际发送：User-Agent: Agent2# 对自定义头部，cURL 可能发送多个同名头部curl -H "X-Custom: value1" -H "X-Custom: value2" URL# 可能发送两个 X-Custom 头部大多数服务器按照 RFC 7230 将同名头部合并为逗号分隔的单个值。如果需要覆盖而非追加，用 -v 确认实际发送结果，或确保只写一次该头部。特殊场景发送压缩请求体：# 告诉服务器请求体是 gzip 压缩的curl -H "Content-Encoding: gzip" \ --data-binary @compressed.gz \ https://api.example.com/uploadCORS 预检请求：# 模拟浏览器发送 OPTIONS 预检curl -X OPTIONS \ -H "Origin: https://example.com" \ -H "Access-Control-Request-Method: POST" \ -H "Access-Control-Request-Headers: X-Custom-Header" \ https://api.example.com/data带摘要认证（Digest Auth）：# curl 内置摘要认证支持，不必手动构造 Authorization 头curl --digest -u user:pass https://api.example.com/protected发送 multipart 表单时自动设置的头部：# -F 会自动设置 Content-Type: multipart/form-data; boundary=...# 不要手动设置 Content-Type，否则会覆盖 boundarycurl -F "file=@photo.jpg" \ -F "name=test" \ https://api.example.com/upload常见踩坑1. 冒号后面没有空格# 可能出问题 — 部分服务端解析失败curl -H "Content-Type:application/json" URL# 推荐 — 冒号后加空格curl -H "Content-Type: application/json" URLHTTP 规范允许冒号后无空格，但实际中部分服务端解析会出问题，建议始终加空格。2. 值含特殊字符未加引号# 错误 — 分号会被 shell 解释curl -H Cookie: session=abc; user=123 URL# 正确 — 整个头用双引号包裹curl -H "Cookie: session=abc; user=123" URL3. multipart 表单手动设置了 Content-Type# 错误 — 覆盖了 boundary，服务端无法解析curl -H "Content-Type: multipart/form-data" -F "file=@data.bin" URL# 正确 — 让 -F 自动设置 Content-Typecurl -F "file=@data.bin" URL4. 后设置的头部覆盖前一个# 最终 User-Agent 是 Agent2curl -H "User-Agent: Agent1" \ -H "User-Agent: Agent2" \ URL对标准头部是覆盖行为，用 -v 确认实际发送结果。

在 cURL 中处理 URL 编码和特殊字符是日常请求中绕不开的问题——查询参数里的空格、中文、& 和 = 都可能在传输中被误解析。理解 cURL 提供的编码机制，以及何时需要手动编码，能避免大量调试时间。URL 编码的核心规则URL 编码（Percent Encoding）将非安全字符转换为 %XX 格式，XX 是字符 UTF-8 字节的十六进制表示。RFC 3986 规定，只有字母、数字和 -_.~ 属于无需编码的"未保留字符"。# 常见字符的编码映射空格 -> %20& -> %26= -> %3D+ -> %2B% -> %25# -> %23中文 -> %E4%B8%AD%E6%96%87需要区分两种编码场景：URL 路径编码遵循 RFC 3986，空格编码为 %20；表单提交编码（application/x-www-form-urlencoded）遵循 HTML 规范，空格编码为 +。cURL 的 --data-urlencode 使用的就是表单编码规则。--data-urlencode 的四种语法--data-urlencode 是 cURL 处理编码的主力参数，但它支持多种写法，行为各不相同：# 1. key=value：对 value 部分 URL 编码curl --data-urlencode "name=hello world" https://api.example.com# 发送：name=hello+world（value 编码，key 不编码）# 2. =value：对整个 value 编码，不带 keycurl --data-urlencode "=hello world" https://api.example.com# 发送：hello+world# 3. key@filename：读取文件内容作为 value 并编码curl --data-urlencode "content@/tmp/payload.txt" https://api.example.com# 文件内容会被 URL 编码后作为 content 的值# 4. @filename：读取文件内容并编码，不带 keycurl --data-urlencode "@/tmp/raw_data.txt" https://api.example.com# 文件内容整体编码后发送面试追问：为什么 --data-urlencode "name=value" 只编码 value 而不编码 key？因为 key 是开发者可控的固定字符串，通常不含特殊字符；而 value 来自用户输入，不可控，必须编码。GET 请求中的编码：-G 配合 --data-urlencode--data-urlencode 默认以 POST 方式发送数据。加上 -G（或 --get）后，数据会被追加到 URL 查询字符串中：# 构建带编码的 GET 请求curl -G https://api.example.com/search \ --data-urlencode "q=hello world" \ --data-urlencode "category=技术&编程"# 实际请求：https://api.example.com/search?q=hello+world&category=%E6%8A%80%E6%9C%AF%26%E7%BC%96%E7%A8%8B如果不加 -G，同样的命令会把数据放进请求体，变成 POST 请求——这是 cURL 新手最常犯的错误之一。手动编码：当 --data-urlencode 不够用时有些场景下 --data-urlencode 无法覆盖需求，比如 URL 路径中包含中文、需要对整个 URL 做编码处理等。# 使用 Python 编码（最通用）ENCODED=$(python3 -c "import urllib.parse; print(urllib.parse.quote('hello world & 中文'))")curl "https://api.example.com/search?q=$ENCODED"# 使用 jq 编码（适合管道操作）ENCODED=$(jq -nr --arg s 'hello world' '$s | @uri')curl "https://api.example.com/search?q=$ENCODED"# 利用 cURL 自身做编码（巧妙但可读性差）encode() { local data="$(curl -s -o /dev/null -w '%{url_effective}' --get --data-urlencode "$1" "")" echo "${data#/?}"}ENCODED=$(encode "hello world & 中文")curl "https://api.example.com/search?q=$ENCODED"双编码陷阱对已经编码过的字符串再次编码，会产生双重编码（double-encoding），这是最难排查的一类 bug：# 正确：只编码一次curl -G https://api.example.com/search \ --data-urlencode "q=hello%20world"# 服务端收到：q=hello%20world → 解码为 "hello world"# 错误：--data-urlencode 又对 %20 做了一次编码# 结果 %20 变成了 %2520# 服务端收到：q=hello%2520world → 解码为 "hello%20world"避免方法：如果一个值已经是编码后的，不要再通过 --data-urlencode 处理。用 -d 代替，或者确保输入始终是未编码的原始值。# 如果值已经是编码后的，用 -d 直接发送curl -G https://api.example.com/search \ -d "q=hello%20world"# 如果值是原始值，用 --data-urlencodecurl -G https://api.example.com/search \ --data-urlencode "q=hello world"查询参数中 & 和 = 的歧义URL 中 & 是参数分隔符，= 是键值分隔符。当参数值本身包含这些字符时，不加编码会导致参数解析错误：# 错误：& 被误认为参数分隔符curl "https://api.example.com/search?q=foo&bar"# 服务端理解为两个参数：q=foo 和 bar（无值）# 正确方式一：手动编码curl "https://api.example.com/search?q=foo%26bar"# 正确方式二：用 --data-urlencode 自动处理curl -G https://api.example.com/search \ --data-urlencode "q=foo&bar"路径中的特殊字符URL 路径（? 之前的部分）中的特殊字符处理与查询参数不同。cURL 默认会对路径中的部分字符做处理：# 路径中的空格需要编码curl "https://api.example.com/files/my%20document.pdf"# 路径中的中文需要编码curl "https://api.example.com/files/%E4%B8%AD%E6%96%87%E6%96%87%E4%BB%B6.pdf"# --path-as-is：阻止 cURL 对路径做任何处理（保留原始路径）# 不加此参数时，cURL 会把 /../ 和 /./ 规范化curl --path-as-is "https://api.example.com/../secret.txt"JSON 请求体中的特殊字符JSON 请求体不走 URL 编码，但有自己的转义规则——双引号、反斜杠、控制字符需要转义：# 直接写 JSON 时需要手动转义curl -X POST https://api.example.com/users \ -H "Content-Type: application/json" \ -d '{"name":"张三","bio":"Line1\nLine2\tTabbed"}'# 用 jq 生成 JSON，自动处理转义（推荐）jq -n '{name: "张三", bio: "Line1\nLine2"}' | \ curl -X POST https://api.example.com/users \ -H "Content-Type: application/json" \ -d @-表单提交的混合编码实际开发中经常需要同时发送已编码字段和待编码字段：curl -X POST https://api.example.com/submit \ -d "id=123&status=active" \ --data-urlencode "content=Special chars: & = ?"-d 和 --data-urlencode 可以混用。cURL 会将所有数据合并为一条请求体，-d 的部分原样发送，--data-urlencode 的部分自动编码。调试编码问题的方法编码问题的排查关键在于确认"实际发送的内容到底是什么"：# 方法一：用 -v 查看完整请求（包含编码后的 URL）curl -v -G https://api.example.com/search \ --data-urlencode "q=hello world"# 方法二：用 --trace-ascii 把完整请求写入文件curl --trace-ascii /tmp/trace.log -G https://api.example.com/search \ --data-urlencode "q=hello world"# 然后查看 trace.log 确认实际 URL# 方法三：用 -w 输出编码后的实际 URLcurl -s -o /dev/null -w '%{url_effective}\n' -G https://api.example.com/search \ --data-urlencode "q=hello world"# 输出：https://api.example.com/search?q=hello+world实战脚本#!/bin/bash# URL 编码处理封装# 编码函数（依赖 python3）urlencode() { python3 -c "import urllib.parse, sys; print(urllib.parse.quote(sys.argv[1]))" "$1"}API_BASE="https://api.example.com/v1"# GET 请求：自动编码查询参数curl -G "${API_BASE}/search" \ --data-urlencode "q=hello world & 中文" \ -H "Accept: application/json"# POST 请求：混合编码字段curl -X POST "${API_BASE}/submit" \ -d "type=article" \ --data-urlencode "title=深入理解 cURL 编码" \ --data-urlencode "content=包含 & 和 = 的内容"# 路径中含中文：手动编码路径部分ENCODED_NAME=$(urlencode "中文文件")curl "${API_BASE}/files/${ENCODED_NAME}.pdf"面试中常被追问的关键区别：--data-urlencode 编码的是 value 部分，-d 原样发送；表单编码空格变 +，路径编码空格变 %20；已编码的值不要再过 --data-urlencode，否则会双编码。掌握这三条，cURL 的编码问题基本不会踩坑。

为什么要关注 cURL 性能cURL 是后端开发、运维和测试中最常用的命令行 HTTP 工具。默认配置下，cURL 每次请求都重新建立 TCP 连接和 TLS 握手，批量调用时性能损耗显著。掌握超时、重试、连接复用、并发和压缩等优化手段，能让生产环境的 API 调用速度提升数倍。超时与速率控制超时是生产环境的第一道防线。cURL 提供两级超时：--connect-timeout：TCP 连接建立的最大等待时间--max-time：整个请求（含传输）的最大耗时# 连接超时 10 秒，整体超时 30 秒curl --connect-timeout 10 --max-time 30 https://api.example.com# 7.68.0+ 支持毫秒级超时curl --connect-timeout 3.5 --max-time 10.5 https://api.example.com遇到慢速传输时，--speed-time 和 --speed-limit 可以主动中断卡住的连接：# 如果连续 5 秒速度低于 100 字节/秒，自动中断curl --speed-time 5 --speed-limit 100 https://api.example.com/large-file.zip -O速率限制用 --limit-rate，在带宽敏感场景下控制下载速度：curl --limit-rate 1M https://example.com/large-file.zip -O重试机制网络请求天生不可靠，重试是保障可靠性的核心手段。# 失败自动重试 3 次curl --retry 3 https://api.example.com# 重试间隔 2 秒，防止立即重试加重服务端压力curl --retry 3 --retry-delay 2 https://api.example.com# 限定重试总耗时，避免无限等待curl --retry 5 --retry-delay 1 --retry-max-time 30 https://api.example.com# 连接被拒绝时也重试（默认只重试超时类错误）curl --retry 3 --retry-connrefused https://api.example.com关键细节：--retry 默认只对超时、5xx 错误和连接失败重试，不会对 4xx 重试。如果需要针对特定 HTTP 状态码重试，需要脚本层面处理。--retry-delay 只在两次重试之间生效，首次请求不受影响。连接复用HTTP Keep-Alive 是 cURL 性能优化中收益最高的一项。一次 TCP + TLS 握手通常需要 100-300ms，复用连接直接省掉这笔开销。# 保持连接 60 秒curl --keepalive-time 60 https://api.example.com命令行 cURL 在单次执行中自动复用连接。但跨进程调用时无法复用——这是命令行 cURL 的固有限制，需要 libcurl 句柄复用才能解决：// libcurl 句柄复用示例CURL *handle = curl_easy_init();// 第一次请求curl_easy_setopt(handle, CURLOPT_URL, "https://api.example.com/users");curl_easy_perform(handle);// 第二次请求复用同一连接curl_easy_setopt(handle, CURLOPT_URL, "https://api.example.com/products");curl_easy_perform(handle);curl_easy_cleanup(handle);多 handle 场景下，用 curl_share_setopt 共享 DNS 缓存和 Cookie，进一步减少重复开销。DNS 解析也有缓存收益。--resolve 可以跳过 DNS 查询：# 直接指定 IP，跳过 DNS 解析curl --resolve api.example.com:443:203.0.113.50 https://api.example.com这对调试 CDN 回源、绕过 DNS 劫持、压测时固定后端 IP 都有用。HTTP/2 多路复用HTTP/2 在单条 TCP 连接上并行传输多个请求，从根本上解决了 HTTP/1.1 的队头阻塞问题：# 强制使用 HTTP/2curl --http2 https://api.example.com# 优先协商 HTTP/2，失败回退 HTTP/1.1curl --http2-prior-knowledge https://api.example.com配合连接复用，HTTP/2 的收益最大：多个 API 请求共享一条连接，省去多次握手和队头等待。适合微服务网关、GraphQL 批量查询等场景。并发请求cURL 7.66+ 原生支持并行传输，使用 -Z（--parallel）标志：# 并行下载多个 URLcurl -Z -OL https://example.com/a.json https://example.com/b.json# 控制最大并发数curl -Z --parallel-max 5 -OL https://example.com/file{1..10}.zip旧版本用 shell 方式实现并发：# 后台进程 + waitfor url in "${urls[@]}"; do curl -s "$url" -o "$(basename $url).json" &donewait# GNU Parallel，更精细的并发控制cat urls.txt | parallel -j 4 curl -s {} -o {/}.json选择建议：少量 URL 用 -Z 即可，批量任务推荐 GNU Parallel，便于控制并发数和失败重试。压缩传输--compressed 让 cURL 在请求头添加 Accept-Encoding，服务端返回压缩响应后自动解压：curl --compressed https://api.example.comJSON API 响应通常能压缩 60-80%，对移动端和带宽敏感场景效果显著。也可以手动指定压缩算法：curl -H "Accept-Encoding: gzip, deflate, br" https://api.example.com注意：--compressed 在服务端不支持压缩时不会报错，cURL 会正常接收未压缩的响应。TCP 与 TLS 优化--tcp-nodelay 禁用 Nagle 算法，减少小包传输延迟，适合交互式 API 调用：curl --tcp-nodelay --tcp-fastopen https://api.example.comTLS 握手是 HTTPS 请求中耗时的环节，优化点包括：# 强制使用 TLS 1.2 及以上（拒绝旧协议）curl --tlsv1.2 --tls-max tls1.3 https://api.example.com# TLS 会话复用（libcurl 句柄复用时自动生效）# CA 缓存减少证书链重复加载（libcurl 7.84+）生产环境务必验证证书，不要用 -k 跳过验证。密码等凭证不要写在命令行里：# -u 只输用户名，cURL 会提示输入密码curl -u "username" https://api.example.com# 更好：用环境变量curl -H "Authorization: Bearer $API_TOKEN" https://api.example.com性能分析-w（--write-out）是 cURL 性能诊断的核心工具，可以输出请求各阶段耗时：curl -w "DNS: %{time_namelookup}sConnect: %{time_connect}sSSL: %{time_appconnect}sTTFB: %{time_starttransfer}sTotal: %{time_total}sSize: %{size_download}BSpeed: %{speed_download}B/s" -o /dev/null -s https://api.example.com各指标含义：| 指标 | 含义 | 关注场景 ||------|------|----------|| time_namelookup | DNS 解析耗时 | CDN 选路、DNS 劫持排查 || time_connect | TCP 连接建立耗时 | 网络延迟、连接池耗尽 || time_appconnect | TLS 握手完成耗时 | 证书链过长、协议协商慢 || time_starttransfer | 首字节到达耗时（TTFB） | 服务端处理慢、排队过长 || time_total | 整体耗时 | 端到端性能评估 |定位思路：如果 time_namelookup 高，查 DNS；time_connect 高，查网络或连接池；time_appconnect 高，查 TLS 配置；time_starttransfer 高但前面指标正常，查服务端。把格式写入文件可以复用：cat > perf-format.txt << 'EOF'timestamp:%{time_total} dns:%{time_namelookup} connect:%{time_connect} ssl:%{time_appconnect} ttfb:%{time_starttransfer} size:%{size_download} speed:%{speed_download}EOFcurl -w "@perf-format.txt" -o /dev/null -s https://api.example.com >> perf.log大文件与断点续传# 分块下载curl -r 0-10485760 https://example.com/large-file.zip -o part1.zipcurl -r 10485761-20971520 https://example.com/large-file.zip -o part2.zip# 断点续传curl -C - -O https://example.com/large-file.zip分块下载 + 断点续传组合使用：先分块下载，某块中断后用 -C - 续传，最后用 cat part*.zip > large-file.zip 合并。流式处理避免大文件占满内存：# 流式处理 JSON 响应curl -s https://api.example.com/stream | jq '.[] | .name'生产级脚本模板#!/bin/bash# 生产级 API 调用脚本API_URL="https://api.example.com/v1/data"TOKEN="${API_TOKEN:-$(cat ~/.api_token)}"TIMEOUT=30RETRY=3api_call() { curl -s -S --connect-timeout 10 --max-time "$TIMEOUT" --retry "$RETRY" --retry-delay 2 --retry-connrefused --compressed --tlsv1.2 -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -H "Accept: application/json" -H "User-Agent: MyApp/1.0" -w "{"status":%{http_code},"time":%{time_total},"size":%{size_download}}" "$@"}response=$(api_call "$API_URL")if [ $? -eq 0 ]; then echo "$response" | jq '.'else echo "Request failed" >&2 exit 1fi可维护性方面，常用配置写入 ~/.curlrc：verboseconnect-timeout = 10max-time = 60retry = 3日志监控脚本示例：#!/bin/bashwhile true; do STATUS=$(curl -w "%{http_code}" -o /dev/null -s --max-time 5 https://api.example.com/health) echo "$(date '+%Y-%m-%d %H:%M:%S') | Status: $STATUS" [ "$STATUS" != "200" ] && echo "API unhealthy!" | mail -s "API Alert" admin@example.com sleep 60done优化效果对比| 优化项 | 优化前 | 优化后 | 典型提升 ||--------|--------|--------|----------|| 连接复用 | 每次新建连接 | Keep-Alive | 延迟降低 30-50% || 压缩传输 | 原始大小 | Gzip/Brotli | 体积减少 60-80% || HTTP/2 多路复用 | 队头阻塞 | 单连接并行 | 并发延迟降低 50%+ || 并发请求 | 串行执行 | 并行处理 | 吞吐提升 3-5 倍 || DNS 缓存 | 每次解析 | --resolve/本地缓存 | 延迟降低 10-20ms || 断点续传 | 重新下载 | 续传 | 节省已完成部分的带宽 |追问cURL 的 --retry 和应用层面的指数退避重试有什么区别？什么时候该用哪种？命令行 cURL 的连接复用有什么局限？libcurl 句柄复用如何突破这个限制？--compressed 在服务端不支持压缩时行为是什么？会不会导致请求失败？HTTP/2 多路复用和 -Z 并行传输有什么区别？各自适合什么场景？

核心答案Zustand 通过 create 函数创建 store，返回一个可直接在组件中使用的 Hook。与 Redux 不同，它不需要 Provider 包裹，store 本身就是 Hook：import { create } from 'zustand'const useStore = create((set, get) => ({ count: 0, increment: () => set((state) => ({ count: state.count + 1 })), reset: () => set({ count: 0 }),}))组件中使用时，推荐通过选择器订阅，避免不必要的重渲染：const count = useStore((state) => state.count) // 只订阅 countconst increment = useStore((state) => state.increment) // 只订阅 incrementset 与 get 的用法set 用于更新状态，支持对象和函数两种形式。Zustand 自动浅合并第一层属性，所以不需要手动展开 ...state：const useStore = create((set) => ({ user: { name: 'Tom', age: 20 }, // 对象形式：直接替换第一层属性 setName: (name) => set({ user: { name, age: 20 } }), // 注意：第二层需手动处理 // 函数形式：基于旧状态计算 incrementAge: () => set((state) => ({ user: { ...state.user, age: state.user.age + 1 } })),}))get 用于在 action 中读取当前状态，不触发订阅：const useStore = create((set, get) => ({ items: [], addItem: (item) => set({ items: [...get().items, item] }), getCount: () => get().items.length, // 不触发重渲染}))选择性订阅与性能优化直接解构整个 store 会导致任何状态变化都触发重渲染，应避免：// 不推荐：任何状态变化都触发重渲染const { count, name } = useStore()// 推荐：按需订阅const count = useStore((s) => s.count)const name = useStore((s) => s.name)对于复杂对象，使用 shallow 比较避免引用变化导致的重渲染：import { shallow } from 'zustand/shallow'const { name, age } = useStore( (s) => ({ name: s.user.name, age: s.user.age }), shallow)Store 拆分（Slice 模式）大型应用中，将不同领域的状态拆成独立 slice，再合并到一个 store：// slices/cartSlice.jsexport const createCartSlice = (set) => ({ items: [], addItem: (item) => set((s) => ({ items: [...s.items, item] })), clearCart: () => set({ items: [] }),})// slices/userSlice.jsexport const createUserSlice = (set) => ({ user: null, setUser: (user) => set({ user }),})// store.jsimport { create } from 'zustand'import { createCartSlice } from './slices/cartSlice'import { createUserSlice } from './slices/userSlice'const useStore = create((...a) => ({ ...createCartSlice(...a), ...createUserSlice(...a),}))异步操作Zustand 的 action 可以直接是 async 函数，不需要额外的中间件：const useStore = create((set) => ({ data: null, loading: false, error: null, fetchData: async (id) => { set({ loading: true, error: null }) try { const res = await fetch(`/api/data/${id}`) const data = await res.json() set({ data, loading: false }) } catch (error) { set({ error: error.message, loading: false }) } },}))常用中间件persist — 持久化到 localStorageimport { create } from 'zustand'import { persist } from 'zustand/middleware'const useStore = create( persist( (set) => ({ theme: 'light', setTheme: (theme) => set({ theme }), }), { name: 'theme-storage' } // localStorage key ))immer — 不可变更新的简化写法import { create } from 'zustand'import { immer } from 'zustand/middleware/immer'const useStore = create( immer((set) => ({ user: { name: 'Tom', address: { city: 'Beijing' } }, setCity: (city) => set((state) => { state.user.address.city = city }), // 无需手动展开，直接修改 draft })))devtools — Redux DevTools 调试支持import { create } from 'zustand'import { devtools } from 'zustand/middleware'const useStore = create( devtools((set) => ({ count: 0, increment: () => set((s) => ({ count: s.count + 1 })), }), { name: 'CounterStore' }))中间件可以组合使用，顺序从外到内：devtools(persist(immer(...)))。create 与 createStore 的区别| | create | createStore ||---|---|---|| 返回值 | React Hook | Store 对象 || 使用场景 | React 组件内 | React 外（测试、服务端、非React环境） || 订阅方式 | useStore(s => s.xxx) | store.subscribe() / store.getState() |import { createStore } from 'zustand'const store = createStore((set) => ({ count: 0, increment: () => set((s) => ({ count: s.count + 1 })),}))// React 外部使用store.getState().count // 读取store.setState({ count: 10 }) // 更新store.subscribe((state) => { // 监听 console.log('state changed', state)})追问：Zustand 与 Redux 的核心区别是什么？无需 Provider：Zustand 不需要 <Provider> 包裹组件树，直接导入 Hook 使用订阅粒度：Zustand 通过选择器精确订阅，Redux 用 useSelector 实现类似效果但机制不同样板代码：Zustand 无 action type、reducer、dispatch，一个函数搞定Bundle 体积：Zustand ~1KB vs Redux Toolkit ~11KB中间件生态：Redux 有更成熟的中间件链，Zustand 的中间件更轻量但够用

cURL 是开发者在 API 开发中最常接触的命令行工具，但多数人只停留在 curl -X GET 的层面。遇到请求超时、证书报错、重定向异常等问题时，如果不知道 cURL 的调试参数，排查就像盲人摸象。-v：你的第一道诊断线-v（verbose）是 cURL 调试的核心开关，它会输出完整的请求-响应交互过程：curl -v https://api.example.com/users输出中以不同前缀区分信息来源：> 发出的请求行和请求头< 收到的响应头* 连接建立和 TLS 握手细节当 API 返回 401 时，先看 > 部分确认 Authorization 头是否真的发出去了；返回 301/302 时，看 < Location 确认跳转目标。大部分问题在 -v 输出中就能定位。-w：量化请求的每个阶段-w（write-out）把请求拆解为可量化的时间指标，是定位性能瓶颈的关键：curl -w "DNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \ -o /dev/null -s https://api.example.com各指标的含义和典型排查思路：| 指标 | 含义 | 偏高时排查方向 ||------|------|----------------|| time_namelookup | DNS 解析耗时 | 检查 DNS 配置或切换 DNS 服务器 || time_connect | TCP 连接耗时 | 网络链路问题或服务端负载高 || time_appconnect | TLS 握手耗时 | 证书链过长或协商算法不匹配 || time_starttransfer | 首字节时间（TTFB） | 服务端处理慢，需排查后端逻辑 || time_total | 请求总耗时 | 综合判断，大文件传输时主要受下载速度影响 |如果 time_namelookup 占了总时间的 80%，问题在 DNS 而非服务端；如果 TTFB 正常但 time_total 很高，说明是响应体太大或网络带宽瓶颈。--trace：完整的请求审计日志-v 不够用时，--trace-ascii 记录每一个字节的收发：# 文本格式日志（可读性好）curl --trace-ascii debug.log https://api.example.com# 十六进制格式（排查编码/二进制问题）curl --trace debug.hex https://api.example.com--trace 会记录请求体和响应体的完整内容，适合排查 POST 请求的 body 是否正确发送、响应中是否存在隐藏字符等问题。注意敏感信息（如 token）也会被记录，不要在生产环境随意使用。超时与重试：让请求可控线上环境的请求不能无限等待，必须设置超时：# 连接超时 5 秒，整体超时 10 秒curl --connect-timeout 5 --max-time 10 https://api.example.com# 失败后重试 3 次，间隔 2 秒curl --retry 3 --retry-delay 2 https://api.example.com--connect-timeout 控制 TCP 建连阶段的最大等待时间，--max-time 控制整个请求（含下载）的上限。两者要配合使用——只设 --connect-timeout 而不设 --max-time，慢速下载仍可能卡住。SSL/TLS 证书问题排查证书相关错误是 HTTPS 请求中最常见的坑：# 查看证书链和协商细节curl -v https://api.example.com 2>&1 | grep -A 10 "SSL connection"# 跳过证书验证（仅限本地调试）curl -k https://self-signed.badssl.com# 指定 CA 证书curl --cacert /path/to/ca.crt https://api.example.com# 指定客户端证书（mTLS 场景）curl --cert client.pem --key client-key.pem https://mtls.example.com-k 只能用于临时测试，永远不要在正式环境跳过证书验证。生产环境中遇到证书错误，应使用 --cacert 指定正确的 CA 证书或 --resolve 绕过 DNS 指向正确的服务端。重定向与认证的隐藏陷阱cURL 默认不跟随重定向，需要加 -L：# 跟随重定向并显示每一步的状态码curl -L -v https://example.com 2>&1 | grep -E "(< HTTP|< Location)"重定向有一个容易被忽略的安全行为：当 Location 指向不同域名时，cURL 会自动丢弃 Authorization 头，防止凭据泄露到第三方。如果需要跨域传递认证信息，需要显式用 -H 重新添加。DNS 与网络层诊断当请求连不上服务器时，从 DNS 和网络层开始排查：# 指定 DNS 服务器（绕过本地 DNS 污染）curl --dns-servers 8.8.8.8 https://api.example.com# 手动映射域名到 IP（跳过 DNS 解析）curl --resolve example.com:443:192.168.1.100 https://example.com# 强制 IPv4（IPv6 连接异常时排查）curl -4 https://api.example.com# 测试端口连通性curl -v telnet://example.com:80--resolve 在调试负载均衡、灰度发布时特别有用——可以把域名直接指向特定后端实例，绕过 LB 层。组合调试实战脚本把常用的调试步骤封装成脚本，遇到问题直接执行：#!/bin/bash# api-debug.sh — 快速诊断 API 请求URL=$1[ -z "$URL" ] && echo "Usage: $0 <url>" && exit 1echo "=== 连通性检查 ==="curl -o /dev/null -s -w "HTTP %{http_code} | TTFB %{time_starttransfer}s | Total %{time_total}s\n" "$URL"echo ""echo "=== 响应头 ==="curl -s -I "$URL"echo ""echo "=== 重定向链 ==="curl -s -I -L "$URL" 2>&1 | grep -E "^(HTTP|Location)"echo ""echo "=== 各阶段耗时 ==="curl -o /dev/null -s -w "DNS %{time_namelookup}s | TCP %{time_connect}s | TLS %{time_appconnect}s | TTFB %{time_starttransfer}s | Total %{time_total}s\n" "$URL"用法：bash api-debug.sh https://api.example.com/users面试高频追问Q: -v 和 --trace-ascii 有什么区别？-v 只输出请求头和响应头，不记录 body；--trace-ascii 记录完整的请求和响应内容，包括 body。排查请求体问题时必须用 --trace-ascii。Q: curl -w 的 timestarttransfer 和 timetotal 差异大说明什么？TTFB 小但 Total 大，说明服务端响应快但传输慢——可能是响应体太大、网络带宽不足，或服务端在流式传输。反之如果 TTFB 本身就高，瓶颈在服务端处理速度。Q: 为什么 curl -L 跟随重定向后 Authorization 头丢了？这是 cURL 的安全设计。当重定向目标与原始域名不同时，cURL 自动移除敏感头（Authorization、Cookie 等），防止凭据被发送到第三方服务器。这是 RFC 7235 的安全要求。