服务端面试题手册

Jest 是由 Facebook（Meta）开发的 JavaScript 测试框架，凭借零配置、内置工具链和出色的开发者体验，已成为前端领域使用率最高的测试框架。根据 State of JS 调查，Jest 的使用率从 2016 年的 8% 增长到 2021 年的 73%，被 Facebook、Airbnb、Spotify 等公司广泛采用。核心特性1. 零配置开箱即用Jest 内置了测试运行器、断言库、Mock 系统、代码覆盖率工具和快照测试功能，无需安装和配置额外依赖即可开始编写测试：npm install --save-dev jest在 package.json 中添加测试脚本后即可运行：{ "scripts": { "test": "jest" }}2. 内置断言库与丰富的匹配器Jest 提供了 expect 断言函数和大量匹配器（matchers），覆盖常见断言场景：test('基础匹配器示例', () => { // 相等性判断 expect(1 + 1).toBe(2); // 严格相等 === expect({ a: 1 }).toEqual({ a: 1 }); // 深度相等 // 真值判断 expect(true).toBeTruthy(); expect(null).toBeFalsy(); expect(undefined).toBeUndefined(); expect(1).toBeDefined(); // 数字比较 expect(0.1 + 0.2).toBeCloseTo(0.3); // 浮点数近似 expect(5).toBeGreaterThan(3); // 字符串匹配 expect('hello world').toMatch(/world/); // 数组与异常 expect([1, 2, 3]).toContain(2); expect(() => { throw new Error('err'); }).toThrow('err');});3. 强大的 Mock 系统Mock 是 Jest 最核心的能力之一，可以模拟函数、模块和定时器，隔离被测代码的外部依赖：// 模拟函数const mockFn = jest.fn();mockFn.mockReturnValue(42);mockFn(); // 返回 42// 验证调用情况expect(mockFn).toHaveBeenCalled();expect(mockFn).toHaveBeenCalledTimes(1);// 模拟模块jest.mock('axios');axios.get.mockResolvedValue({ data: { name: 'test' } });// 模拟实现const calc = jest.fn((a, b) => a + b);calc(1, 2); // 返回 3expect(calc).toHaveBeenCalledWith(1, 2);4. 快照测试快照测试用于捕获组件或函数的输出，在后续运行中对比是否发生变化，特别适合 UI 组件测试：test('按钮组件快照', () => { const { container } = render(<Button label="Submit" />); expect(container).toMatchSnapshot();});首次运行会生成 .snap 快照文件，后续运行自动对比。如果变化是预期的，使用 jest --updateSnapshot 更新。5. 并行执行与性能优化Jest 自动并行执行测试文件，利用 Worker 进程充分使用多核 CPU，显著提高测试速度。还支持以下优化策略：--onlyChanged：只运行受改动影响的测试文件--findRelatedTests：运行与指定文件相关的测试缓存机制：自动缓存未变更文件的测试结果6. 内置代码覆盖率无需额外安装 Istanbul 等工具，Jest 内置覆盖率统计：jest --coverage可生成行覆盖率、分支覆盖率、函数覆盖率和语句覆盖率报告，支持 HTML 可视化输出。核心概念测试组织结构describe('Calculator', () => { beforeAll(() => { /* 所有测试前执行一次 */ }); afterAll(() => { /* 所有测试后执行一次 */ }); beforeEach(() => { /* 每个测试前执行 */ }); afterEach(() => { /* 每个测试后执行 */ }); test('adds two numbers', () => { expect(add(1, 2)).toBe(3); }); test('subtracts two numbers', () => { expect(subtract(5, 3)).toBe(2); });});describe：将相关测试用例分组，支持嵌套test/it：定义单个测试用例钩子函数：beforeAll/afterAll/beforeEach/afterEach 管理测试生命周期异步测试Jest 支持多种异步测试方式：// 回调方式test('callback', (done) => { fetchData((data) => { expect(data).toBe('result'); done(); });});// Promise 方式test('promise', () => { return fetchData().then(data => { expect(data).toBe('result'); });});// async/await 方式（推荐）test('async/await', async () => { const data = await fetchData(); expect(data).toBe('result');});// resolves/rejects 匹配器test('resolves matcher', () => { return expect(fetchData()).resolves.toBe('result');});面试常见追问Jest 的测试隔离机制是什么？每个测试文件在独立的模块作用域中执行，beforeEach/afterEach 确保测试之间状态不共享。Jest 通过 jest.isolateModules() 或自动的模块注册表隔离来防止测试间污染。spyOn 和 jest.fn() 有什么区别？jest.fn() 创建全新的模拟函数，不保留原始实现jest.spyOn(object, method) 包装对象的现有方法，保留原始实现，可通过 .mockImplementation() 替换，用 .mockRestore() 恢复const spy = jest.spyOn(console, 'log').mockImplementation(() => {});// 测试结束后恢复spy.mockRestore();快照测试的局限是什么？快照可能过于宽泛，导致即使有 bug 也通过对比大型快照难以 review，容易盲目更新不适合频繁变更的 UI 或动态数据最佳实践：保持快照小而精确，使用 toMatchSnapshot 配合自定义匹配器。与其他框架对比| 特性 | Jest | Mocha | Vitest ||------|------|-------|--------|| 配置 | 零配置 | 需搭配 chai/sinon/nyc | 兼容 Jest API，零配置 || 断言库 | 内置 | 需额外安装 | 内置 || Mock | 内置 | 需搭配 Sinon | 内置 || 快照测试 | 内置 | 需额外插件 | 内置 || 执行速度 | 快（并行） | 较慢 | 最快（ESM 原生） || ESM 支持 | 实验性 | 支持 | 原生支持 || 生态成熟度 | 最成熟 | 成熟 | 快速增长 |Vitest 是 Jest 的新兴替代，与 Vite 生态深度整合，在 ESM 原生支持和执行速度上有优势，但 Jest 的生态和社区资源仍然最为丰富。总结Jest 的核心优势在于"一站式"测试体验——内置断言、Mock、快照和覆盖率，零配置即可运行，并行执行保证速度。面试中需重点掌握 Mock 系统（jest.fn/jest.spyOn/jest.mock）、异步测试三种方式和快照测试原理。在新项目中如果使用 Vite，可以优先考虑 Vitest 作为替代。

为什么需要 Mock？在单元测试中，被测代码往往依赖外部模块（如 API 请求、数据库、第三方库）。直接调用这些依赖会导致测试变慢、不稳定、难以控制返回值。Jest 的 Mock 功能可以替换依赖的行为，让测试专注于被测逻辑本身。一、创建 Mock 函数jest.fn() 是创建 Mock 函数最基本的方式，它会生成一个空函数并记录所有调用信息：const mockFn = jest.fn();mockFn('hello');mockFn('world');console.log(mockFn.mock.calls);// [['hello'], ['world']]console.log(mockFn.mock.results);// [{ type: 'return', value: undefined }, { type: 'return', value: undefined }]mockFn.mock 对象包含三个关键属性：| 属性 | 说明 ||------|------|| mock.calls | 每次调用的参数列表 || mock.results | 每次调用的返回值 || mock.instances | 每次调用时的 this 值 |二、控制 Mock 返回值mockReturnValue — 固定返回值const getAge = jest.fn().mockReturnValue(25);console.log(getAge()); // 25console.log(getAge()); // 25（每次都返回相同值）mockReturnValueOnce — 一次性返回值const getRandom = jest.fn() .mockReturnValueOnce(1) .mockReturnValueOnce(2) .mockReturnValue(0);console.log(getRandom()); // 1console.log(getRandom()); // 2console.log(getRandom()); // 0（Once 用完后回落到 mockReturnValue）mockResolvedValue — 异步返回值const fetchUser = jest.fn().mockResolvedValue({ name: 'Alice' });// 在测试中使用 async/awaitconst user = await fetchUser(1);expect(user).toEqual({ name: 'Alice' });mockResolvedValueOnce 同理，仅生效一次。三、自定义 Mock 实现当需要根据参数动态返回不同值时，使用 mockImplementation：const calculate = jest.fn().mockImplementation((a, b) => a + b);expect(calculate(1, 2)).toBe(3);也可以在 jest.fn() 中直接传入实现：const greet = jest.fn(name => `Hello, ${name}!`);进阶用法 — 根据调用次数返回不同值：const fn = jest.fn() .mockImplementationOnce(() => 'first') .mockImplementationOnce(() => 'second') .mockImplementation(() => 'default');四、Mock 整个模块这是实际项目中最常用的场景 — 替换外部模块的导出：替换默认导出// api.jsexport default function fetchData() { return fetch('/api/data');}// __tests__/component.test.jsjest.mock('../api', () => ({ __esModule: true, default: jest.fn(() => Promise.resolve({ data: 'mocked' }))}));import fetchData from '../api';test('使用模拟的 API 数据', async () => { const result = await fetchData(); expect(result).toEqual({ data: 'mocked' });});替换命名导出// utils.jsexport function formatDate(date) { /* ... */ }export function parseJSON(str) { /* ... */ }// 仅 Mock formatDate，保留 parseJSON 原始实现（Partial Mock）jest.mock('../utils', () => ({ ...jest.requireActual('../utils'), formatDate: jest.fn(() => '2026-01-01')}));使用 __mocks__ 目录自动 Mock在模块同目录下创建 __mocks__/api.js：// __mocks__/api.jsexport default function fetchData() { return Promise.resolve({ data: 'from automock' });}测试文件只需声明 jest.mock('../api')，Jest 会自动查找 __mocks__ 目录。五、SpyOn — 监视真实函数jest.spyOn 在不替换原函数的情况下追踪调用，也可以按需 Mock：const math = { add: (a, b) => a + b,};test('spy 追踪调用但不改变行为', () => { const spy = jest.spyOn(math, 'add'); expect(math.add(1, 2)).toBe(3); // 原函数正常执行 expect(spy).toHaveBeenCalledWith(1, 2); // 同时记录了调用});test('spy 也可以临时替换实现', () => { jest.spyOn(math, 'add').mockReturnValue(999); expect(math.add(1, 2)).toBe(999); // 被替换了 math.add.mockRestore(); // 恢复原函数});六、常用断言| 断言 | 说明 ||------|------|| toHaveBeenCalled() | 至少被调用一次 || toHaveBeenCalledTimes(n) | 被调用了 n 次 || toHaveBeenCalledWith(...args) | 曾用指定参数调用 || toHaveBeenLastCalledWith(...args) | 最后一次调用的参数 || toHaveReturnedWith(value) | 曾返回指定值 || toHaveLastReturnedWith(value) | 最后一次返回的值 || toHaveReturnedTimes(n) | 成功返回了 n 次 |七、清理 Mock测试之间未清理的 Mock 会导致状态泄漏，务必在 afterEach 或 afterAll 中清理：afterEach(() => { jest.clearAllMocks(); // 清除所有 mock.calls、mock.results，但保留实现});afterAll(() => { jest.restoreAllMocks(); // 恢复所有 spyOn 的原始实现});| 方法 | 效果 ||------|------|| jest.clearAllMocks() | 清除调用记录，保留 mock 实现 || jest.resetAllMocks() | 清除调用记录 + 清除 mock 实现（恢复为空函数） || jest.restoreAllMocks() | 恢复 spyOn 的原始实现 |八、常见问题与最佳实践问题1：Mock 不生效jest.mock 会被提升（hoisted）到文件顶部，如果回调中使用了变量，该变量可能尚未定义。解决方案：// 错误 — mockFactory 尚未定义const mockFactory = () => jest.fn();jest.mock('../module', mockFactory);// 正确 — 使用动态函数jest.mock('../module', () => ({ myMethod: jest.fn()}));问题2：Timer Mock测试 setTimeout、setInterval 相关逻辑时：jest.useFakeTimers();test('延迟执行', () => { const callback = jest.fn(); setTimeout(callback, 1000); jest.advanceTimersByTime(1000); expect(callback).toHaveBeenCalled();});最佳实践Mock 外部依赖，不 Mock 被测代码本身 — 否则测试失去意义优先使用 spyOn 而非 jest.fn 替换 — 便于恢复原始行为每个测试前确保 Mock 状态干净 — 避免测试间相互影响Mock 的行为应尽量贴近真实 — 否则测试通过但代码可能在生产环境失败不要过度 Mock — 如果一个测试中 Mock 了超过 3 个依赖，考虑是否测试粒度不对

Jest 提供了四个生命周期钩子函数，用于在测试的不同阶段执行设置和清理操作。理解它们的执行时机和使用场景，是编写可靠测试的基础。四个钩子函数概览| 钩子 | 执行时机 | 典型用途 ||------|---------|---------|| beforeAll | 当前 describe 块所有测试运行前，仅执行一次 | 建立数据库连接、启动服务器 || afterAll | 当前 describe 块所有测试运行后，仅执行一次 | 关闭数据库连接、停止服务器 || beforeEach | 当前 describe 块每个测试运行前，每次都执行 | 重置状态、初始化数据 || afterEach | 当前 describe 块每个测试运行后，每次都执行 | 清除 Mock、还原定时器 |beforeAll 与 afterAll：一次性设置与清理beforeAll 适合需要一次投入成本的场景，避免在每个测试前重复执行：let db;beforeAll(async () => { db = await connectDatabase('test_db'); await db.createTables();});afterAll(async () => { await db.dropTables(); await db.close();});test('should insert user', async () => { await db.insert('users', { name: 'Alice' }); const users = await db.query('SELECT * FROM users'); expect(users).toHaveLength(1);});注意： beforeAll 中如果发生错误，该 describe 块内的所有测试都会失败。beforeEach 与 afterEach：逐测试隔离beforeEach 和 afterEach 保证每个测试在独立环境中运行，是测试隔离的核心手段：let users;beforeEach(() => { users = [{ id: 1, name: 'Alice' }];});afterEach(() => { jest.clearAllMocks(); jest.useRealTimers();});test('should add user', () => { users.push({ id: 2, name: 'Bob' }); expect(users).toHaveLength(2);});test('should not be affected by previous test', () => { // beforeEach 重置了 users，这里仍然是初始状态 expect(users).toHaveLength(1);});钩子的执行顺序当存在嵌套 describe 时，钩子按照从外到内的顺序执行 setup，从内到外的顺序执行 teardown：describe('Outer', () => { beforeAll(() => console.log('Outer beforeAll')); beforeEach(() => console.log('Outer beforeEach')); afterEach(() => console.log('Outer afterEach')); afterAll(() => console.log('Outer afterAll')); describe('Inner', () => { beforeAll(() => console.log('Inner beforeAll')); beforeEach(() => console.log('Inner beforeEach')); afterEach(() => console.log('Inner afterEach')); afterAll(() => console.log('Inner afterAll')); test('example', () => { console.log('--- test runs ---'); }); });});执行顺序输出：Outer beforeAllInner beforeAllOuter beforeEachInner beforeEach--- test runs ---Inner afterEachOuter afterEachInner afterAllOuter afterAll关键规则： 外层 beforeEach 先于内层执行，外层 afterEach 后于内层执行——这保证了内层可以依赖外层的设置，同时内层的清理不会影响外层。异步钩子钩子函数支持异步操作，三种写法均可：// 方式一：async/await（推荐）beforeAll(async () => { await initializeService();});// 方式二：返回 PromisebeforeAll(() => { return fetch('/api/setup').then(res => res.json());});// 方式三：单个参数 done 回调beforeAll((done) => { startServer(done);});如果异步钩子超时，可以设置自定义超时时间：beforeAll(async () => { await heavySetup();}, 30000); // 30 秒超时常见陷阱1. 在 beforeAll 中修改共享状态，在 afterEach 中忘记清理// 错误：beforeAll 修改了全局状态，但 afterAll 没有还原beforeAll(() => { process.env.NODE_ENV = 'test';});// 其他测试文件可能受到影响// 正确：配对使用 afterAll 还原beforeAll(() => { originalEnv = process.env.NODE_ENV; process.env.NODE_ENV = 'test';});afterAll(() => { process.env.NODE_ENV = originalEnv;});2. 混淆 beforeAll 和 beforeEach 的使用场景beforeAll：设置成本高、测试之间可共享（数据库连接、服务器启动）beforeEach：每个测试需要独立副本（状态重置、数据初始化）如果测试之间有依赖或顺序敏感，优先使用 beforeEach 保证隔离。3. 钩子中的错误导致测试全部跳过beforeAll 抛出错误时，该 describe 块内所有测试直接失败。如果部分初始化失败不应阻断所有测试，考虑将初始化移入 beforeEach 并做容错处理。最佳实践优先使用 beforeEach/afterEach 保证隔离，仅在设置成本确实很高时才用 beforeAllafterEach 中务必清理 Mock 和定时器：jest.clearAllMocks() + jest.useRealTimers()保持钩子函数简洁，复杂逻辑拆分为辅助函数配对使用：有 before 就有对应的 after，确保资源不泄漏避免在钩子间传递状态，每个测试应能独立运行

Cookie 和 Session 到底有什么区别？HTTP 协议是无状态的，服务器收到请求后没办法知道这个请求是谁发的。Cookie 和 Session 都是为了解决这个问题，但路子完全不同：Cookie 是服务器写给浏览器的一小段数据，浏览器每次请求自动带上，容量约 4KBSession 是服务器自己存的数据，通过一个 Session ID 跟浏览器对应起来，大小没限制两者的配合方式：服务端创建 Session，生成唯一的 Session ID，通过 Set-Cookie 响应头下发给浏览器；后续每次请求浏览器自动带着这个 Cookie，服务器拿 Session ID 去查对应的 Session 数据。一个容易混淆的点：Session ID 本身就是通过 Cookie 传递的，所以 Session 依赖 Cookie，但 Cookie 可以独立使用（比如存用户偏好、主题设置等）。Koa 里怎么读写 Cookie？Koa 内置了 Cookie 支持，不需要额外装中间件，直接用 ctx.cookies 就行。设置 Cookieapp.use(async (ctx) => { // 最简单的写法 ctx.cookies.set('name', 'value'); // 带完整选项 ctx.cookies.set('token', 'abc123', { maxAge: 86400000, // 有效期，单位毫秒，这里是一天 expires: new Date('2026-12-31'), // 过期时间点，和 maxAge 二选一 path: '/', // 生效路径，默认 / domain: '.example.com', // 生效域名 secure: true, // 只在 HTTPS 下传输 httpOnly: true, // JS 不能读，防 XSS sameSite: 'strict', // 同源才带，防 CSRF signed: true // 签名防篡改 }); ctx.body = 'Cookie 已设置';});几个选项容易踩坑：httpOnly: true 不是可选项，是必选项。没有它，一段 XSS 脚本就能用 document.cookie 把你的登录凭证偷走sameSite 有三个值：strict（最严，跨站一律不带）、lax（导航到目标站点的 GET 请求会带，是浏览器默认值）、none（都带，但必须配 secure: true）signed: true 依赖 app.keys，没设置 keys 会报错。签名防的是篡改，不是加密——签过名的 Cookie 值客户端仍然能解码看到读取 Cookieapp.use(async (ctx) => { const name = ctx.cookies.get('name'); ctx.body = `你好，${name}`;});设置了 signed: true 的 Cookie，ctx.cookies.get() 会自动校验签名。签名不对返回 undefined，不是报错——这一点要留意，调试时别以为是自己没存上。删除 Cookiectx.cookies.set('name', null, { maxAge: 0 });把 maxAge 设成 0 就行。有个细节：path 和 domain 必须跟设置时完全一致，否则浏览器匹配不到那个 Cookie，删除操作会静默失败。这个坑在本地调试时特别容易遇到——设置了 /api 路径的 Cookie，删除时没带路径，结果怎么也删不掉。Koa 中 Session 怎么用？Koa 核心不带 Session，需要装 koa-session 中间件。安装和基本配置npm install koa-sessionconst session = require('koa-session');// 必须先设置 keys，用于 Cookie 签名app.keys = ['some-secret-key'];app.use(session({ key: 'koa.sess', // Cookie 里存 Session ID 的字段名 maxAge: 86400000, // Session 有效期，毫秒 httpOnly: true, // JS 不可读 signed: true, // 签名防篡改 rolling: false, // 每次请求是否重置过期倒计时 renew: false // 快过期时是否自动续期}, app));app.keys 支持数组，用于密钥轮换：app.keys = ['new-key', 'old-key'];签名用第一个密钥，校验按顺序尝试。换密钥时把新密钥放前面、旧密钥保留一段时间，已有的 Session 不会突然失效。两个容易忽略的配置项：rolling: true -- 每次请求都刷新 Cookie 的过期时间，适合需要保持活跃会话的场景（比如后台管理系统），但会增加 Cookie 写入频率renew: true -- 只在 Session 快过期时自动续期，比 rolling 更轻量，是大多数场景的推荐选项读写 Session// 登录 —— 写入 Sessionapp.use(async (ctx) => { if (ctx.path === '/login' && ctx.method === 'POST') { const { username, password } = ctx.request.body; const user = await authenticate(username, password); if (user) { ctx.session.user = { id: user.id, name: user.name }; ctx.body = { message: '登录成功' }; } else { ctx.throw(401, '用户名或密码错误'); } }});// 受保护页面 —— 读取 Sessionapp.use(async (ctx) => { if (ctx.path === '/profile') { if (!ctx.session.user) { ctx.throw(401, '请先登录'); } ctx.body = `欢迎，${ctx.session.user.name}`; }});// 登出 —— 销毁 Sessionapp.use(async (ctx) => { if (ctx.path === '/logout') { ctx.session = null; ctx.body = '已登出'; }});销毁 Session 用 ctx.session = null 就够了，不需要逐个删属性。koa-session 会同时清掉服务端的 Session 数据和浏览器端的 Cookie。koa-session 默认把 Session 数据存在哪里？这是个关键问题：koa-session 默认把 Session 数据序列化后直接塞进 Cookie 里。也就是说，浏览器每次请求都带着完整的 Session 数据。这种默认行为有三个问题：4KB 上限 -- Cookie 有大小限制，Session 数据稍大就会被截断，而且报错不明显，容易排查半天才发现是 Cookie 溢出数据可读 -- 签名只防篡改，不防窥探。Session 数据只是 Base64 编码，浏览器开发者工具里一眼就能看到内容，敏感信息绝不能放进去带宽浪费 -- 每次请求都带着全量 Session 数据往返，用户量大了以后带宽开销不小开发阶段用默认配置图方便没问题，上线之前必须换外部存储。生产环境怎么用 Redis 存储 Session？为什么选 Redis纯内存操作，读写延迟在微秒级，Session 是高频读写场景，非常匹配原生支持 TTL 过期，和 Session 的生命周期管理天然吻合支持多实例共享，部署多个 Node 进程时只要连同一个 Redis 就行配置方式npm install koa-session ioredisconst session = require('koa-session');const Redis = require('ioredis');const redis = new Redis({ host: '127.0.0.1', port: 6379, password: 'your-password', db: 0});// koa-session 需要的 store 接口只有三个方法const redisStore = { async get(key) { const data = await redis.get(`session:${key}`); return data ? JSON.parse(data) : null; }, async set(key, sess, maxAge) { await redis.set(`session:${key}`, JSON.stringify(sess), 'EX', maxAge / 1000); }, async destroy(key) { await redis.del(`session:${key}`); }};app.use(session({ store: redisStore, key: 'koa.sess', maxAge: 86400000, httpOnly: true, signed: true}, app));配置 Redis 之后，Cookie 里只剩一个 Session ID，真正的数据全在 Redis 里。应用部署多个实例也没问题，只要连的是同一个 Redis 集群，Session 就能跨实例共享。几个生产环境的注意点：Redis 连接建议用连接池或集群模式，单点 Redis 挂了 Session 全丢key 的前缀（上面的 session:）按业务区分，避免和其他 Redis 数据冲突maxAge / 1000 是把毫秒转成秒，Redis 的 EX 参数单位是秒，这里容易写错其他存储方案除了 Redis，常见的还有：MongoDB -- 用 connect-mongo 之类的适配器，适合已经有 MongoDB 的项目，但性能不如 RedisMySQL -- 不推荐，关系型数据库做高频 Session 读写是大材小用，性能也跟不上Memcached -- 和 Redis 类似的内存缓存，但不如 Redis 生态完善，现在用的人少了怎么实现登录认证中间件？认证中间件的核心就是一件事：检查 Session 里有没有用户信息，没有就拦截。async function authRequired(ctx, next) { if (!ctx.session.user) { ctx.throw(401, '未登录'); } await next();}// 只对需要认证的路由生效router.get('/api/profile', authRequired, async (ctx) => { ctx.body = ctx.session.user;});router.get('/api/settings', authRequired, async (ctx) => { ctx.body = await getUserSettings(ctx.session.user.id);});中间件放在路由处理函数前面，没登录的请求在中间件层就打回去了，不会进业务逻辑。更完善的做法是加上角色校验：function roleRequired(...roles) { return async (ctx, next) => { if (!ctx.session.user) { ctx.throw(401, '未登录'); } if (!roles.includes(ctx.session.user.role)) { ctx.throw(403, '权限不足'); } await next(); };}router.delete('/api/users/:id', roleRequired('admin'), async (ctx) => { // 只有 admin 角色能访问});Session 和 JWT 该怎么选？两者不是非此即彼，但在不同场景下各有优势：| 对比维度 | Session | JWT ||---------|---------|-----|| 存储位置 | 服务端（内存/Redis） | 客户端（Cookie/Header） || 状态 | 有状态，服务端维护会话 | 无状态，服务端不存数据 || 水平扩展 | 需要共享存储（Redis） | 天然支持，哪里都能验 || 主动失效 | 删掉服务端 Session 就行 | 做不到，只能等过期 || 数据安全 | 数据在服务端，客户端看不到 | Payload 只是 Base64，谁都能解码 || 实现复杂度 | 需要维护存储和清理 | 签发即忘，但吊销很麻烦 |选型建议：传统 Web 应用（SSR） -- 用 Session。浏览器自动管理 Cookie，登出即失效，权限变更即时生效，开发体验最简单前后端分离 / API 服务 -- 用 JWT。无状态减少服务端压力，适合微服务架构，客户端自己存 token高安全要求 -- 两者结合：JWT 做接口认证（短期有效），关键操作再校验 Session（服务端可控）。银行、支付这类场景经常这么干一个常见误区：觉得 JWT 无状态就一定比 Session 好。实际上 JWT 做不到主动失效，一旦签发就无法撤回。如果你需要"踢人下线"或"立即撤销权限"的能力，Session 反而更合适。Cookie 和 Session 的安全防护有哪些要点？Cookie 安全清单httpOnly: true -- 必设项。没有这个，XSS 攻击能直接偷 Cookiesecure: true -- 生产环境必须开。确保 Cookie 只在 HTTPS 下传输，防止中间人窃听sameSite: 'strict' 或 'lax' -- 阻止跨站请求携带 Cookie，从源头防 CSRF。strict 最安全但可能影响从外链跳转的体验，lax 是较好的折中signed: true -- 签名防篡改，客户端改了 Cookie 值服务端能发现Cookie 前缀 -- __Host- 前缀强制 secure、不设 domain、path 为 /；__Secure- 前缀强制 secure。浏览器会自动执行这些约束，推荐用在敏感 Cookie 上Session 安全清单app.keys 用强随机字符串，至少 32 位，从环境变量读取，不要硬编码在代码里设置合理的 maxAge，不要设成永不过期。通常 1-7 天，根据业务调整登出必须 ctx.session = null 彻底销毁，别只删 ctx.session.user生产环境必须用 Redis 等外部存储，内存存储重启就丢，也没法跨进程共享Session Fixation 防护Session Fixation 攻击的原理是：攻击者获取一个有效的 Session ID，诱骗受害者使用这个 ID 登录，攻击者就能用同一个 Session ID 访问受害者的会话。防护方法：登录成功后重新生成 Session ID。app.use(async (ctx) => { if (ctx.path === '/login' && ctx.method === 'POST') { const user = await authenticate(ctx.request.body); if (user) { // 登录成功，先销毁旧 Session 再创建新的 ctx.session = null; ctx.session.user = { id: user.id, name: user.name }; // koa-session 会在响应时生成新的 Session ID ctx.body = { message: '登录成功' }; } }});其他防护措施限制同一账号的并发 Session 数量，防止 Session 被盗用后长期使用记录认证日志（登录 IP、时间、设备），异常行为可以及时发现实现登录失败次数限制和延迟，5 次失败后锁定 15 分钟，防暴力破解Session ID 要足够长且随机，用 crypto.randomBytes(32) 生成，避免被猜测或碰撞敏感操作（修改密码、绑定手机）要求重新验证身份，不要仅依赖已有 Session

Koa 洋葱模型到底是什么先看一个现象：在 Koa 里写三个中间件，控制台打印的顺序是 1-前置 → 2-前置 → 3-核心处理 → 2-后置 → 1-后置。请求像穿透洋葱一样从外层进到最里层，再从里层一层层返回——这就是"洋葱模型"的名字由来。这个机制不是 Koa 凭空发明的，它借鉴了 koa-compose 的函数组合思想，核心就一句话：每个中间件拿到 next 函数，调用它就进入下一层，await 它返回后就执行后置逻辑。执行流程拆解用一个最小可运行的例子说明：const Koa = require('koa');const app = new Koa();app.use(async (ctx, next) => { console.log('1-前置'); await next(); console.log('1-后置');});app.use(async (ctx, next) => { console.log('2-前置'); await next(); console.log('2-后置');});app.use(async (ctx) => { console.log('3-核心处理'); ctx.body = 'Hello Koa';});app.listen(3000);请求进来后，执行路径是这样的：进入第一个中间件，执行 console.log('1-前置')遇到 await next()，暂停当前中间件，进入第二个中间件执行 console.log('2-前置')，再遇到 await next()，进入第三个中间件第三个中间件没有调用 next，设置 ctx.body 后返回回到第二个中间件，执行 await next() 之后的 console.log('2-后置')回到第一个中间件，执行 console.log('1-后置')关键点在于 await next() 这一行。它不是简单的函数调用，而是一个 Promise——下一个中间件（以及它后续的所有中间件）全部执行完毕后，这个 Promise 才 resolve。所以 await 之后的代码天然就在所有下游中间件之后执行。compose 函数怎么实现的洋葱模型的本质是 koa-compose，核心代码不到 30 行：function compose(middleware) { return function (context, next) { let index = -1; function dispatch(i) { if (i <= index) return Promise.reject(new Error('next() called multiple times')); index = i; let fn = i === middleware.length ? next : middleware[i]; if (!fn) return Promise.resolve(); try { return Promise.resolve(fn(context, dispatch.bind(null, i + 1))); } catch (err) { return Promise.reject(err); } } return dispatch(0); };}dispatch(i) 取出第 i 个中间件，把 dispatch(i+1) 作为 next 传进去。每个中间件内部 await next() 就是 await dispatch(i+1)，递归调用下一层。当 i 等于 middleware.length 时，fn 为 next（外层传入的，通常为 undefined），递归终止。有一个容易忽略的细节：index 变量用来检测 next() 是否被调用了多次。同一个中间件里调用两次 next() 会抛错，因为第二次调用时 i <= index 成立。这是有意为之——多次调用 next() 会导致下游中间件重复执行，产生不可预期的行为。和 Express 中间件有什么区别Express 的中间件是线性的：调用 next() 之后，控制权交给下一个中间件，不会再回来。Koa 的洋葱模型让控制权"去了又回"，这是最根本的区别。// Express 风格app.use((req, res, next) => { console.log('前置'); next(); // 交出控制权，不再回来 console.log('这行也会执行，但响应可能已经发出');});// Koa 风格app.use(async (ctx, next) => { console.log('前置'); await next(); // 等下游全部完成，控制权回来 console.log('后置，此时可以修改响应');});这意味着在 Koa 里，后置逻辑可以可靠地操作响应——比如统一格式化返回值、记录响应日志、计算耗时。Express 里 next() 后面的代码虽然也能执行，但响应可能已经被下游发出了，再改就晚了。另一个区别是错误处理。Express 需要在中间件链末尾放一个四个参数的错误处理中间件 (err, req, res, next) => {}。Koa 只需要在最外层 try-catch：app.use(async (ctx, next) => { try { await next(); } catch (err) { ctx.status = err.status || 500; ctx.body = { error: err.message }; }});因为洋葱模型保证了外层中间件的后置逻辑一定会执行，所以 try-catch 能捕获到任何内层抛出的异常。实际项目中怎么用洋葱模型请求耗时统计app.use(async (ctx, next) => { const start = Date.now(); await next(); const ms = Date.now() - start; ctx.set('X-Response-Time', `${ms}ms`);});前置逻辑记录开始时间，后置逻辑计算差值并写入响应头。这是洋葱模型最直观的用法——前置做初始化，后置做收尾。统一错误处理app.use(async (ctx, next) => { try { await next(); } catch (err) { ctx.status = err.statusCode || 500; ctx.body = { code: ctx.status, message: err.message }; // 生产环境不暴露堆栈 if (process.env.NODE_ENV !== 'production') { ctx.body.stack = err.stack; } }});放在最外层，任何内层抛出的异常都会被捕获。不需要在每个路由里单独 try-catch。认证与权限控制app.use(async (ctx, next) => { const token = ctx.headers.authorization; if (!token) { ctx.throw(401, '未登录'); } try { ctx.state.user = jwt.verify(token.replace('Bearer ', ''), SECRET); } catch { ctx.throw(401, 'token 无效'); } await next();});如果认证失败，直接抛错不调用 next()，下游中间件不会执行。这是洋葱模型的另一个特性：中间件可以选择"截断"请求，不往下传。响应格式统一app.use(async (ctx, next) => { await next(); if (ctx.body && !ctx.body.code) { ctx.body = { code: 0, data: ctx.body, message: 'success' }; }});后置逻辑里检查 ctx.body，如果路由返回的是裸数据，就包装成统一格式。业务代码不需要关心响应结构。使用洋葱模型容易踩的坑忘记 await next()app.use(async (ctx, next) => { console.log('前置'); next(); // 忘记 await console.log('后置'); // 会立即执行，不等下游完成});next() 返回 Promise，不加 await 后置逻辑会立即执行，洋葱模型失效。更严重的是，如果下游中间件是异步操作（查数据库、调接口），后置逻辑执行时响应可能还没准备好。中间件顺序搞反洋葱模型里，先注册的中间件包裹在后注册的外面。所以日志和错误处理要放最前面，路由放最后面。顺序写反了，错误处理就捕获不到路由层的异常。在后置逻辑里修改请求有些开发者习惯在后置逻辑里继续操作 ctx.request，但此时请求已经处理完了，修改请求对象没有意义。后置逻辑应该只操作 ctx.response 或 ctx.body。洋葱模型适用于哪些场景不是所有场景都需要洋葱模型。如果你的应用只有简单的请求-响应，Express 的线性中间件更直观。洋葱模型的优势在于需要在请求前后都执行逻辑的场景：日志、计时、错误兜底、认证拦截、响应包装。中间件越多、前后置逻辑越复杂，洋葱模型的价值越大。理解洋葱模型的关键不是记住执行顺序，而是理解 await next() 是一个分界线——之前的代码在请求进入时执行，之后的代码在响应返回时执行。把握住这一点，写中间件就不会出错。

Kubernetes Ingress 是什么当你把一个 Web 应用部署到 Kubernetes 集群后，集群外部的用户怎么访问它？最直接的方式是用 Service 的 NodePort 或 LoadBalancer 类型暴露端口，但前者端口范围有限且不安全，后者每个 Service 都要占用一个云厂商的负载均衡器，成本很高。Ingress 就是解决这个问题的方案。它是一种 API 对象，在集群入口处统一管理 HTTP 和 HTTPS 路由规则，根据域名和路径把流量分发到不同的 Service。你可以把它理解成集群的"前台接待"——所有外部请求先到 Ingress，再由它根据规则转给对应的后端服务。Ingress 能做的事情包括：基于域名的路由：api.example.com 走 A 服务，web.example.com 走 B 服务，共享同一个入口 IP基于路径的路由：example.com/api 走后端 API 服务，example.com/app 走前端服务TLS 终止：在 Ingress 层处理 HTTPS 握手，后端 Service 只需跑 HTTP，证书管理集中化路径重写：把 /v2/api 重写为 /api 再转发给后端负载均衡：在多个 Pod 副本之间分发请求一个请求从到达到转发的完整链路理解 Ingress 工作方式的关键是搞清楚请求的完整路径：外部客户端发送请求到 https://api.example.com/usersDNS 将域名解析到 Ingress Controller 暴露的 IP（通常是一个 LoadBalancer Service）请求到达 Ingress Controller，Controller 检查 TLS 证书完成 HTTPS 握手Controller 根据 Host 头和路径匹配 Ingress 规则，找到对应的 ServiceController 将请求转发给 Service 关联的某个 Pod（通过 Endpoints 列表）Pod 处理请求并返回响应注意：Ingress 资源本身只是规则定义，真正干活的是 Ingress Controller。没有 Controller，Ingress 规则就是一纸空文。Ingress Controller 选型Ingress Controller 是 Ingress 功能的实际执行者，它监听集群中 Ingress 资源的变化，动态更新自己的配置（比如 NGINX 的 upstream 配置），然后按照规则转发流量。NGINX Ingress Controller社区使用最广泛的方案，基于 NGINX/OpenResty 实现。功能成熟、社区活跃、文档齐全，支持限流、认证、CORS、自定义错误页、灰度发布等高级特性。如果你没有特殊需求，选它基本不会出错。Traefik云原生设计，原生支持自动服务发现和 Let's Encrypt 自动证书申请，配置方式比 NGINX 更直观（支持文件和 CRD 两种 provider）。适合追求配置简洁和自动化的团队。HAProxy Ingress基于 HAProxy 实现，强项是高性能和丰富的负载均衡算法（加权轮询、最少连接、一致性哈希等）。对性能有极致要求时可以考虑。Istio Gateway服务网格方案中的入口网关，除了基本路由还支持 mTLS、流量镜像、故障注入、熔断等服务网格能力。如果集群已经用了 Istio，直接用它就够了，不需要再额外部署 Ingress Controller。AWS ALB Ingress Controller专为 AWS 设计，直接创建 ALB 资源作为入口，和 AWS 的 WAF、ACM 证书、CloudWatch 等服务深度集成。纯 AWS 环境下的首选。Ingress 资源配置实战最基本的路由规则下面这个示例把 example.com/app1 和 example.com/app2 分别路由到两个不同的 Service：apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: simple-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: /spec: rules: - host: example.com http: paths: - path: /app1 pathType: Prefix backend: service: name: app1-service port: number: 80 - path: /app2 pathType: Prefix backend: service: name: app2-service port: number: 80pathType 是 v1 版本必须指定的字段，有三个可选值：Exact：精确匹配，只有路径完全一致才命中。/app 只匹配 /app，不匹配 /app/ 或 /app1Prefix：前缀匹配，按 / 分段进行前缀判断。/app 能匹配 /app、/app/、/app/user，但不匹配 /app1ImplementationSpecific：由 Controller 自行决定匹配逻辑配置 HTTPS（TLS 终止）要启用 HTTPS，需要先在集群中创建 TLS 证书的 Secret，然后在 Ingress 中引用：apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: tls-ingressspec: tls: - hosts: - secure.example.com secretName: tls-secret rules: - host: secure.example.com http: paths: - path: / pathType: Prefix backend: service: name: secure-service port: number: 80Ingress Controller 会在 443 端口处理 TLS 握手，解密后以 HTTP 转发给后端 Service，后端无需关心证书。默认后端（Default Backend）当请求没有匹配到任何规则时，Ingress Controller 会把流量发给默认后端。通常是一个返回 404 的简单服务：apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: default-backend-ingressspec: defaultBackend: service: name: default-service port: number: 80 rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80IngressClass：多 Controller 共存的关键一个集群中可能部署了多个 Ingress Controller（比如 NGINX 处理外部流量，Traefik 处理内部流量）。IngressClass 用来指定一个 Ingress 资源由哪个 Controller 处理：apiVersion: networking.k8s.io/v1kind: IngressClassmetadata: name: nginx-external annotations: ingressclass.kubernetes.io/is-default-class: "true"spec: controller: k8s.io/ingress-nginx---apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: my-ingressspec: ingressClassName: nginx-external rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: my-service port: number: 80标注 is-default-class: "true" 的 IngressClass 会被自动分配给没有指定 ingressClassName 的 Ingress 资源。常用 Annotations 配置Annotations 是 Ingress 的核心扩展机制，不同 Controller 支持不同的注解。以下是 NGINX Ingress Controller 最常用的几个：路径重写：把匹配到的路径部分替换后再转发nginx.ingress.kubernetes.io/rewrite-target: /$2强制 HTTPS 重定向：HTTP 请求自动跳转到 HTTPSnginx.ingress.kubernetes.io/ssl-redirect: "true"限流配置：限制每个客户端的请求频率和并发连接数nginx.ingress.kubernetes.io/limit-rps: "10"nginx.ingress.kubernetes.io/limit-connections: "5"CORS 跨域：前后端分离场景经常需要nginx.ingress.kubernetes.io/enable-cors: "true"nginx.ingress.kubernetes.io/cors-allow-origin: "https://example.com"Basic 认证：简单的访问控制nginx.ingress.kubernetes.io/auth-type: basicnginx.ingress.kubernetes.io/auth-secret: basic-auth自定义错误页面：统一展示 404、503 等错误页nginx.ingress.kubernetes.io/custom-http-errors: "404,503"Ingress 和 Service、LoadBalancer 的区别很多初学者容易混淆这三者的关系，这里做个明确对比。Ingress vs Service：Service 是四层（L4）负载均衡，基于端口和 IP 转发 TCP/UDP 流量，不关心请求内容。Ingress 是七层（L7）负载均衡，能识别 HTTP 的 Host 头和 URL 路径，做更精细的路由。Service 是必须的（Ingress 最终还是把流量转给 Service），Ingress 是可选的增强。Ingress vs LoadBalancer：LoadBalancer 类型的 Service 每个都占用一个云厂商负载均衡器，成本高且没有域名路由能力。Ingress 只需要一个 LoadBalancer（给 Ingress Controller 用），然后通过规则复用这个入口给多个 Service 使用。| 维度 | Ingress | Service (ClusterIP/NodePort) | Service (LoadBalancer) ||------|---------|------|------|| 层级 | L7 | L4 | L4 || 路由能力 | 域名 + 路径 | 端口 | 端口 || TLS 终止 | 支持 | 不支持 | 部分支持 || 成本 | 低（共享入口） | 低 | 高（每 Service 一个 LB） || 协议 | HTTP/HTTPS | TCP/UDP | TCP/UDP |部署 NGINX Ingress Controller用 Helm 安装是最快的方式：# 添加 Helm 仓库helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginxhelm repo update# 安装到独立命名空间helm install ingress-nginx ingress-nginx/ingress-nginx \ --namespace ingress-nginx \ --create-namespace安装完成后验证：kubectl get pods -n ingress-nginxkubectl get svc -n ingress-nginx如果看到 Service 有一个 EXTERNAL-IP（云环境）或 NodePort（本地环境），说明 Controller 已经就绪。生产环境的最佳实践命名空间隔离：把 Ingress Controller 部署在独立命名空间（如 ingress-nginx），和业务负载分开管理。资源限制：Ingress Controller 是集群流量的咽喉，必须设置合理的 CPU 和内存 requests/limits，避免被其他 Pod 抢占资源。监控告警：重点监控连接数、请求延迟、4xx/5xx 错误率、证书过期时间。Prometheus + Grafana 是主流方案。证书管理：生产环境推荐用 cert-manager 自动签发和续期 Let's Encrypt 证书，避免手动管理证书过期。健康检查：确保后端 Service 配置了正确的 readinessProbe，Ingress Controller 只会把流量发给就绪的 Pod。配置备份与版本管理：Ingress 规则属于基础设施即代码的一部分，应该用 Git 管理 YAML 文件，而不是直接 kubectl edit。灰度发布：利用 nginx.ingress.kubernetes.io/canary 系列注解实现金丝雀发布，按权重或 Header 把部分流量导向新版本。常见故障排查排查 Ingress 问题有一个清晰的思路：从外到内，逐层验证。第一层：Ingress 规则是否正确kubectl get ingresskubectl describe ingress <ingress-name>检查 Rules 中的 Host、Path、Backend 是否符合预期，特别注意 pathType 是否匹配。第二层：Controller 是否正常工作kubectl logs -n ingress-nginx <pod-name> --tail=100看日志中是否有配置加载错误或后端连接失败的记录。第三层：DNS 是否解析正确nslookup example.comdig example.com确认域名指向 Ingress Controller 的外部 IP。第四层：后端 Service 和 Pod 是否健康kubectl get svckubectl get endpoints <service-name>kubectl get pods -l app=<your-app>Endpoints 列表为空说明没有 Pod 通过了 readinessProbe，流量无处可去。第五层：TLS 证书是否有效kubectl get secret tls-secret -o yamlopenssl x509 -in <cert-file> -text -noout检查证书是否过期、域名是否匹配、Secret 是否在正确的命名空间。按照这个顺序逐层排查，绝大多数 Ingress 问题都能定位到原因。

Kubernetes Deployment 是用来管理无状态应用生命周期的核心控制器。它围绕 ReplicaSet 实现了声明式部署、滚动更新和版本回滚，是日常使用频率最高的 K8s 工作负载类型。Deployment 到底管什么Deployment 并不直接管理 Pod。它管理的是 ReplicaSet，再由 ReplicaSet 来确保 Pod 的副本数。这种两层结构是理解 Deployment 更新和回滚机制的关键——每次更新 Pod 模板，Deployment 都会创建一个新的 ReplicaSet，逐步把流量从旧 ReplicaSet 迁移到新 ReplicaSet。一个最小化的 Deployment 定义：apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deploymentspec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80注意 selector.matchLabels 必须和 template.metadata.labels 匹配，否则 Deployment 无法关联到自己的 Pod，这是一个常见的新手错误。滚动更新是怎么发生的当你修改了 Deployment 的 Pod 模板（比如换了镜像版本），Kubernetes 不会一次性替换所有 Pod，而是按策略逐步替换。默认使用 RollingUpdate 策略，整个过程依赖两个参数：maxUnavailable：更新过程中最多允许多少个 Pod 处于不可用状态。默认值是 25%，即 3 副本的 Deployment 最多允许 1 个 Pod 不可用。maxSurge：更新过程中最多允许超出期望副本数多少个 Pod。默认值也是 25%。以 3 副本为例，默认配置下的滚动更新过程大致如下：Kubernetes 先创建 1 个新 Pod（因为 maxSurge=25%，3 的 25% 向上取整为 1），等新 Pod 就绪后，再终止 1 个旧 Pod，如此循环直到全部替换完成。这里有一个容易忽略的细节：所谓"就绪"，依赖的是 readinessProbe。如果你没有配置 readinessProbe，Kubernetes 只要看到容器启动就认为 Pod ready，这可能导致流量打到还没准备好的新 Pod 上。生产环境中务必配置 readinessProbe。查看更新状态：kubectl rollout status deployment/nginx-deploymentRecreate 策略什么时候用除了 RollingUpdate，还有一种 Recreate 策略：先杀掉所有旧 Pod，再创建新 Pod。这会带来停机时间，看起来不如 RollingUpdate，但有些场景必须用它：应用不支持多版本同时运行（比如数据库 schema 变更后旧代码会报错）新旧版本共享的资源无法兼容（比如同一个 ConfigMap 被新旧版本以不同方式解析）设置方式：spec: strategy: type: Recreate选择策略时问自己一个问题：新旧 Pod 能不能同时对外服务？能就用 RollingUpdate，不能就用 Recreate。回滚机制的底层逻辑每次更新 Pod 模板，Deployment 都会创建一个新的 ReplicaSet，旧的 ReplicaSet 不会被删除，而是保留作为回滚的锚点。Kubernetes 用 revisionHistoryLimit 控制保留多少个旧 ReplicaSet，默认值是 10。查看更新历史：kubectl rollout history deployment/nginx-deployment回滚到上一版本：kubectl rollout undo deployment/nginx-deployment回滚到指定版本：kubectl rollout undo deployment/nginx-deployment --to-revision=2回滚的本质是什么？是把当前 Deployment 的 Pod 模板替换成目标 revision 对应的 ReplicaSet 的 Pod 模板，然后走一遍正常的滚动更新流程。所以回滚不是"魔法还原"，它和正向更新走的是同一条路径，同样受 maxUnavailable 和 maxSurge 约束。一个常见问题：如果你发现更新出错了，想暂停更新怎么办？kubectl rollout pause deployment/nginx-deployment暂停后可以做多次修改，确认没问题后再恢复：kubectl rollout resume deployment/nginx-deployment扩缩容：手动和自动手动扩缩容：kubectl scale deployment/nginx-deployment --replicas=5自动扩缩容需要 HPA（HorizontalPodAutoscaler）。HPA 根据 CPU、内存或自定义指标自动调整 Deployment 的副本数：apiVersion: autoscaling/v2kind: HorizontalPodAutoscalermetadata: name: nginx-hpaspec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx-deployment minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50需要注意的是，HPA 扩容是立刻生效的，但缩容有一个默认 5 分钟的稳定窗口（behavior.scaleDown.stabilizationWindowSeconds），防止指标波动导致副本数来回抖动。Deployment 和其他控制器的选择面试中常问的一个问题是：什么时候用 Deployment，什么时候用 StatefulSet 或 DaemonSet？Deployment 适用于无状态应用——Pod 之间没有差异，任何一个 Pod 都能处理任何请求。Web 服务、API 网关、微服务实例都属于这一类。StatefulSet 适用于有状态应用——每个 Pod 有稳定的网络标识和持久化存储。数据库主从集群、ZooKeeper、Kafka 集群需要用 StatefulSet。DaemonSet 确保每个节点上运行一个 Pod 副本，常用于日志采集、监控 Agent、网络插件等节点级服务。选错控制器的后果很直接：用 Deployment 跑数据库，Pod 重建后数据丢失；用 StatefulSet 跑无状态 Web 服务，滚动更新变慢且没有收益。生产环境中的几个注意点资源限制必须设置。没有 requests 和 limits 的 Pod 可能抢占节点资源，导致其他 Pod 被驱逐。至少设置 requests，让调度器能正确决策。健康检查不能省。livenessProbe 检测进程死锁，readinessProbe 控制流量接入。只配 livenessProbe 不配 readinessProbe，是导致滚动更新期间 502 的常见原因。不要用 latest 标签。image: nginx:latest 意味着每次拉取可能拿到不同版本，这会让 Deployment 的声明式管理失去意义。用明确的版本号，变更时改 YAML 走正常的更新流程。revisionHistoryLimit 不要设成 0。有些团队为了"清理资源"把它设成 0，结果是无法回滚。旧 ReplicaSet 里的 Pod 都是 0 副本，占用的资源微乎其微，保留回滚能力的收益远大于节省的那点开销。掌握了 Deployment 的滚动更新机制、回滚原理和与其他控制器的选型逻辑，面试中关于工作负载的大部分问题都能从容应对。

Kubernetes 是什么？Kubernetes（常缩写为 K8s）是一个开源的容器编排平台，用于自动化容器化应用的部署、扩展和运维管理。它最初由 Google 基于内部运行大规模容器的经验（Borg/Omega 系统）设计并开发，于 2014 年开源，随后成为 Cloud Native Computing Foundation（CNCF）的旗舰项目。简单来说，当你从"在一台机器上跑几个容器"发展到"在几百台机器上跑几千个容器，还要保证服务不中断、能自动扩缩容、出了故障能自愈"时，Kubernetes 就是解决这个问题的工具。核心概念详解Pod — 最小调度单元Pod 是 Kubernetes 中最小的可部署单元。一个 Pod 包含一个或多个紧密耦合的容器，它们共享网络命名空间（同一个 IP 地址和端口空间）和存储卷。大多数情况下，一个 Pod 只运行一个容器；多容器 Pod 的典型场景是 Sidecar 模式，比如主容器运行业务逻辑，Sidecar 容器负责日志收集或代理网络请求。apiVersion: v1kind: Podmetadata: name: my-appspec: containers: - name: app image: my-app:1.0 ports: - containerPort: 8080Node — 工作节点Node 是集群中实际运行工作负载的机器，可以是物理机或虚拟机。每个 Node 上运行着三个关键组件：kubelet：负责管理本 Node 上 Pod 的生命周期，向控制平面汇报状态kube-proxy：维护节点上的网络规则，实现 Service 的负载均衡容器运行时：实际运行容器的软件，如 containerd、CRI-OCluster — 集群Cluster 由一组 Node 组成，是 Kubernetes 管理的计算资源池。一个集群通常包含多个 Worker Node 和至少一个 Master Node（控制平面）。集群是 Kubernetes 运维的基本单元——所有的应用部署、资源分配、网络策略都在集群范围内定义和管理。Service — 服务发现与负载均衡Pod 的 IP 地址是临时的——每次 Pod 重建后 IP 都会变化。Service 通过标签选择器（Label Selector）匹配一组 Pod，并为它们提供一个稳定的虚拟 IP（ClusterIP）和 DNS 名称，解决了"如何找到一组随时可能变化的 Pod"这个问题。常见的 Service 类型：ClusterIP：默认类型，仅在集群内部可访问NodePort：通过每个 Node 的指定端口暴露服务LoadBalancer：向云厂商请求外部负载均衡器Deployment — 声明式应用管理Deployment 是最常用的工作负载控制器，它管理 ReplicaSet，而 ReplicaSet 管理 Pod 副本数量。你只需要声明"我需要 3 个副本运行 my-app:2.0 镜像"，Kubernetes 就会自动完成从旧版本到新版本的滚动更新，并且在更新出问题时支持一键回滚。apiVersion: apps/v1kind: Deploymentmetadata: name: my-appspec: replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: app image: my-app:2.0ConfigMap 与 Secret — 配置管理ConfigMap 用于存储非敏感的配置数据（如应用配置文件、环境变量），Secret 用于存储敏感信息（如数据库密码、TLS 证书）。将配置与镜像解耦后，同一份镜像可以在开发、测试、生产环境中复用，只需替换不同的 ConfigMap 和 Secret 即可。Namespace — 资源隔离Namespace 在同一个物理集群中划分出多个逻辑上的"虚拟集群"。不同 Namespace 下的资源名称可以重复，资源配额（ResourceQuota）和访问控制（RBAC）也可以按 Namespace 粒度设置。常见做法是为每个团队或每个环境（dev/staging/prod）创建独立的 Namespace。Kubernetes 的工作原理Kubernetes 采用经典的主从架构，分为控制平面（Control Plane）和数据平面（Worker Node）两部分。控制平面（Control Plane）控制平面是集群的"大脑"，负责全局决策和响应集群事件：kube-apiserver：集群的统一入口，所有组件之间的通信都通过 REST API 经由 apiserver 完成。它是唯一直接与 etcd 交互的组件。etcd：分布式键值存储，保存集群的全部状态数据。etcd 的数据就是集群的"唯一真相来源"（Single Source of Truth）。kube-scheduler：监听新创建且尚未被调度的 Pod，根据资源需求、亲和性规则、污点容忍等策略为 Pod 选择合适的 Node。kube-controller-manager：运行各种控制器（Deployment Controller、ReplicaSet Controller、Node Controller 等），通过控制循环不断将集群的当前状态向期望状态收敛。工作节点（Worker Node）工作节点是集群的"手脚"，负责实际运行业务容器：kubelet：在每个 Node 上运行的代理，接收 PodSpec 并确保容器按照规范运行，同时向 apiserver 汇报 Node 和 Pod 的状态。kube-proxy：在每个 Node 上维护网络规则（默认使用 iptables 或 IPVS 模式），实现 Service 到 Pod 的请求转发和负载均衡。容器运行时：负责拉取镜像、启动和停止容器。Kubernetes 通过 CRI（Container Runtime Interface）与运行时交互，不再直接依赖 Docker。一个请求的完整流程当你执行 kubectl apply -f deployment.yaml 时，发生了什么：kubectl 将 YAML 发送到 kube-apiserverapiserver 对请求进行认证、鉴权和准入控制后，将数据写入 etcdkube-scheduler 监听到未调度的 Pod，为其选择 Node 并将结果写回 etcd目标 Node 上的 kubelet 监听到有 Pod 分配给自己，调用容器运行时启动容器kube-controller-manager 不断监控实际副本数与期望副本数是否一致，如有偏差则创建或删除 Pod这个"声明式 + 控制循环"的设计思想是 Kubernetes 最核心的理念——你只需要告诉它"我想要什么"，而不是"怎么做"。Kubernetes 的主要特性自动化部署和回滚：通过声明式配置实现滚动更新，支持按比例控制升级速度，出错时可一键回滚到上一版本服务发现和负载均衡：自动为 Service 分配 ClusterIP 和 DNS 记录，内置轮询式负载均衡自动扩缩容：Horizontal Pod Autoscaler（HPA）根据 CPU/内存使用率或自定义指标自动增减 Pod 副本数自愈能力：自动重启失败容器、替换无响应节点上的 Pod、杀死未通过健康检查的容器存储编排：通过 PV/PVC 机制自动挂载各种存储后端（本地磁盘、NFS、云盘等），无需关心底层实现配置和密钥管理：ConfigMap 和 Secret 将配置与镜像解耦，支持热更新而不需要重新构建镜像典型应用场景微服务架构：每个微服务独立部署为一个 Deployment，通过 Service 互相调用，配合 Istio 等 Service Mesh 实现流量治理CI/CD 流水线：利用 Kubernetes 的声明式特性，将构建、测试、部署全流程容器化，实现 GitOps 工作流批处理和定时任务：Job 和 CronJob 控制器支持一次性任务和定时调度任务机器学习训练：利用 GPU 调度、分布式训练框架（如 Kubeflow）在 Kubernetes 上运行大规模模型训练掌握 Kubernetes 的核心概念和工作原理，是理解整个云原生技术栈的基础。从 Pod 到 Deployment，从 Service 到 Namespace，每一个概念都对应着生产环境中真实存在的问题和解决方案。建议在学习理论的同时动手搭建一个多节点集群，用 kubectl 完成一次完整的部署、扩容和滚动更新，这样对这些概念的理解才会从"知道"变成"会用"。

Kubernetes 集群中并非所有节点都一样——有的挂了 GPU，有的专门跑监控组件，有的正在维护。如何让 Pod "知道"哪些节点该避开、哪些节点可以进入？答案就是污点（Taints）和容忍度（Tolerations）。这对机制从节点侧和 Pod 侧分别控制调度行为，是 Kubernetes 调度体系中不可绕过的一环。污点是什么——节点说"别来"污点是打在节点上的标记，告诉调度器："除非 Pod 明确声明能容忍我，否则别往这儿调度。"一个完整的污点由三部分组成：Key：污点的键，必填。比如 dedicated、node-role.kubernetes.io/masterValue：污点的值，选填。比如 gpu、control-planeEffect：污点生效的方式，必填。决定"不匹配时怎么办"三种 Effect 的区别这是面试中最常被追问的细节，三种 Effect 行为差异很大：NoSchedule——硬性拒绝新 Pod 调度到该节点，但已经在跑的 Pod 不受影响。这是最常见的用法，典型场景是为专用节点（GPU、Ingress）加锁：没写容忍度的 Pod 根本进不来。PreferNoSchedule——软性偏好，调度器会尽量避开，但如果集群资源紧张，还是可能把 Pod 放过来。适合那种"最好别来，但来了也行"的场景，比如想让某节点尽量只跑日志采集组件，但不强制。NoExecute——最严厉的一种。不仅阻止新 Pod 调度进来，还会把已经在跑但没有匹配容忍度的 Pod 驱逐走。这是唯一会"赶人"的 Effect，通常用于节点故障或维护场景。Kubernetes 控制面默认用这种 Effect 处理 NotReady 和 Unreachable 节点。污点的增删查添加污点用 kubectl taint：# 给 node1 添加 NoSchedule 污点kubectl taint nodes node1 dedicated=gpu:NoSchedule# 没有值的污点也可以kubectl taint nodes node1 special:NoSchedule查看节点的污点：# 查看单个节点kubectl describe node node1 | grep Taints# 列出所有节点的污点kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints删除污点时在键后面加减号：# 删除指定污点kubectl taint nodes node1 dedicated=gpu:NoSchedule-# 删除该键下所有 Effectkubectl taint nodes node1 dedicated-容忍度是什么——Pod 说"我能进"容忍度写在 Pod 的 spec.tolerations 里，告诉调度器："这个污点我能接受，可以调度到对应节点。"容忍度的字段一个容忍度包含以下字段：| 字段 | 说明 | 是否必填 ||------|------|----------|| key | 要容忍的污点键 | 否，为空时匹配所有键 || operator | Equal 或 Exists | 否，默认 Equal || value | 污点的值 | Equal 时必填 || effect | 污点的 Effect | 否，为空时匹配所有 Effect || tolerationSeconds | 容忍多久后被驱逐 | 仅 NoExecute 有效 |两种 Operator 的匹配逻辑Equal——精确匹配，key、value、effect 三者都要对上才算匹配成功：tolerations:- key: "dedicated" operator: "Equal" value: "gpu" effect: "NoSchedule"这条容忍度只能匹配 dedicated=gpu:NoSchedule 这一个污点，少一个字段都不行。Exists——只检查 key 是否存在，不关心 value 是什么：tolerations:- key: "dedicated" operator: "Exists" effect: "NoSchedule"这条能匹配 dedicated=gpu:NoSchedule、dedicated=cpu:NoSchedule 等所有 key 为 dedicated 且 effect 为 NoSchedule 的污点。两个极端写法也值得记住：operator: "Exists" 且不写 key，匹配一切污点；只写 operator: "Exists" 连 effect 也不写，匹配所有污点的所有 Effect。tolerationSeconds 的作用这个字段只对 NoExecute 生效。假设节点出了问题被自动打上污点，Pod 不会立刻被驱逐，而是等 tolerationSeconds 秒后再驱逐。这给应用留了缓冲时间做优雅退出：tolerations:- key: "node.kubernetes.io/not-ready" operator: "Exists" effect: "NoExecute" tolerationSeconds: 300 # 节点 NotReady 后等 5 分钟再驱逐如果不设置 tolerationSeconds，Pod 会一直容忍该污点，不会被驱逐。匹配规则：调度器怎么判断调度器的匹配逻辑可以简化为三步：取出节点上所有污点逐个检查 Pod 的容忍度能否匹配每个污点（忽略能匹配的）剩下未匹配的污点中，如果有 NoSchedule 或 PreferNoSchedule，影响调度决策；如果有 NoExecute，直接驱逐几个容易混淆的边界情况：容忍度的 key 为空且 operator 为 Exists，匹配所有污点（包括后面新增的）容忍度的 effect 为空，匹配该 key 下的所有 Effect多个污点之间是"与"的关系：Pod 必须容忍节点的所有污点才能被调度，容忍一个不够控制面自动添加的污点Kubernetes 控制面会在特定条件下自动给节点打污点，这些污点是内置的，了解它们对排查调度问题至关重要：| 污点键 | Effect | 触发条件 ||--------|--------|----------|| node.kubernetes.io/not-ready | NoExecute | 节点 NotReady || node.kubernetes.io/unreachable | NoExecute | 节点不可达 || node.kubernetes.io/memory-pressure | NoSchedule | 节点内存压力 || node.kubernetes.io/disk-pressure | NoSchedule | 节点磁盘压力 || node.kubernetes.io/pid-pressure | NoSchedule | PID 资源不足 || node.kubernetes.io/network-unavailable | NoSchedule | 节点网络不可用 || node.kubernetes.io/unschedulable | NoSchedule | 节点被 cordon |Kubernetes 还默认为 Pod 添加了对 not-ready 和 unreachable 的容忍度，tolerationSeconds 为 300 秒。这就是为什么节点故障后 Pod 不会立刻被驱逐，而是等 5 分钟。这个默认行为可以通过在 Pod 中显式声明容忍度来覆盖。实战场景专用节点隔离集群里有几台 GPU 机器，只想让需要 GPU 的 Pod 调度上去，普通 Pod 不要占位置。做法是给 GPU 节点打污点，给 GPU Pod 加容忍度：# 节点侧kubectl taint nodes gpu-node dedicated=gpu:NoSchedule# Pod 侧spec: tolerations: - key: "dedicated" operator: "Equal" value: "gpu" effect: "NoSchedule" containers: - name: gpu-app image: nvidia/cuda:11.0.3-base-ubuntu20.04但注意，只加容忍度只能让 Pod "可以进"，不能保证 Pod "一定进"。如果要让 GPU Pod 只调度到 GPU 节点，还需要配合 nodeAffinity 或 nodeSelector 一起使用。污点是"拒绝"机制，不是"吸引"机制。节点维护与驱逐需要对节点做内核升级，先标记为不可调度并驱逐工作负载：# cordon 阻止新 Pod 调度kubectl cordon node1# drain 驱逐现有 Pod（忽略 DaemonSet）kubectl drain node1 --ignore-daemonsets --delete-emptydir-datakubectl drain 的本质就是给节点加 node.kubernetes.io/unschedulable:NoSchedule 污点，然后驱逐所有不匹配的 Pod。DaemonSet 的 Pod 默认带有对这些污点的容忍度，所以 drain 不会驱逐它们。DaemonSet 为什么不怕污点DaemonSet 控制器会自动为管理的 Pod 添加以下容忍度：tolerations:- key: "node.kubernetes.io/not-ready" operator: "Exists" effect: "NoExecute"- key: "node.kubernetes.io/unreachable" operator: "Exists" effect: "NoExecute"- key: "node.kubernetes.io/disk-pressure" operator: "Exists" effect: "NoSchedule"- key: "node.kubernetes.io/memory-pressure" operator: "Exists" effect: "NoSchedule"# ... 还有更多这就是为什么日志采集、监控 Agent 这类 DaemonSet 的 Pod 在节点出问题时仍然留在节点上——它们天生容忍这些污点。污点容忍度与节点亲和性的配合污点和亲和性解决的是不同方向的问题：污点：从节点出发，"我不想要谁"亲和性：从 Pod 出出发，"我想去哪里"两者配合才能实现完整的调度控制。一个常见模式是：污点把不该来的 Pod 挡在外面，亲和性把该来的 Pod 拉到正确位置。比如 GPU 场景——污点阻止普通 Pod，亲和性确保 GPU Pod 优先去 GPU 节点。单独使用污点有一个隐患：Pod 加了容忍度后能进节点，但不一定只进这个节点。它可能被调度到任何有匹配容忍度的节点。所以污点适合"排他"，亲和性适合"定向"，两者结合才是完整方案。TaintBasedEviction 机制当节点进入 NotReady 或 Unreachable 状态时，Kubernetes 不是立刻驱逐 Pod，而是基于 TaintBasedEviction 机制工作：节点控制器检测到节点异常，给节点打上对应污点Pod 上的容忍度开始倒计时（tolerationSeconds）倒计时结束，Pod 被标记为驱逐驱逐由 kubelet 执行优雅终止这个机制比旧版的基于 NodeCondition 的驱逐更灵活，因为你可以为不同的 Pod 设置不同的容忍时间。关键服务给较长缓冲，非关键服务快速驱逐。排查调度问题的思路Pod 调度失败时，按这个顺序排查：# 1. 查看 Pod 的调度失败事件kubectl describe pod <pod-name> | grep -A 20 Events# 2. 检查目标节点的污点kubectl describe node <node-name> | grep Taints# 3. 对比 Pod 的容忍度是否匹配kubectl get pod <pod-name> -o jsonpath='{.spec.tolerations}'# 4. 检查调度器日志kubectl logs -n kube-system -l component=kube-scheduler常见的调度失败提示比如 node(s) had taints that the pod didn't tolerate，说明 Pod 缺少对应污点的容忍度，要么给 Pod 加容忍度，要么去掉节点上的污点。污点和容忍度的核心思路就是"节点标记排斥，Pod 声明接受"。三种 Effect 的行为差异、控制面内置污点的触发条件、与亲和性的配合关系、以及 tolerationSeconds 带来的驱逐缓冲——这些是面试和实战中真正需要掌握的要点。理解了这套机制，就能在专用节点隔离、节点维护、故障处理这些场景下做出合理的调度决策。

MobX 生态中有两套不同的拦截与中间件机制：MobX 核心库的 intercept/observe，以及 MobX-State-Tree（MST）的 addMiddleware/onAction。面试中混淆两者是常见的扣分点。下面分别讲解它们的用法、区别和典型场景。核心库：intercept 和 observeintercept 和 observe 是 MobX 核心库提供的底层 API，直接作用于 observable 对象的属性变更。intercept：变更前拦截intercept(target, propertyName?, interceptor) 在变更作用于 observable 之前被调用，可以对变更进行修改、放行或取消。import { observable, intercept } from 'mobx';const store = observable({ count: 0, items: []});// 拦截 count 属性的变化const disposer = intercept(store, 'count', (change) => { // 1. 修改变更：不允许负数 if (change.newValue < 0) { change.newValue = 0; } // 2. 取消变更：超过上限直接返回 null if (change.newValue > 100) { return null; } // 3. 放行变更：返回 change 对象 return change;});store.count = 5; // 正常设置，count 变为 5store.count = -1; // 被修改，count 变为 0store.count = 200; // 被取消，count 保持不变disposer(); // 移除拦截器拦截器的返回值决定了变更的命运：返回 change 对象：放行变更修改 change 后返回：修改后放行（常用于数据规范化）返回 null：取消变更，对象不被修改抛出异常：阻止变更并向上传播错误拦截数组和 Mapintercept 也可以作用于 observable 数组和 Map，此时不需要指定属性名：import { observable, intercept } from 'mobx';const items = observable([1, 2, 3]);intercept(items, (change) => { if (change.type === 'add' && typeof change.newValue !== 'number') { throw new Error('只允许添加数字'); } return change;});const map = observable(new Map());intercept(map, (change) => { if (change.name === 'secret') { return null; // 禁止设置 secret 键 } return change;});observe：变更后观察observe(target, propertyName?, listener) 在变更已经生效之后被调用，适合做副作用处理（如日志、同步到外部系统）。import { observable, observe } from 'mobx';const store = observable({ count: 0 });const disposer = observe(store, 'count', (change) => { console.log(`count: ${change.oldValue} -> ${change.newValue}`);});store.count = 5; // 输出: count: 0 -> 5disposer();观察数组时的 change 对象包含 added、removed、index 等字段：const items = observable([1, 2, 3]);observe(items, (change) => { if (change.type === 'splice') { console.log('添加:', change.added, '移除:', change.removed); }});items.push(4); // 添加: [4] 移除: []不指定属性名时，可以观察对象所有属性的变化：observe(store, (change) => { console.log(`${change.name}: ${change.oldValue} -> ${change.newValue}`);});intercept 与 observe 的关键区别| 对比项 | intercept | observe ||--------|-----------|---------|| 触发时机 | 变更生效前 | 变更生效后 || 能否修改变更 | 可以 | 不可以 || 能否取消变更 | 可以（返回 null） | 不可以 || 典型用途 | 数据验证、格式化、权限控制 | 日志记录、副作用同步 |注意事项MobX 官方文档明确指出，intercept 和 observe 是底层工具，在实际项目中应谨慎使用。原因如下：observe 不遵循事务原则，在 action 中间可能触发多次两者都不支持深层级对象变化的监听滥用 intercept 容易创建难以调试的隐式数据流优先使用 reaction、autorun 或 when 来替代 observe；将数据验证逻辑放在 action 内部而不是 intercept 中。MobX-State-Tree：中间件体系MobX-State-Tree（MST）在 MobX 核心之上构建了更完善的中间件系统，通过 addMiddleware 和 onAction 提供 action 级别的拦截能力。addMiddleware：拦截 actionaddMiddleware 可以拦截子树上的任何 action 调用，并能修改参数、中止执行或替换返回值。import { addMiddleware, flow } from 'mobx-state-tree';const disposer = addMiddleware(store, (call, next) => { // call 包含: name, args, type, context, tree 等 console.log(`[Action] ${call.name} 被调用，参数:`, call.args); // 前置逻辑：验证参数 if (call.name === 'removeItem' && call.args[0] < 0) { return next({ ...call, args: [0] }); // 修改参数后传递 } // 调用 next 继续执行链 const result = next(call); // 后置逻辑：记录结果 console.log(`[Action] ${call.name} 完成，结果:`, result); return result;});中间件处理函数必须调用 next(call) 让 action 继续执行，或者通过返回值中止 action。不调用 next 会导致 action 被静默取消。onAction：监听 actiononAction 是一个内置的只读中间件，只能监听 action 的调用，不能拦截或修改。import { onAction } from 'mobx-state-tree';const disposer = onAction(store, (call) => { console.log(`Action ${call.name} 被调用，参数:`, call.args);});onAction 的参数以可序列化格式传递，适合用于：调试日志操作录制与重放（配合 applyAction）远程同步onAction 与 addMiddleware 的区别| 对比项 | addMiddleware | onAction ||--------|---------------|----------|| 能否拦截 action | 可以 | 不可以 || 能否修改参数 | 可以（克隆后修改） | 不可以 || 能否中止执行 | 可以（不调用 next） | 不可以 || 参数格式 | 原始参数 | 可序列化格式 || 典型用途 | 验证、权限控制、错误处理 | 日志、录制、调试 |中间件链的执行顺序多个中间件可以附加到同一个节点上，执行顺序遵循"由内到外"原则：同一对象上，先注册的中间件先执行子节点的中间件先于父节点的中间件执行每个中间件必须调用 next(call) 才能将控制权传递给下一个实战：典型应用场景数据验证与格式化用 intercept 在数据写入前进行校验和规范化：import { observable, intercept } from 'mobx';const form = observable({ email: '', age: 0});intercept(form, 'email', (change) => { if (change.newValue && !change.newValue.includes('@')) { return null; // 不写入无效邮箱 } return change;});intercept(form, 'age', (change) => { change.newValue = Math.max(0, Math.floor(change.newValue)); return change;});撤销/重做（Undo/Redo）利用 observe 记录变更历史，实现撤销和重做功能：import { observable, observe, action, makeAutoObservable } from 'mobx';class UndoManager { past = []; future = []; constructor(target) { this.target = target; makeAutoObservable(this); // 监听目标对象的属性变化 Object.keys(target).forEach((key) => { observe(target, key, (change) => { this.past.push({ key, oldValue: change.oldValue, newValue: change.newValue }); this.future = []; }); }); } @action undo() { if (this.past.length === 0) return; const entry = this.past.pop(); this.future.push(entry); this.target[entry.key] = entry.oldValue; } @action redo() { if (this.future.length === 0) return; const entry = this.future.pop(); this.past.push(entry); this.target[entry.key] = entry.newValue; } get canUndo() { return this.past.length > 0; } get canRedo() { return this.future.length > 0; }}MST 中间件：统一的错误处理在 MST 中用 addMiddleware 为所有 action 统一添加错误处理：import { addMiddleware } from 'mobx-state-tree';addMiddleware(store, (call, next) => { try { const result = next(call); // 异步 action 需要特殊处理 if (result && typeof result.then === 'function') { return result.catch((error) => { console.error(`[Error] ${call.name} 失败:`, error); store.setError(error.message); throw error; }); } return result; } catch (error) { console.error(`[Error] ${call.name} 失败:`, error); store.setError(error.message); throw error; }});MST 中间件：性能监控import { addMiddleware } from 'mobx-state-tree';const metrics = {};addMiddleware(store, (call, next) => { const start = performance.now(); const result = next(call); const duration = performance.now() - start; if (!metrics[call.name]) { metrics[call.name] = { count: 0, totalTime: 0, maxTime: 0 }; } const m = metrics[call.name]; m.count++; m.totalTime += duration; m.maxTime = Math.max(m.maxTime, duration); if (duration > 100) { console.warn(`[性能] ${call.name} 耗时 ${duration.toFixed(2)}ms`); } return result;});操作录制与重放利用 onAction 的可序列化特性，录制操作并在其他实例上重放：import { onAction, applyAction } from 'mobx-state-tree';// 录制端const recordedActions = [];onAction(sourceStore, (call) => { recordedActions.push(call);});// 重放端recordedActions.forEach((action) => { applyAction(targetStore, action);});这种模式在协作编辑、时间旅行调试和测试中非常有用。面试高频问题intercept 和 observe 的区别是什么？intercept 在变更生效前触发，可以修改或取消变更；observe 在变更生效后触发，只能被动接收。前者适合数据校验和格式化，后者适合日志和副作用同步。为什么 MobX 官方建议慎用 intercept 和 observe？因为 observe 不遵循事务原则，可能在一个 action 中间多次触发；两者都不支持深层级监听；滥用容易创建隐式的、难以调试的数据流。官方推荐使用 reaction、autorun 或 when 替代。MST 的 addMiddleware 和 onAction 有什么区别？addMiddleware 可以拦截、修改和中止 action，而 onAction 只能监听不能拦截。onAction 的参数以可序列化格式传递，适合录制和重放场景。MST 中间件链的执行顺序是什么？同一对象上先注册的中间件先执行，子节点中间件先于父节点中间件执行。每个中间件必须调用 next(call) 才能将控制权传递给下一个。如何选择使用哪种机制？需要拦截 observable 属性级别的变更：用核心库 intercept需要监听属性变更做副作用：优先用 reaction，其次 observe需要拦截 MST action 级别的调用：用 addMiddleware只需监听 MST action 调用：用 onAction需要数据验证：放在 action 逻辑内部，而非 intercept 中

Kubernetes 中 ConfigMap 和 Secret 都用于将配置与容器镜像解耦，但它们在数据性质、存储方式和安全机制上有本质区别。理解两者的差异并正确使用，是管理 K8s 应用配置的基本功，也是面试高频考点。ConfigMap 和 Secret 的核心区别是什么ConfigMap 存储非敏感的配置数据，比如应用端口号、日志级别、功能开关；Secret 专门存储密码、证书、Token 等敏感信息。这是最根本的划分原则——如果你犹豫某个值该放哪里，问自己一个问题：泄露后会不会出安全事故？会就放 Secret。两者在 API 层面的差异：编码方式：ConfigMap 的 data 字段存明文，Secret 的 data 字段存 Base64 编码。注意 Base64 只是编码不是加密，etcd 中 Secret 默认仍是明文存储，必须启用 EncryptionConfiguration 才能真正加密。访问控制：Secret 有更严格的 RBAC 建议策略，K8s 审计日志可以单独追踪 Secret 的访问记录。etcd 存储：开启加密后，Secret 在 etcd 中以密文保存；ConfigMap 始终明文。大小限制：两者单条都限制 1 MiB，超限需要拆分或引入外部配置中心。一个容易忽略的点：Secret 挂载到 Pod 后，kubelet 会将其写入 tmpfs（内存文件系统），Pod 删除后数据随之消失；而 ConfigMap 挂载的文件默认写入磁盘。怎样创建 ConfigMap实际项目中很少用命令行一条条创建，更多是通过 YAML 声明式管理，配合 GitOps 流程。以下覆盖常见的创建方式。从字面值创建，适合少量键值对：kubectl create configmap app-config \ --from-literal=LOG_LEVEL=info \ --from-literal=MAX_RETRIES=3从文件创建，适合将整个配置文件注入：kubectl create configmap nginx-config \ --from-file=nginx.conf=./nginx.conf从 YAML 声明创建，这是推荐的做法，便于版本管理和审计：apiVersion: v1kind: ConfigMapmetadata: name: app-configdata: LOG_LEVEL: "info" MAX_RETRIES: "3" application.yml: | server: port: 8080 spring: datasource: url: jdbc:mysql://mysql-svc:3306/mydb注意 ConfigMap 的 data 下所有值都是字符串类型。如果你写了 PORT: 8080，实际存储的是 "8080"，这在某些语言框架中可能引发类型解析问题。怎样在 Pod 中使用 ConfigMapConfigMap 有三种使用方式，选择哪种取决于配置的变更频率和消费方式。作为环境变量——适合少量、启动时确定的配置：spec: containers: - name: app image: my-app:latest env: - name: LOG_LEVEL valueFrom: configMapKeyRef: name: app-config key: LOG_LEVEL也可以一次性注入所有键值对：envFrom:- configMapRef: name: app-config注意 envFrom 会把 ConfigMap 的所有键注入环境变量，如果键名冲突会被后面的覆盖，要确认命名规范一致。挂载为卷——适合配置文件场景，如 Nginx 配置、Spring 的 application.yml：spec: containers: - name: app volumeMounts: - name: config-volume mountPath: /etc/app/config readOnly: true volumes: - name: config-volume configMap: name: app-config挂载为卷有一个重要特性：ConfigMap 更新后，挂载的文件会在几分钟内自动刷新（kubelet 的同步周期默认 60 秒 + 随机延迟）。但应用本身需要有能力感知文件变化并热加载，否则还是要滚动重启 Pod。作为命令行参数——在容器启动命令中引用环境变量：spec: containers: - name: app image: my-app:latest command: ["./app"] args: ["--log-level=$(LOG_LEVEL)"] env: - name: LOG_LEVEL valueFrom: configMapKeyRef: name: app-config key: LOG_LEVEL这种方式本质上还是环境变量，只是被 command/args 引用了。怎样创建 SecretSecret 的创建方式与 ConfigMap 类似，但有一个关键区别：data 字段的值必须 Base64 编码。apiVersion: v1kind: Secretmetadata: name: db-credentialstype: Opaquedata: username: YWRtaW4= # echo -n 'admin' | base64 password: c2VjcmV0MTIz # echo -n 'secret123' | base64如果你不想手动编码，可以用 stringData 字段，K8s 会自动帮你转 Base64：apiVersion: v1kind: Secretmetadata: name: db-credentialstype: OpaquestringData: username: admin password: secret123stringData 在写入 etcd 后会被转为 data 字段的 Base64 编码形式，所以通过 kubectl get -o yaml 看到的仍然是编码后的值。创建 TLS 类型的 Secret，用于 Ingress 或 Pod 的 HTTPS 配置：kubectl create secret tls tls-cert \ --cert=./tls.crt \ --key=./tls.key创建镜像拉取凭据：kubectl create secret docker-registry regcred \ --docker-server=registry.example.com \ --docker-username=user \ --docker-password=pass怎样在 Pod 中使用 Secret作为环境变量——最简单但要注意安全隐患：spec: containers: - name: app env: - name: DB_USERNAME valueFrom: secretKeyRef: name: db-credentials key: username环境变量方式的缺点：应用日志或调试输出可能意外打印敏感值；子进程会继承所有环境变量。如果对安全性要求高，优先用卷挂载。挂载为卷——推荐方式，Secret 以文件形式存在 tmpfs 中：spec: containers: - name: app volumeMounts: - name: secret-volume mountPath: /etc/secrets readOnly: true volumes: - name: secret-volume secret: secretName: db-credentials挂载方式的好处是应用可以按需读取，不会意外泄露到环境变量或日志中。imagePullSecrets——用于拉取私有镜像仓库：spec: imagePullSecrets: - name: regcred containers: - name: app image: registry.example.com/my-app:latestConfigMap 和 Secret 的更新机制有什么坑这是一个面试常考、实战也常踩的要点。ConfigMap/Secret 更新后，Pod 不会自动重启。对于 Deployment 管理的 Pod，你需要在模板中引用 ConfigMap/Secret 的某个标注（比如通过 subPath 或 env 注入资源版本号），触发滚动更新。否则新配置只会通过卷挂载的方式在 Pod 内部刷新文件内容。环境变量方式更加局限——容器的环境变量在启动时就固定了，ConfigMap 更新后，已经运行的 Pod 的环境变量不会变，必须重建 Pod 才能生效。还有一个容易忽略的坑：如果你用了 subPath 挂载 ConfigMap 或 Secret 的某个键，该文件不会随着 ConfigMap/Secret 更新而自动刷新，因为它脱离了符号链接的更新机制。immutable 不可变配置有什么用Kubernetes 1.21 起，ConfigMap 和 Secret 支持 immutable: true 字段：apiVersion: v1kind: ConfigMapmetadata: name: app-configimmutable: truedata: LOG_LEVEL: "info"标记为不可变后，无法修改 data 字段，只能删除重建。好处有两点：性能提升：kubelet 不需要 watch 不可变 ConfigMap/Secret，减轻了 API Server 和 kubelet 的负担。集群中 ConfigMap/Secret 数量多时效果明显。安全性：防止配置被意外或恶意篡改。生产环境中，如果配置在发布后确实不会变更，建议加上 immutable: true。Secret 的安全加固方案有哪些Base64 编码不等于加密，这是一个必须强调的事实。以下是生产环境中需要落实的安全措施。启用 etcd 加密——配置 EncryptionConfiguration，让 Secret 在 etcd 中以密文存储：apiVersion: apiserver.config.k8s.io/v1kind: EncryptionConfigurationresources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret: <base64-encoded-32-byte-key> - identity: {}配置 RBAC 最小权限——只授权必要的 Secret 访问：apiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: name: secret-readerrules:- apiGroups: [""] resources: ["secrets"] resourceNames: ["db-credentials"] verbs: ["get"]使用外部密钥管理系统——对于安全等级高的场景，引入 HashiCorp Vault、AWS Secrets Manager 或 Sealed Secrets 等：Vault Agent Injector：通过 Mutating Admission Webhook 自动将 Vault 中的密钥注入 PodExternal Secrets Operator：将外部密钥同步为 K8s SecretSealed Secrets：加密后可以安全地存储在 Git 中启用审计日志——追踪谁在什么时候访问了哪些 Secret：apiVersion: audit.k8s.io/v1kind: Policyrules:- level: RequestResponse resources: - group: "" resources: ["secrets"]定期轮换密钥——建立轮换机制，避免长期使用同一密钥。可以结合 CI/CD 流程在部署时自动更新 Secret。面试中如何回答 ConfigMap 和 Secret 的相关问题面试官问这个问题，通常不只是要你背概念，而是在考察你对 K8s 配置管理的整体理解。一个合格的回答应该涵盖以下层次：先说清楚本质区别：非敏感 vs 敏感，明文 vs Base64 编码，不同的安全机制再说实际使用：创建方式、三种消费方式（环境变量/卷挂载/命令行参数）及各自的适用场景然后说踩坑经验：更新机制的限制、环境变量不热更新、subPath 不自动刷新最后说安全加固：etcd 加密、RBAC 最小权限、外部密钥管理、审计日志如果你只答了第一层，面试官会认为你对 K8s 的理解停留在表面。能把第四层讲清楚，才能体现出生产环境的实战经验。

Koa 的错误处理和其他框架有什么不同？Koa 的错误处理设计跟 Express 有本质区别。Express 用中间件参数签名来区分普通中间件和错误处理中间件——四个参数 (err, req, res, next) 才是错误处理中间件。Koa 走了另一条路：它借助 async/await，让 try-catch 自然地包裹整个下游中间件链，配合洋葱模型实现错误冒泡。这意味着你只需要在洋葱模型的最外层放一个 try-catch，就能捕获所有内层抛出的错误。理解这一点，是写好 Koa 错误处理的前提。Koa 错误传播的原理是什么？Koa 的洋葱模型中，每个中间件都有机会在 await next() 之后执行逻辑。如果某个内层中间件抛出错误，这个错误会沿着调用栈向上冒泡，直到被某一层的 try-catch 捕获，或者到达框架顶层。关键细节：Koa 框架顶层有兜底逻辑。如果一个错误始终没被任何中间件捕获，Koa 会尝试返回 500，并触发 app.on('error') 事件。但如果响应头已经发送（ctx.headerSent 为 true），Koa 无法再修改状态码和响应体，只能把错误抛给 Node.js 的 unhandledRejection。这是实际开发中容易踩的坑——在流式响应场景中尤其要注意。如何用 ctx.throw 抛出标准 HTTP 错误？ctx.throw 是 Koa 提供的快捷方法，用于抛出带 HTTP 状态码的错误：app.use(async (ctx) => { if (!ctx.query.token) { ctx.throw(401, 'Token is required'); } ctx.body = 'Success';});ctx.throw 的第一个参数是状态码，第二个参数是错误消息。它内部会创建一个 HttpError 对象并抛出，这个对象携带 status、message 等属性，方便外层中间件统一处理。需要注意的是，ctx.throw 只支持 HTTP 标准状态码对应的错误。如果你需要携带自定义的业务错误码（比如 INVALID_PARAM），应该用自定义错误类代替 ctx.throw。怎么写错误处理中间件？错误处理中间件必须放在所有业务中间件之前，也就是洋葱模型的最外层。只有这样，内层所有中间件的错误才能被捕获：async function errorHandler(ctx, next) { try { await next(); } catch (err) { ctx.status = err.status || 500; if (ctx.app.env === 'development') { ctx.body = { error: err.message, stack: err.stack, code: err.code }; } else { ctx.body = { error: 'Internal Server Error', code: 'INTERNAL_ERROR' }; } ctx.app.emit('error', err, ctx); }}app.use(errorHandler);这段代码做了三件事：设置状态码、构建响应体、触发错误事件。开发环境返回堆栈信息方便调试，生产环境隐藏细节防止信息泄露。ctx.app.emit('error', err, ctx) 把错误转发给全局监听器，用于日志记录和监控上报。常见误区：有人把错误处理中间件放在路由中间件之后，这样它就无法捕获路由中抛出的错误——因为洋葱模型中，后注册的中间件在内层，内层的 try-catch 捕获不到外层已经抛出的错误。如何设计自定义错误类？ctx.throw 只能抛出 HTTP 标准错误，实际项目中往往需要更丰富的错误信息。自定义错误类可以携带业务错误码、错误详情等字段：class AppError extends Error { constructor(status, message, code) { super(message); this.status = status; this.code = code; this.name = 'AppError'; }}class NotFoundError extends AppError { constructor(message = 'Resource not found') { super(404, message, 'NOT_FOUND'); this.name = 'NotFoundError'; }}class ValidationError extends AppError { constructor(message = 'Validation failed') { super(400, message, 'VALIDATION_ERROR'); this.name = 'ValidationError'; }}class AuthError extends AppError { constructor(message = 'Authentication required') { super(401, message, 'AUTH_ERROR'); this.name = 'AuthError'; }}使用时直接抛出，错误处理中间件会自动识别 status 和 code：app.use(async (ctx) => { const user = await findUser(ctx.params.id); if (!user) { throw new NotFoundError('User not found'); } if (!user.isActive) { throw new AuthError('User account is deactivated'); } ctx.body = user;});设计自定义错误类时，建议让所有业务错误继承同一个基类 AppError，这样错误处理中间件可以通过 instanceof 判断错误类型，做差异化处理。全局错误事件怎么用？app.on('error') 是 Koa 的全局错误事件监听器。所有未被中间件完全处理的错误，以及中间件中手动 ctx.app.emit('error', err, ctx) 触发的错误，都会到达这里：app.on('error', (err, ctx) => { console.error(`[${new Date().toISOString()}] ${ctx.method} ${ctx.url}`); console.error(`Status: ${err.status || 500}, Code: ${err.code || 'UNKNOWN'}`); console.error(`Message: ${err.message}`); // 上报监控系统 monitoringService.report(err, ctx); // 严重错误发送告警 if (err.status >= 500) { alertService.send(err, ctx); }});全局错误事件的职责是日志记录、监控上报、告警通知。不要在这里修改 ctx 的响应——因为到了这一步，响应可能已经发出去了。响应格式化是错误处理中间件的事，全局监听只管记录。还有一个容易忽略的点：如果错误处理中间件捕获了错误并正常响应了客户端，但没有调用 ctx.app.emit('error')，这个错误就不会到达全局监听器。这意味着你需要做一个选择——哪些错误需要全局记录。通常建议：所有 500 及以上的错误都应该 emit 到全局，4xx 的客户端错误可以视情况决定。404 怎么处理？Koa 不会自动返回 404。如果一个请求没有匹配到任何路由，也没有任何中间件设置响应体，Koa 默认返回 404 状态码和 Not Found 纯文本。但在实际项目中，你通常需要返回统一格式的 JSON 响应：// 放在所有路由之后app.use(async (ctx) => { ctx.status = 404; ctx.body = { error: 'Not Found', code: 'NOT_FOUND', path: ctx.url };});这个中间件的原理是：如果前面的路由中间件已经处理了请求（设置了 ctx.body），Koa 不会再执行后续中间件。只有请求穿透了所有路由，才会落到这个兜底中间件。更优雅的做法是判断 ctx.status === 404 && !ctx.body，避免覆盖其他中间件故意设置的 404 响应。异步错误在 Koa 中怎么处理？Koa 基于 async/await，能自动捕获 async 函数中抛出的同步错误。但有些场景需要额外注意：// 直接 await — 错误会正常冒泡app.use(async (ctx) => { const data = await fetchData(); ctx.body = data;});// 未 await 的 Promise — 错误不会被捕获app.use(async (ctx) => { fetchData().then(data => { // 危险！如果 fetchData reject，错误不会冒泡 ctx.body = data; });});第二条规则：永远不要在 Koa 中间件里写 .then() 而不 await。未 await 的 Promise 如果 reject，错误会被吞掉，不会冒泡到错误处理中间件，也不会触发全局错误事件。这是 Node.js 中 unhandledRejection 的常见来源。对于第三方回调风格的异步操作，用 Promise 包装后再 await：const { promisify } = require('util');const readFile = promisify(fs.readFile);app.use(async (ctx) => { try { const content = await readFile(ctx.query.path, 'utf8'); ctx.body = content; } catch (err) { if (err.code === 'ENOENT') { throw new NotFoundError('File not found'); } throw err; }});数据库和第三方服务的错误怎么统一处理？数据库驱动抛出的错误通常有特定的错误码，需要转换成 HTTP 友好的格式。在错误处理中间件中针对不同错误类型做转换：app.use(async (ctx, next) => { try { await next(); } catch (err) { // PostgreSQL 唯一约束冲突 if (err.code === '23505') { ctx.throw(409, 'Resource already exists'); } // PostgreSQL 外键约束冲突 if (err.code === '23503') { ctx.throw(400, 'Invalid reference'); } // MongoDB 重复键 if (err.code === 11000) { ctx.throw(409, 'Duplicate key error'); } // JWT 过期 if (err.name === 'TokenExpiredError') { ctx.throw(401, 'Token expired'); } // 请求超时 if (err.code === 'ECONNABORTED' || err.code === 'ETIMEDOUT') { ctx.throw(504, 'Request timeout'); } throw err; }});这种做法把底层错误码翻译成 HTTP 语义，对客户端更友好。但要注意，这些转换逻辑不应该无限膨胀——如果某个数据库的错误码特别多，应该封装成专门的错误转换函数。一个完整的错误处理方案长什么样？把上面的各个部分组合起来，得到一个可用的完整方案：const Koa = require('koa');const app = new Koa();// 自定义错误类class AppError extends Error { constructor(status, message, code) { super(message); this.status = status; this.code = code; this.name = 'AppError'; }}class NotFoundError extends AppError { constructor(message = 'Resource not found') { super(404, message, 'NOT_FOUND'); }}class ValidationError extends AppError { constructor(message = 'Validation failed') { super(400, message, 'VALIDATION_ERROR'); }}// 错误处理中间件 — 放在最前面app.use(async (ctx, next) => { try { await next(); // 兜底 404 if (ctx.status === 404 && !ctx.body) { ctx.body = { error: 'Not Found', code: 'NOT_FOUND', path: ctx.url }; } } catch (err) { ctx.status = err.status || 500; const response = { error: err.message, code: err.code || 'INTERNAL_ERROR', timestamp: new Date().toISOString() }; if (app.env === 'development') { response.stack = err.stack; } ctx.body = response; ctx.app.emit('error', err, ctx); }});// 全局错误事件app.on('error', (err, ctx) => { console.error(`[${new Date().toISOString()}] ${ctx.method} ${ctx.url} - ${err.status || 500}`); if (err.status >= 500) { monitoringService.report(err, ctx); }});// 业务路由app.use(async (ctx) => { if (ctx.path === '/users/:id') { const user = await findUser(ctx.params.id); if (!user) throw new NotFoundError('User not found'); ctx.body = user; } ctx.body = { message: 'OK' };});app.listen(3000);这套方案覆盖了自定义错误类、错误处理中间件、全局事件监听、404 兜底、开发/生产环境差异化响应。把它作为项目模板，根据实际需求增减即可。写 Koa 错误处理，核心就是三件事：把错误处理中间件放在最前面，用自定义错误类统一错误格式，在全局事件中做好日志和监控。搞清洋葱模型中错误的传播方向，其他问题都好解决。

Koa 的 Context 对象是什么？Koa 的 Context 对象（即 ctx）是 Koa 框架中最核心的概念之一。它将 Node.js 原生的 request 和 response 对象封装到一个统一的对象中，并通过代理机制让开发者可以直接在 ctx 上访问请求和响应的属性，不必反复切换 req/res。理解 ctx，本质上就是理解 Koa 的设计哲学——用更少的代码完成更多的事情。ctx 的代理机制是怎么工作的？很多开发者只知道 ctx.query 能拿到查询参数，但并不清楚它为什么能直接用。实际上，ctx 上许多属性并不是自己定义的，而是通过 Object.defineProperty 代理到 ctx.request 和 ctx.response 上的。具体来说，当你访问 ctx.query 时，实际执行的是 ctx.request.query；当你设置 ctx.body 时，实际设置的是 ctx.response.body。这种代理机制的好处是减少了代码嵌套层级，让中间件的写法更加扁平。需要注意的一点是，并非所有 request/response 上的属性都被代理了。对于没有被代理的属性，你仍然需要通过 ctx.request.xxx 或 ctx.response.xxx 来访问。请求相关属性有哪些？ctx 提供了两组请求属性的访问方式：便捷访问和完整访问。便捷访问（直接通过 ctx）：ctx.url — 请求路径，包含查询字符串ctx.method — 请求方法（GET、POST 等）ctx.header — 请求头对象ctx.query — 解析后的查询字符串对象，例如 /api?name=koa 会得到 { name: 'koa' }ctx.path — 请求路径，不包含查询字符串ctx.host — 请求的主机名完整访问（通过 ctx.request）：ctx.request.querystring — 原始查询字符串（未解析），例如 name=koactx.request.search — 包含 ? 的原始查询字符串ctx.request.type — 请求的 Content-Typectx.request.accept — 客户端接受的内容类型ctx.request.ip — 客户端 IP 地址实际开发中，ctx.query 和 ctx.method 是使用频率最高的两个请求属性。获取请求体数据（ctx.request.body）则需要额外引入 koa-bodyparser 中间件，Koa 本身不内置 body 解析功能。app.use(async (ctx) => { // 获取查询参数 const { page, size } = ctx.query; // 获取请求方法和路径 console.log(ctx.method, ctx.path); // 获取客户端 IP const ip = ctx.request.ip;});响应相关属性有哪些？和请求类似，响应也有便捷访问和完整访问两种方式。便捷访问（直接通过 ctx）：ctx.body — 响应体，支持字符串、Buffer、Stream、Object（自动序列化为 JSON）ctx.status — HTTP 状态码ctx.type — 响应的 Content-Typectx.redirect(url) — 重定向到指定 URL完整访问（通过 ctx.response）：ctx.response.header — 响应头对象ctx.response.length — 响应 Content-Lengthctx.response.lastModified — Last-Modified 时间戳ctx.response.etag — ETag 值设置 ctx.body 时有一些细节值得注意：如果 body 是一个对象，Koa 会自动设置 Content-Type 为 application/json；如果 body 是字符串，则默认为 text/plain。你也可以通过 ctx.type 手动覆盖。app.use(async (ctx) => { // 返回 JSON ctx.body = { code: 0, data: { list: [] } }; // 返回 HTML ctx.type = 'html'; ctx.body = '<h1>Hello</h1>'; // 设置状态码后重定向 ctx.status = 302; ctx.redirect('/login');});ctx.state 有什么用？ctx.state 是 Koa 官方推荐的命名空间，用于在中间件之间传递数据。它的设计初衷是避免在 ctx 上随意挂载属性导致命名冲突。// 认证中间件app.use(async (ctx, next) => { const token = ctx.header.authorization; if (token) { ctx.state.user = verifyToken(token); // 将用户信息挂到 state 上 } await next();});// 业务中间件app.use(async (ctx) => { const user = ctx.state.user; // 从 state 取出用户信息 ctx.body = { name: user.name };});这个模式在实际项目中非常常见。除了用户信息，你还可以用它存储请求 ID、权限标识、分页参数等中间件间需要共享的数据。ctx.cookies 怎么操作？Koa 内置了 Cookie 操作能力，不需要额外安装中间件。ctx.cookies 提供了 get 和 set 两个方法。app.use(async (ctx) => { // 读取 Cookie const sessionId = ctx.cookies.get('sid'); // 设置 Cookie ctx.cookies.set('sid', 'abc123', { maxAge: 86400000, // 有效期 1 天，单位毫秒 httpOnly: true, // 禁止 JS 访问，防止 XSS secure: true, // 仅 HTTPS 传输 sameSite: 'lax', // 防止 CSRF });});设置 Cookie 时，httpOnly 和 sameSite 是两个安全相关的选项，生产环境中建议始终配置。maxAge 比 expires 更常用，因为它指定的是相对时间，不受时区影响。ctx.throw 和 ctx.assert 怎么用？Koa 提供了两种错误处理方式：ctx.throw() 和 ctx.assert()。ctx.throw() 用于主动抛出 HTTP 错误：app.use(async (ctx) => { const user = await findUser(ctx.query.id); if (!user) { ctx.throw(404, '用户不存在'); }});ctx.assert() 是 ctx.throw() 的断言封装，条件为 false 时抛出错误：app.use(async (ctx) => { ctx.assert(ctx.query.id, 400, '缺少用户 ID'); ctx.assert(ctx.state.user, 401, '未登录');});两种方式抛出的错误都会被 Koa 的错误事件捕获，你可以在 app.on('error') 中统一处理日志记录和监控上报。相比之下，ctx.assert() 的写法更简洁，适合做参数校验。ctx.app 是什么？ctx.app 是当前 Koa 应用实例的引用。通过它可以访问应用级别的配置和回调，比如 ctx.app.env 获取运行环境、ctx.app.proxy 判断是否信任代理头等。日常开发中用得不多，但在编写通用中间件时偶尔需要。ctx.req 和 ctx.res 与 ctx.request 和 ctx.response 有什么区别？这是初学者容易混淆的一对概念：ctx.req / ctx.res — Node.js 原生的 http 模块请求和响应对象，功能原始，不经过 Koa 封装ctx.request / ctx.response — Koa 封装后的对象，提供了更友好的 API除非你需要操作一些 Koa 没有封装的底层功能（比如 ctx.res.writeHead()），否则应始终优先使用 ctx.request 和 ctx.response。直接操作 ctx.res 可能会绕过 Koa 的中间件机制，导致响应处理逻辑失效。实际项目中的 ctx 使用模式了解了各个属性之后，更重要的是知道在实际项目中如何组织 ctx 的使用。以下是一个典型的中间件链中 ctx 的流转过程：const Koa = require('koa');const app = new Koa();// 请求日志中间件app.use(async (ctx, next) => { const start = Date.now(); await next(); const duration = Date.now() - start; console.log(`${ctx.method} ${ctx.url} - ${ctx.status} - ${duration}ms`);});// 认证中间件app.use(async (ctx, next) => { const token = ctx.header.authorization; ctx.assert(token, 401, '缺少认证信息'); ctx.state.user = verifyToken(token); await next();});// 业务路由app.use(async (ctx) => { const { page = 1, size = 10 } = ctx.query; const list = await getList(ctx.state.user.id, page, size); ctx.status = 200; ctx.body = { code: 0, data: { list, total: list.length } };});app.listen(3000);这个例子展示了 ctx 在整个请求生命周期中的角色：从日志中间件读取 method 和 url，到认证中间件校验 header 和写入 state，再到业务层读取 query 和设置 body，ctx 始终是贯穿所有中间件的数据枢纽。

Logstash 的强大之处在于它的插件体系——输入、过滤、输出三大类插件覆盖了从数据采集到写入目标的全链路。面试中经常问到"Logstash 有哪些常用插件""怎么安装和管理插件"，下面结合实际使用场景梳理清楚。Input 插件：数据从哪里来？Input 插件决定 Logstash 从哪个数据源读取数据。选对 Input 插件是搭建 Pipeline 的第一步。file —— 读日志文件file 是最基础的 Input 插件，行为类似 tail -f，持续读取文件新增内容：input { file { path => "/var/log/nginx/access.log" start_position => "beginning" sincedb_path => "/var/lib/logstash/sincedb" }}几个关键参数：start_position：首次读取时从文件开头（beginning）还是末尾（end）开始，默认 endsincedb_path：记录已读取位置的文件路径，重启后从断点续读；设为 /dev/null 则每次从头读mode：默认 tail 模式持续追踪，设为 read 则读完即退出beats —— 接收 Beats 数据Beats 是 Elastic 官方的轻量采集器家族（Filebeat、Metricbeat 等），beats 插件是 Logstash 与 Beats 配合的标准方式：input { beats { port => 5044 }}生产环境中，Beats 负责在各服务器上采集数据，再统一发送到 Logstash 做集中处理，这是 ELK 架构中最常见的组合。kafka —— 从 Kafka 消费消息当数据量大、需要缓冲或多个消费者协同工作时，Kafka 是首选的中间层：input { kafka { bootstrap_servers => "kafka-broker1:9092,kafka-broker2:9092" topics => ["app-logs", "business-events"] group_id => "logstash-consumer" consumer_threads => 4 }}其他常用 Input 插件| 插件 | 典型场景 ||------|---------|| jdbc | 定时从关系型数据库拉取增量数据 || http | 对外暴露 HTTP 接口，接收外部系统推送的数据 || tcp / udp | 接收网络协议数据，常用于收集 syslog || syslog | 专门解析 syslog 格式日志 || redis | 从 Redis List 或 Channel 读取数据 || elasticsearch | 从 ES 中查询数据做二次处理 || s3 | 从 AWS S3 桶读取归档日志 |Filter 插件：数据怎么加工？Filter 插件负责把非结构化的原始数据转换成结构化、可搜索的字段。这是 Logstash 最核心的能力。grok —— 解析非结构化日志grok 是使用频率最高的 Filter 插件，通过正则表达式模式把文本拆解成字段：filter { grok { match => { "message" => "%{IP:client_ip} %{WORD:method} %{URIPATH:request_uri} %{NUMBER:response_code:int} %{NUMBER:bytes:int}" } tag_on_failure => ["_grokparsefailure"] }}关键点：Logstash 内置了大量命名模式（如 IP、HOSTNAME、COMBINEDAPACHELOG），优先使用内置模式tag_on_failure：匹配失败时打上标签，方便后续排查未解析的日志性能瓶颈：grok 基于正则，匹配复杂模式时 CPU 开销大，大规模数据场景下可考虑用 dissect 替代mutate —— 字段操作mutate 用于对字段进行增删改查，是日常配置中使用最频繁的 Filter 之一：filter { mutate { rename => { "old_field" => "new_field" } remove_field => ["unused_field"] convert => { "response_code" => "integer" "latency" => "float" } gsub => [ "message", "\", "/" ] }}date —— 时间戳解析日志中的时间格式五花八门，date 插件负责将字符串时间解析为 Logstash 事件的时间戳：filter { date { match => ["log_time", "yyyy-MM-dd HH:mm:ss", "ISO8601"] target => "@timestamp" timezone => "Asia/Shanghai" }}注意：如果不确定时间格式，可以传多个模式数组，date 插件会依次尝试匹配。其他常用 Filter 插件| 插件 | 作用 ||------|------|| json | 解析 JSON 字符串为字段 || csv | 按分隔符拆分 CSV 格式数据 || geoip | 根据 IP 查询地理位置 || useragent | 解析浏览器 User-Agent || ruby | 用 Ruby 代码实现复杂逻辑（性能敏感场景慎用） || aggregate | 跨事件聚合，如关联同一个请求的多条日志 || dissect | 类似 grok 但基于固定分隔符，性能更好 || drop | 直接丢弃不需要的事件 || fingerprint | 给事件生成唯一标识 |Output 插件：数据送到哪里去？elasticsearch —— 写入 Elasticsearch这是最常用的 Output 插件，生产环境中几乎必用：output { elasticsearch { hosts => ["http://es-node1:9200", "http://es-node2:9200"] index => "app-logs-%{+YYYY.MM.dd}" template => "/etc/logstash/templates/es-template.json" action => "create" retry_on_conflict => 3 }}关键参数：index：支持按时间动态生成索引名，%{+YYYY.MM.dd} 按天分索引action：index（默认，覆盖写入）或 create（仅当文档不存在时写入，防止重复）retry_on_conflict：版本冲突时重试次数kafka —— 写入 Kafkaoutput { kafka { bootstrap_servers => "kafka-broker1:9092" topic_id => "processed-logs" codec => json compression_type => "snappy" }}其他常用 Output 插件| 插件 | 场景 ||------|------|| file | 写入本地文件 || http | 推送到外部 HTTP API || redis | 写入 Redis || stdout | 控制台输出，调试时常用 || email | 触发告警邮件 || s3 | 归档到 AWS S3 || mongodb | 写入 MongoDB |Codec 插件：数据的编解码Codec 插件常被忽略，但它影响着数据的序列化方式。常用的是 json 和 multiline：input { file { path => "/var/log/app.log" codec => multiline { pattern => "^%{TIMESTAMP_ISO8601}" negate => true what => "previous" } }}multiline 用于把 Java 堆栈信息等多行日志合并为一条事件，pattern 匹配新日志行的开头，what => "previous" 表示不匹配的行归入上一条事件。插件安装和管理Logstash 通过 bin/logstash-plugin 命令管理插件生命周期：查看已安装插件# 列出所有插件bin/logstash-plugin list# 带版本号bin/logstash-plugin list --verbose# 按分组查看bin/logstash-plugin list --group input# 模糊搜索bin/logstash-plugin list '*kafka*'安装插件# 从 RubyGems 安装bin/logstash-plugin install logstash-output-s3# 指定版本bin/logstash-plugin install logstash-output-s3 --version 10.0.0# 从本地 gem 文件安装bin/logstash-plugin install /path/to/logstash-output-custom-1.0.0.gem更新和卸载# 更新全部插件bin/logstash-plugin update# 更新指定插件bin/logstash-plugin update logstash-output-s3# 卸载插件（Logstash 7.x+ 中部分插件为集成插件，不可卸载）bin/logstash-plugin uninstall logstash-output-s3离线安装生产环境通常无法访问外网，需要制作离线安装包：# 在有网络的机器上生成离线包bin/logstash-plugin prepare-offline-pack logstash-output-s3# 在目标机器上安装bin/logstash-plugin install file:///path/to/logstash-offline-plugins.zip插件配置的实战经验条件判断让 Pipeline 更高效不同类型的日志走不同的 Filter 逻辑，避免无关插件浪费算力：filter { if [type] == "nginx-access" { grok { match => { "message" => "%{COMBINEDAPACHELOG}" } } geoip { source => "clientip" } } else if [type] == "app-error" { grok { match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:level} %{GREEDYDATA:msg}" } } if [level] == "ERROR" { mutate { add_field => { "alert" => "true" } } } }}grok 解析失败的兜底处理grok 匹配失败是线上常见问题，必须处理：filter { grok { match => { "message" => "%{PATTERN:field}" } tag_on_failure => ["_grokparsefailure"] } if "_grokparsefailure" in [tags] { mutate { add_field => { "parse_error" => "true" } } }}性能优化要点优先用 dissect 替代 grok：当日志格式固定时，dissect 基于分隔符拆分，性能比 grok 高出一个量级减少 mutate 调用次数：合并多个 mutate 操作到一个块内，减少事件反复处理慎用 ruby 插件：Ruby 代码执行效率远低于内置插件，只在无法用其他插件实现时才用合理配置 pipeline.workers 和 pipeline.batch.size：workers 数量通常设为 CPU 核心数，batch.size 根据事件大小调整（默认 125，大事件可适当调小）关注慢 Filter：在 logstash.yml 中开启 config.debug 和慢日志，定位瓶颈插件自定义插件开发当内置插件无法满足需求时（比如对接公司内部系统），就需要开发自定义插件。创建插件骨架gem install logstash-plugin-generatorlogstash-plugin generate --type input --name myinput生成的目录结构：logstash-input-myinput/├── lib/│ └── logstash/│ └── inputs/│ └── myinput.rb├── spec/│ └── inputs/│ └── myinput_spec.rb├── Gemfile├── logstash-input-myinput.gemspec└── README.md核心实现一个 Input 插件至少实现 register 和 run 两个方法：class LogStash::Inputs::Myinput < LogStash::Inputs::Base config_name "myinput" config :host, :validate => :string, :default => "0.0.0.0" config :port, :validate => :number, :required => true def register # 初始化资源，只在启动时调用一次 @server = TCPServer.new(@host, @port) end def run(queue) # 持续运行，产生事件后推入 queue loop do client = @server.accept while line = client.gets event = LogStash::Event.new("message" => line.chomp) decorate(event) queue << event end client.close end end def stop # 优雅关闭 @server.close if @server endend构建与安装gem build logstash-input-myinput.gemspecbin/logstash-plugin install logstash-input-myinput-1.0.0.gem编写测试require "logstash/devutils/rspec/spec_helper"require "logstash/inputs/myinput"describe LogStash::Inputs::Myinput do let(:config) { { "port" => 9999 } } it "registers without error" do input = described_class.new(config) expect { input.register }.not_to raise_error endend插件版本管理的注意事项集成插件不可卸载：Logstash 7.x 之后，Kafka、Beats 等常用插件被合并为集成插件（logstash-integration-kafka），无法通过 uninstall 移除锁定版本：在 Gemfile 中指定版本避免升级引入兼容问题：gem "logstash-output-s3", "~> 10.0"升级策略：bin/logstash-plugin update 默认只升级小版本和补丁版本，不会跨大版本升级，降低破坏性变更风险查看插件版本：bin/logstash-plugin list --verbose | grep 插件名掌握 Logstash 插件体系的关键在于理解 Input-Filter-Output 的数据流模型，以及每个插件在链路中的定位。日常使用中，grok 和 mutate 是最需要熟练掌握的 Filter 插件，elasticsearch output 是最核心的输出插件，而插件管理命令则保证你能灵活扩展和维护 Pipeline。

MariaDB 有哪些索引类型？各自的适用场景是什么？MariaDB 支持多种索引类型，理解它们的区别是做优化决策的基础。B-Tree 索引是 MariaDB 的默认索引结构，绝大多数场景下使用的都是它。B-Tree 采用平衡多路搜索树结构，叶子节点通过双向链表连接，天然支持等值查询、范围查询和排序操作。当你执行 WHERE id BETWEEN 100 AND 200 或 ORDER BY created_at DESC 时，B-Tree 可以高效地利用索引的有序性完成扫描，而不需要额外的文件排序（filesort）。哈希索引仅支持等值匹配查询，不支持范围查询和排序。它的查询时间复杂度接近 O(1)，在精确查找场景下比 B-Tree 更快。MariaDB 中哈希索引主要用于 MEMORY 存储引擎的表，InnoDB 的自适应哈希索引（Adaptive Hash Index）是引擎内部自动维护的，不需要手动创建。面试中如果被问到"哈希索引为什么不能用于范围查询"，核心原因是哈希值之间没有大小关系，无法利用有序性做区间扫描。全文索引（FULLTEXT）专门用于文本内容的模糊搜索，底层基于倒排索引实现。相比于 LIKE '%关键词%' 会导致全表扫描，全文索引可以快速定位包含目标词的记录。MariaDB 支持 MATCH ... AGAINST 语法，提供自然语言模式和布尔模式两种查询方式。需要注意的是，全文索引对中文分词的支持有限，通常需要借助 ngram 解析器或 Mroonga 引擎来处理中文场景。空间索引（SPATIAL）用于地理空间数据类型的索引，底层基于 R-Tree 结构。适合处理点、线、多边形等 GIS 数据的空间关系查询，比如"查找某坐标 5 公里范围内的门店"。空间索引仅支持 InnoDB 和 MyISAM 引擎，且索引列必须声明为 NOT NULL。聚簇索引不是一个独立的索引类型，而是 InnoDB 的数据组织方式。InnoDB 的主键索引就是聚簇索引——叶子节点直接存储完整的行数据，而非主键索引（二级索引）的叶子节点存储的是主键值。这意味着通过二级索引查找数据时，需要先查到主键值，再回表查询完整行数据，这个过程叫做"回表"。理解聚簇索引和回表机制，是掌握覆盖索引优化前提。创建索引时应该遵循哪些设计原则？索引不是越多越好。每多一个索引，INSERT/UPDATE/DELETE 就多一份维护成本，同时占用额外的磁盘空间。设计索引时需要把握几个关键原则。优先对高选择性列建索引。 选择性指的是列中不同值的数量与总行数的比值。选择性越高，索引过滤效果越好。例如用户表的 email 列选择性接近 1，几乎每条记录值都不同，索引过滤效率极高；而性别列只有两三个值，选择性极低，索引对查询的帮助微乎其微，优化器大概率会选择全表扫描。一个经验阈值是：当某值占比超过全表的 20% 时，优化器通常放弃使用索引。复合索引要遵循最左前缀原则。 对于索引 idx_abc(a, b, c)，查询条件用到了 a、(a,b)、(a,b,c) 都能命中索引，但只用 b 或 c 则无法使用。实际设计中，应该把等值查询的列放在前面，范围查询的列放在后面。例如 WHERE status = 1 AND created_at > '2024-01-01'，应建索引 (status, created_at) 而非 (created_at, status)，因为等值过滤在前可以大幅缩小范围查询的扫描区间。利用覆盖索引减少回表。 如果查询需要的所有列都包含在索引中，InnoDB 直接从索引返回数据，无需回表读取行记录。例如 SELECT id, name FROM users WHERE name = 'John'，如果 name 列上有索引且索引包含了 id（InnoDB 二级索引自动包含主键），这就是一次覆盖索引扫描。在 EXPLAIN 输出中，覆盖索引的 Extra 列会显示 Using index。避免在索引列上使用函数或表达式。 WHERE YEAR(created_at) = 2024 会导致索引失效，因为 MariaDB 需要对每一行计算函数值后才能比较。正确的写法是 WHERE created_at >= '2024-01-01' AND created_at < '2025-01-01'，这样优化器可以利用 B-Tree 的有序性做范围扫描。如何使用 EXPLAIN 分析查询的索引使用情况？EXPLAIN 是索引优化的核心工具，它展示优化器为查询选择的执行计划。EXPLAIN SELECT u.name, o.totalFROM users uJOIN orders o ON u.id = o.user_idWHERE u.status = 1 AND o.created_at > '2024-01-01';重点关注以下几个字段：type：访问类型，从好到差依次为 system > const > eq_ref > ref > range > index > ALL。出现 ALL 意味着全表扫描，需要重点优化。ref 表示使用索引等值匹配，range 表示索引范围扫描。key：实际使用的索引名称。如果显示 NULL，说明没有可用索引。rows：预估扫描行数。这个值越小越好，但它是基于统计信息的估算值，不一定精确。Extra：额外信息。Using index 表示覆盖索引，Using filesort 表示需要额外排序，Using temporary 表示使用了临时表，后两者通常意味着性能瓶颈。一个实用的工作流是：先跑 EXPLAIN 看执行计划，发现 type 为 ALL 或 rows 过大时，针对性地添加或调整索引，再反复验证。什么是索引失效？哪些常见写法会导致索引失效？索引失效指的是查询条件虽然涉及了索引列，但优化器最终选择不使用索引而做全表扫描。以下几种写法是常见的索引失效陷阱。对索引列使用函数或运算： WHERE name LIKE '%John'（左模糊）、WHERE YEAR(date_col) = 2024、WHERE id + 1 = 100，这些写法破坏了 B-Tree 的有序性，优化器无法利用索引定位。隐式类型转换： 当列是 VARCHAR 类型，查询条件写成 WHERE phone = 13800001111（数字类型），MariaDB 会将列值转为数字再做比较，这相当于对列施加了隐式函数，导致索引失效。正确写法是 WHERE phone = '13800001111'。OR 条件连接不同索引列： WHERE name = 'John' OR age = 25，如果 name 和 age 各有独立索引，MariaDB 在某些情况下可以使用 Index Merge 优化，但效果往往不如预期，不如改写为 UNION ALL 两个子查询。NOT IN、NOT EXISTS、!=、： 这些否定条件可能导致索引失效，尤其是结果集占比较大时。但并非绝对——如果否定条件过滤性很强（排除的值很少），优化器仍可能选择索引。索引列 IS NULL： 在 MariaDB 中，B-Tree 索引是包含 NULL 值的，WHERE col IS NULL 可以使用索引。这一点与 Oracle 等数据库不同，面试中注意区分。如何通过覆盖索引和索引下推提升查询性能？覆盖索引在前文已经提到，核心思路是让查询所需的所有列都在索引中，从而避免回表。实际应用中，可以通过 SELECT 指定列或将常用查询列加入复合索引来实现。-- 订单列表查询，只需要 id、status、created_atSELECT id, status, created_at FROM orders WHERE user_id = 100;-- 建立覆盖索引 (user_id, status, created_at)-- InnoDB 二级索引自动包含主键 id，因此这三列 + id 都在索引中ALTER TABLE orders ADD INDEX idx_user_status_created(user_id, status, created_at);索引下推（Index Condition Pushdown，ICP） 是 MariaDB 5.6+ 引入的优化。传统流程中，二级索引查到主键后必须回表才能判断 WHERE 中的其他条件；启用 ICP 后，存储引擎在索引扫描阶段就根据 WHERE 条件过滤，减少回表次数。-- 假设有索引 (last_name, first_name)SELECT * FROM users WHERE last_name = 'Smith' AND first_name LIKE '%ohn';-- 没有 ICP：先通过 last_name 索引查到所有 Smith 的主键，逐个回表再过滤 first_name-- 有 ICP：在索引扫描时直接对 first_name 做 LIKE 判断，不满足的跳过，减少回表在 EXPLAIN 的 Extra 列中，ICP 会显示 Using index condition。ICP 的适用条件是：查询使用了复合索引，且 WHERE 中有索引前列的等值条件加上后续列的条件过滤。如何监控和维护索引的健康状态？索引不是建完就一劳永逸的，随着数据增删改，索引可能出现碎片化、统计信息过期等问题，需要定期维护。-- 查看表的索引信息SHOW INDEX FROM users;-- 查看索引统计信息SELECT INDEX_NAME, SEQ_IN_INDEX, COLUMN_NAME, CARDINALITYFROM information_schema.STATISTICSWHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'users';-- 更新表的统计信息（不锁表）ANALYZE TABLE users;-- 重建表以消除碎片（会锁表）OPTIMIZE TABLE users;识别无用索引： 可以通过 sys.schema_unused_indexes 视图（MariaDB 10.6+）或开启 userstat 插件来追踪索引使用情况。长期未使用的索引应该清理，减少写入开销。监控索引碎片： 频繁的增删改会导致索引页出现空洞，降低索引扫描效率。OPTIMIZE TABLE 会重建表和索引，消除碎片，但操作期间会锁表，建议在低峰期执行。对于大表，可以考虑使用 ALTER TABLE ... ENGINE=InnoDB 的方式在线重建。统计信息维护： 优化器依赖统计信息（cardinality、rows 等）来选择执行计划。如果统计信息严重失真，可能导致优化器选错索引。定期执行 ANALYZE TABLE 可以刷新统计信息，且在 MariaDB 10.4+ 中该操作是在线进行的，不会阻塞读写。MariaDB 索引优化有哪些常见的实战案例？案例一：分页查询优化深分页是典型的性能杀手。SELECT * FROM orders ORDER BY id LIMIT 100000, 10 需要先扫描 100010 行再丢弃前 100000 行。-- 方案一：游标分页（推荐）-- 前端记录上一页最后一条的 id，下一页查询时带上SELECT * FROM orders WHERE id > 100000 ORDER BY id LIMIT 10;-- 方案二：延迟关联-- 先通过子查询在索引上定位 id，再回表取数据SELECT o.* FROM orders oJOIN (SELECT id FROM orders ORDER BY id LIMIT 100000, 10) tON o.id = t.id;案例二：多条件组合查询SELECT * FROM products WHERE category_id = 5 AND status = 1 AND price BETWEEN 100 AND 500 ORDER BY sales_count DESC LIMIT 20;索引设计：(category_id, status, sales_count)。前两列做等值过滤缩小范围，第三列利用索引有序性避免 filesort。price 列的范围查询放在最后处理。案例三：大表 JOIN 优化SELECT o.id, u.name FROM orders o JOIN users u ON o.user_id = u.idWHERE o.status = 2 AND u.region = 'CN';确保 JOIN 条件列（user_id、id）有索引，同时 orders 表在 status 上建索引、users 表在 region 上建索引，使驱动表的过滤结果尽可能小，减少循环 JOIN 的次数。掌握以上索引类型、设计原则、分析工具和实战技巧，基本能应对 MariaDB 索引优化的大部分面试问题和线上场景。核心思路始终是：用 EXPLAIN 验证，让索引覆盖查询，减少回表和全表扫描。

MariaDB 从 10.2 开始提供了一套 JSON 函数，能直接在 SQL 里创建、查询、修改和校验 JSON 数据。JSON 列本质是 LONGTEXT 加 CHECK 约束，不是 MySQL 那种二进制格式，这一点在迁移时容易踩坑。追问JSONEXTRACT、JSONVALUE、JSON_QUERY 有什么区别？三个都是取值，但返回类型不同：| 函数 | 返回值 | 示例 ||------|--------|------|| JSONEXTRACT | 原始 JSON 片段（带引号） | "John" || JSONVALUE | 标量值（去引号） | John || JSON_QUERY | 对象或数组 | {"city":"NY"} |日常取字符串值用 -> 操作符（JSONEXTRACT 的语法糖），取标量用 JSONVALUE，取嵌套对象用 JSON_QUERY。JSONSET、JSONINSERT、JSON_REPLACE 有什么区别？JSON_SET：存在则更新，不存在则插入——万能选手JSON_INSERT：只在路径不存在时插入，已有值不动JSON_REPLACE：只在路径已存在时替换，没找到就跳过记住一句话：不确定用 SET，只想加新字段用 INSERT，只想改旧字段用 REPLACE。JSON 列怎么加索引？JSON 列不能直接建普通索引。两种方式：生成列 + 索引（推荐）：ALTER TABLE products ADD COLUMN brand VARCHAR(50) GENERATED ALWAYS AS (JSON_UNQUOTE(JSON_EXTRACT(attributes, '$.brand'))) STORED, ADD INDEX idx_brand(brand);函数索引（MariaDB 10.3+）：CREATE INDEX idx_brand ON products((CAST(attributes->'$.brand' AS CHAR(50))));MariaDB 的 JSON 和 MySQL 的 JSON 有什么区别？这是迁移时最容易翻车的地方：| 对比项 | MariaDB | MySQL ||--------|---------|-------|| 存储格式 | 原文 LONGTEXT | 二进制 JSON || JSON 类型 | LONGTEXT 的别名 | 独立数据类型 || 自动校验 | 需要 CHECK 约束 | 内置校验 || 部分更新 | 不支持 | 支持二进制增量更新 |MariaDB 存原文的好处是可以直接用文本函数处理，坏处是每次修改整个字段重写，大 JSON 字段更新性能差。用 JSON 列存数据有什么坑？没有 schema 约束：同列不同行结构可以完全不同，查出来才知道长什么样，排查问题靠蒙查询性能：每次取值都要解析 JSON，高频查询字段务必抽成普通列加索引更新代价：改一个字段整个 JSON 重写，大文档更新慢CHECK 约束别忘了加：CREATE TABLE products ( id INT PRIMARY KEY, attrs JSON, CONSTRAINT chk_json CHECK (JSON_VALID(attrs)));写段代码-- 建表 + 插入 + 查询一条龙CREATE TABLE products ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100), attrs JSON CHECK (JSON_VALID(attrs)));INSERT INTO products (name, attrs) VALUES ('Laptop', '{"brand":"Dell","ram":"16GB"}');-- 查品牌、改内存SELECT name, attrs->'$.brand' AS brand FROM products;UPDATE products SET attrs = JSON_SET(attrs, '$.ram', '32GB') WHERE id = 1;

Logstash 吞吐量上不去，CPU 打满却处理不完日志，这类问题在生产环境里太常见了。很多团队第一反应是加机器，但多数情况下调对参数就能让现有资源发挥出两三倍的吞吐。这篇文章从实际踩坑经验出发，讲清楚 Logstash 性能瓶颈怎么定位、各参数怎么调、调了之后有什么效果。读完你会知道：什么时候该调 pipeline.workers，什么时候该加 Kafka 缓冲，G1GC 到底有没有用，以及那些看起来合理但实际拖慢速度的配置。先定位瓶颈再动手调优最忌讳盲目改参数。动手之前，先用 Logstash 自带的监控 API 看清楚瓶颈在哪：curl -s localhost:9600/_node/stats/pipelines | jq '.pipelines.main'重点关注这几个指标：| 指标 | 含义 | 健康范围 ||------|------|----------|| events.in | 每秒摄入事件数 | 接近输入源速率 || events.out | 每秒输出事件数 | 与 events.in 基本持平 || events.filtered | 过滤后事件数 | 合理的过滤率 || pipeline.workers 活跃数 | 当前工作线程 | 等于配置值 || queue.type | 队列类型 | memory 或 persisted |如果 events.in 远大于 events.out，说明处理速度跟不上摄入速度，瓶颈在 filter 或 output。如果 CPU 使用率低但吞吐上不去，问题可能出在 I/O 等待或网络延迟上。JVM 调优：堆内存和 GC 怎么配Logstash 跑在 JVM 上，内存配置直接影响性能。在 config/jvm.options 里调整：-Xms4g-Xmx4g-XX:+UseG1GC堆内存设置原则：Xms 和 Xmx 设成一样的值。动态扩缩容会触发 Full GC，导致处理暂停，日志管道会短暂卡顿堆内存不要超过物理内存的 50%。Logstash 本身还需要堆外内存做缓冲区和网络 I/O，堆太大会让操作系统可用内存不足，反而触发 swap大多数场景 4-8GB 就够了。超过 8GB 不一定更好——堆越大，GC 扫描的时间越长，G1GC 在 4-8GB 区间表现最好G1GC 是否值得开？ 实测下来，G1GC 相比默认的 Parallel GC，在堆内存 4GB 以上时 Full GC 暂停时间从秒级降到百毫秒级。但如果堆只有 2GB，G1GC 的分区管理开销反而可能让吞吐量下降 5%-10%。所以：4GB 以上开 G1GC，2GB 以下用默认的就行。一个容易踩的坑：如果日志里有大量 Grok 解析失败，会产生异常对象堆积在堆里。这时候调大堆只是延缓问题，根本办法是修 Grok 模式或用 if 条件跳过不需要解析的日志。Pipeline 参数：workers、batch size、delay 怎么平衡这三个参数互相影响，单独调一个往往看不到效果。pipeline.workers# logstash.ymlpipeline.workers: 4这是处理事件的线程数。默认值是 CPU 核心数，但有个前提：你的 filter 和 output 插件必须是线程安全的。大多数官方插件没问题，但自定义插件需要确认。实际调法：先设成 CPU 核心数跑基准测试，然后分别试 核心数/2 和 核心数*2，看哪个 EPS 最高。经验上，filter 重（大量 Grok 正则）的场景设成核心数就行，filter 轻但 output 重（往 ES 写入）的场景可以适当加倍。pipeline.batch.sizepipeline.batch.size: 125每个 worker 一次拿多少事件来处理。默认 125 是个保守值。增大 batch size 能减少事件调度开销，提高吞吐量：高吞吐场景（日志量 > 10万/分钟）：调到 500-1000低延迟场景（实时告警）：保持 125 或更小batch size 不是越大越好。过大的 batch 会导致单个批次处理时间变长，增加事件从进入到输出端的端到端延迟。而且如果 filter 里有 Grok 失败的情况，大 batch 会让重试开销放大。pipeline.batch.delaypipeline.batch.delay: 50worker 等待多久凑够一个 batch 再开始处理，单位毫秒。默认 50ms。这个参数的意义是：当事件流入速度不够快时，等一等能凑满 batch，减少处理次数。事件流入速度很快：delay 可以降到 10-20ms，减少等待事件流入速度慢但实时性要求高：降到 5ms 甚至 1ms事件流入速度慢且不要求实时：保持 50ms，省 CPU三者联动经验：高吞吐场景用 workers=核心数, batch.size=500, batch.delay=10；低延迟场景用 workers=4, batch.size=50, batch.delay=5。改一个参数时保持其他两个不变，观察 EPS 变化，找到拐点。Filter 优化：减少无用功Filter 是 Logstash 最容易成为瓶颈的环节，尤其是 Grok。Grok 是性能杀手Grok 底层是正则表达式，每条日志都要跑一遍模式匹配。优化 Grok 的方法：用 if 条件跳过不需要 Grok 的日志：filter { if [type] == "nginx_access" { grok { match => { "message" => "%{COMBINEDAPACHELOG}" } } }}这看起来简单，但实际效果可能比调参数还明显。一条不需要 Grok 的日志跳过正则匹配，省下的是毫秒级的 CPU 时间。自定义模式比组合内置模式快：内置的 COMBINEDAPACHELOG 实际上是多个小模式拼接的，每次匹配都要逐个尝试。写成一条自定义模式能减少匹配次数：# 自定义模式文件NGINX_ACCESS %{IPORHOST:clientip} %{USER:ident} %{USER:auth} \[%{HTTPDATE:timestamp}\] "%{WORD:method} %{URIPATHPARAM:request} HTTP/%{NUMBER:httpversion}" %{NUMBER:response} %{NUMBER:bytes}把最常匹配的模式放前面：Grok 是按顺序尝试匹配的，最可能的模式放第一个能最快命中。用 dissect 替代简单格式的 Grok：如果日志格式是固定的分隔符（如管道符、逗号分隔），dissect 插件用分隔符切分，比正则匹配快 5-10 倍：filter { dissect { mapping => { "message" => "%{ip} | %{user} | %{action}" } }}其他 Filter 优化mutate 的 remove_field：尽早删掉不需要的字段，减少后续处理的数据量用 drop 过滤器丢弃无用事件：在 filter 链最前面丢弃，比处理完再丢省很多资源避免重复解析：如果上游已经做过 JSON 解析，不要再用 json filter 再解析一遍Output 优化：往 ES 写数据的讲究ES output 是最常见的瓶颈之一。批量写入参数output { elasticsearch { hosts => ["http://es-cluster:9200"] http_compression => true }}注意：旧版本的 flush_size 和 idle_flush_time 参数已经在 7.x 之后废弃，改由 pipeline 的 batch size 和 batch delay 统一控制。如果你还在用这两个参数，升级后删掉，否则会有告警。http_compression => true 这个一定要开。压缩后网络传输量减少 60%-80%，对跨机房写入场景效果尤其明显，CPU 开销可以忽略。连接池调优如果 ES 集群有多个节点，Logstash 会自动轮询写入。但默认连接池大小可能不够，高并发场景下可以在 ES output 里显式配置：output { elasticsearch { hosts => ["http://es-node1:9200", "http://es-node2:9200", "http://es-node3:9200"] http_compression => true # 新版本支持的批量操作参数 action => "index" }}持久队列：防数据丢失的最后防线# logstash.ymlqueue.type: persistedpath.queue: /data/logstash/queuequeue.page_capacity: 250mbqueue.max_events: 0queue.max_bytes: 4gb持久队列把事件写到磁盘，Logstash 重启或崩溃时不丢数据。代价是吞吐量下降 10%-20%，因为每次事件要写磁盘。什么场景该开持久队列：数据不能丢（金融日志、审计日志）下游 ES 不稳定，偶尔写入失败Logstash 重启频繁什么场景可以不开：日志允许少量丢失（纯分析用途的访问日志）下游写入非常稳定对吞吐量有极致要求架构层面：加缓冲和水平扩展单机调优总有上限。当一台 Logstash 处理不过来，架构上的调整比继续压单机更有效。加 Kafka 缓冲Filebeat → Kafka → Logstash → ElasticsearchKafka 在中间起两个作用：一是缓冲突发流量，Logstash 处理不过来时 Kafka 先存着；二是解耦，上游采集和下游处理互不影响。Kafka 场景下的 Logstash 配置要点：input { kafka { bootstrap_servers => "kafka1:9092,kafka2:9092" topics => ["nginx-logs"] group_id => "logstash-nginx" consumer_threads => 4 auto_offset_reset => "earliest" }}consumer_threads 建议设成 Kafka 分区数。如果分区数是 12，设 12 个 consumer 线程能充分利用并行消费。多实例水平扩展起多个 Logstash 实例，用负载均衡或 Kafka consumer group 分流：如果输入源是 Kafka：每个 Logstash 实例配相同的 group_id，Kafka 自动分配分区给不同实例如果输入源是 Beats：在 Beats 和 Logstash 之间加一层 Nginx 或 HAProxy 做 TCP 负载均衡用 Beats 替代 Logstash 做采集Filebeat、Metricbeat 比 Logstash 轻量得多，资源占用大约是 Logstash 的 1/10。架构上让 Beats 做采集、Logstash 做处理，比让 Logstash 又采集又处理高效得多。怎么验证优化效果每次只改一个参数，跑一轮基准测试对比。用 Logstash 自带的 generator 输入插件做压测：input { generator { lines => ["192.168.1.1 - - [10/Oct/2023:13:55:36 +0000] \"GET /api/users HTTP/1.1\" 200 2326"] count => 1000000 }}filter { grok { match => { "message" => "%{COMBINEDAPACHELOG}" } }}output { stdout { codec => dots }}跑完后看输出的时间，算出 EPS（每秒处理事件数）。把这个值作为基准，改一个参数再跑，对比变化。生产环境监控关键指标：events.in 和 events.out 的差值（积压量）、JVM 堆使用率、GC 频率和耗时。如果堆使用率持续超过 75% 或 Full GC 频率超过每分钟一次，说明要么堆太小，要么 filter 有内存泄漏。调优没有一劳永逸的方案。日志格式变了、流量模式变了、ES 集群扩容了，都可能让之前的调优配置不再最优。养成定期看监控、定期跑基准测试的习惯，比任何单次调优都重要。

Grok 过滤器：把非结构化日志变成结构化数据Grok 是 Logstash 中使用频率最高的过滤器，核心能力是将一行纯文本日志拆解成有名字段的 JSON。它的底层原理是基于正则表达式的模式匹配，但 Elastic 已经预置了大量常用模式，日常使用不需要手写正则。基本匹配最典型的场景是解析 Apache/Nginx 访问日志。COMBINEDAPACHELOG 是内置模式，一条配置就能提取 clientip、response_code、bytes 等十几个字段：filter { grok { match => { "message" => "%{COMBINEDAPACHELOG}" } }}匹配成功后，原来 message 字段中的一整行日志会被拆成 clientip、ident、auth、timestamp、verb、request、httpversion、response、bytes 等独立字段，后续过滤器和输出插件都能直接引用。多模式备选实际生产中，日志格式往往不止一种。Grok 支持传入一个模式数组，按顺序依次尝试匹配，命中的第一个生效：filter { grok { match => { "message" => [ "%{COMBINEDAPACHELOG}", "%{COMMONAPACHELOG}", "%{SYSLOGBASE} %{GREEDYDATA:message}" ] } }}这种方式比写一个超长的"万能正则"更易维护，哪条模式匹配了也更容易排查。自定义模式当内置模式无法满足需求时，可以在外部文件中定义自己的模式。模式文件的语法是 PATTERN_NAME regex，一行一个：filter { grok { patterns_dir => ["/etc/logstash/patterns"] match => { "message" => "%{MYAPP_LOG:myapp_field}" } }}对应的 /etc/logstash/patterns/myapp 文件内容示例：MYAPP_LOG \[%{TIMESTAMP_ISO8601:timestamp}\] \[%{LOGLEVEL:level}\] %{GREEDYDATA:msg}Grok 匹配失败怎么办Grok 匹配失败时，Logstash 会自动给事件打上 _grokparsefailure 标签。在生产环境中，应该用条件判断捕获这些失败事件，避免脏数据静默进入 Elasticsearch：filter { grok { match => { "message" => "%{COMBINEDAPACHELOG}" } } if "_grokparsefailure" in [tags] { mutate { add_field => { "parse_error" => "grok failed for message" } } }}也可以借助 Kibana 自带的 Grok Debugger 工具调试模式，避免反复重启 Logstash。Mutate 过滤器：字段级别的加工工具Mutate 是"万能修理工"，几乎所有的字段增删改操作都能靠它完成。它不关心数据来源，只对已有字段做变换。重命名字段从 Beats 或其他输入源拿到的字段名不符合规范时，用 rename 统一命名：filter { mutate { rename => { "client_ip" => "source_ip" } }}类型转换Grok 解析出来的字段默认都是字符串类型，想做数值聚合或范围查询，必须先转换类型：filter { mutate { convert => { "response" => "integer" "request_time" => "float" } }}这一步经常被忽略，导致 Elasticsearch 中所有字段都是 keyword 类型，数值范围查询直接失效。删除无用字段每个事件默认携带 message、@version、host 等字段。如果已经用 Grok 把 message 拆成了独立字段，原始 message 留着只会浪费存储：filter { mutate { remove_field => ["message", "@version", "host"] }}替换和追加字段replace 会覆盖已有字段或新建字段，add_field 则是在原有字段基础上追加：filter { mutate { replace => { "log_source" => "production-nginx" } add_field => { "environment" => "prod" "pipeline" => "nginx-access" } }}gsub：正则替换字段内容Mutate 自带 gsub 操作，可以对字段值做正则替换，不需要动用 Ruby 过滤器：filter { mutate { gsub => [ "request", "\\?.+$", "" ] }}这会把 /api/users?page=1&size=10 替换为 /api/users，去掉查询参数部分，便于按路径做聚合统计。大小写转换与分割filter { mutate { uppercase => ["log_level"] split => { "tags" => "," } }}uppercase 将字段值转为大写，split 按指定分隔符将字符串拆成数组。这两个操作在数据规范化场景中很常用。Mutate 各操作的执行顺序Mutate 内部有固定的操作执行顺序，与你在配置中写的顺序无关：rename → copy → gsub → uppercase/lowercase → strip → replace → join → split → merge → coerce → convert → add_field → remove_field。如果 rename 在 convert 之后才生效，可能让类型转换的目标字段名对不上。遇到这类问题时，可以拆成两个 mutate 块来控制顺序：filter { mutate { rename => { "resp_code" => "response" } } mutate { convert => { "response" => "integer" } }}Date 过滤器：统一时间戳格式Logstash 用 @timestamp 作为事件的时间基准，但原始日志中的时间格式千差万别。Date 过滤器的作用就是把各种格式的时间字符串解析成 Logstash 内部的 ISO8601 时间对象。解析多种时间格式filter { date { match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z", "yyyy-MM-dd HH:mm:ss", "ISO8601" ] }}match 的第二个参数是格式数组，Joda-Time 格式和 ISO8601 关键字都可以混用。解析成功后，@timestamp 自动更新。指定时区和目标字段filter { date { match => ["log_time", "yyyy-MM-dd HH:mm:ss"] timezone => "Asia/Shanghai" target => "parsed_time" }}如果不指定 target，默认写入 @timestamp。如果只想保留解析结果但不动 @timestamp，就指定一个自定义的 target 字段。GeoIP 过滤器：IP 地址转地理位置GeoIP 根据 IP 地址查询 MaxMind 数据库，自动补充城市、国家、经纬度等地理信息，是做访问地图可视化的前提。filter { geoip { source => "client_ip" target => "geo" fields => ["city_name", "country_name", "location"] }}source 指定待查询的 IP 字段，fields 限制只输出需要的地理字段，避免写入过多无用数据。注意 Logstash 默认内置了 GeoLite2 数据库，但如果需要更精确的数据，需要手动下载并指定 database 路径。JSON 过滤器：解析嵌套 JSON 日志现代应用的日志越来越倾向于直接输出 JSON 格式，JSON 过滤器可以把它展开成 Logstash 的事件字段：filter { json { source => "message" target => "parsed" }}如果指定了 target，解析结果会放在 target 字段下形成嵌套结构；不指定则直接铺平到顶层。生产中建议指定 target，避免字段名冲突。解析后通常配合 mutate 删除原始 message 字段：filter { json { source => "message" target => "log" } mutate { remove_field => ["message"] }}Useragent 过滤器：解析浏览器信息从 HTTP 请求的 User-Agent 头中提取浏览器名称、版本、操作系统等信息：filter { useragent { source => "agent" target => "ua" }}通常跟在 Grok 解析 Apache 日志之后使用，agent 字段就是 Grok 从日志中提取出来的 User-Agent 字符串。CSV 过滤器：处理表格数据CSV 过滤器用于解析逗号（或其他分隔符）分隔的文本数据：filter { csv { separator => "," columns => ["name", "age", "city"] autodetect_column_types => true }}columns 指定每列的字段名，autodetectcolumntypes 让 Logstash 自动识别数值类型。如果 CSV 首行是表头，也可以省略 columns 让它自动读取。Ruby 过滤器：处理复杂逻辑当内置过滤器无法满足需求时，Ruby 过滤器提供了完全的编程能力：filter { ruby { code => ' status = event.get("response").to_i if status >= 400 event.tag("error") event.set("error_level", status >= 500 ? "server_error" : "client_error") end ' }}Ruby 过滤器灵活但性能开销大，Grok 能搞定的事情不要用 Ruby。实际项目中，Ruby 过滤器多用于多字段联合计算、条件标签打标等场景。Drop 过滤器：丢弃不需要的事件Drop 过滤器直接丢弃整个事件，不会传到输出阶段。常见用法是过滤掉调试日志或特定来源的噪声数据：filter { if [log_level] == "DEBUG" or [message] =~ /^health check/ { drop { } }}使用时注意加上条件判断，否则会丢掉所有事件。过滤器的组合与顺序实际项目中，过滤器总是组合使用的。一个典型的 Nginx 访问日志处理管线：filter { # 第一步：用 Grok 把日志拆成字段 grok { match => { "message" => "%{COMBINEDAPACHELOG}" } } # 第二步：转换数值类型 mutate { convert => { "response" => "integer" } convert => { "bytes" => "integer" } remove_field => ["message"] } # 第三步：解析时间戳 date { match => ["timestamp", "dd/MMM/yyyy:HH:mm:ss Z"] } # 第四步：补充地理位置 geoip { source => "clientip" } # 第五步：解析 User-Agent useragent { source => "agent" target => "ua" }}过滤器的执行顺序就是配置中的书写顺序。一般遵循"先解析、再转换、后丰富"的原则：Grok 在最前面把原始文本拆开，Mutate 紧跟其后做类型转换和字段清理，Date/GeoIP/Useragent 等根据已有字段做信息补充。日常排错建议Grok 匹配失败：检查 Kibana Grok Debugger，确认模式与日志格式一致。生产环境务必处理 _grokparsefailure 标签事件。Mutate 顺序问题：记住 Mutate 内部操作有固定执行顺序，不受配置书写位置影响。遇到 rename 和 convert 冲突时，拆成两个 mutate 块。Date 时区偏移：@timestamp 默认是 UTC 时间，查询时注意时区换算。如果业务强依赖本地时间，在 date 过滤器中指定 timezone。GeoIP 数据库过旧：Logstash 内置的 GeoLite2 不会自动更新，地理信息不准确时需要手动下载最新数据库。性能瓶颈：Grok 是 CPU 密集型操作，复杂模式会导致吞吐量下降。可以考虑用 dissect 过滤器替代简单格式的 Grok 匹配，dissect 基于分隔符定位，性能更好。

MQTT 主题通配符是订阅机制中绕不过去的核心概念。当你只需要监听某一类设备的数据，而不是逐个订阅每一个具体主题时，通配符就能派上用场。MQTT 规范定义了两种通配符：单级通配符 + 和多级通配符 #，它们各自的匹配规则和使用限制完全不同，混用或用错都会导致订阅失败或收到意料之外的消息。单级通配符 +单级通配符用 + 表示，它的作用很明确：只匹配主题层级中的一个层级，且该层级不能为空。所谓"一个层级"，指的是两个 / 之间的一段内容。比如主题 home/livingroom/temperature 包含三个层级：home、livingroom、temperature。如果你订阅 home/+/temperature，那么第二层级无论是什么值都会被匹配到——home/bedroom/temperature、home/kitchen/temperature 都能命中，但 home/temperature 不行（缺少一个层级），home/livingroom/kitchen/temperature 也不行（多了一个层级）。几个需要特别注意的点：+ 可以在同一个主题过滤器中出现多次。比如 sensor/+/data/+ 是合法的，它会匹配 sensor/001/data/temperature 和 sensor/002/data/humidity，但不匹配 sensor/001/data（层级不够）或 sensor/001/data/temperature/value（层级超出）。+ 不能匹配空层级。订阅 home/+/temperature 不会匹配 home//temperature，因为中间那个层级是空的，而 + 要求至少有一个字符。+ 必须占据整个层级。home/room+/temperature 是无效写法，它不会匹配 home/room1/temperature——+ 不是一个正则里的"一个任意字符"，而是代表整个层级的通配。多级通配符多级通配符用 # 表示，它的匹配范围比 + 大得多：匹配当前层级及其后面的所有层级，包括零个层级。比如订阅 home/#，以下主题全部能命中：home/livingroom、home/livingroom/temperature、home/bedroom/humidity/value。甚至 home/ 本身也能匹配（# 匹配了零个层级，但注意 home 不行，因为 # 前面必须有 / 或者 # 本身就是整个过滤器的第一个字符）。# 的使用限制比 + 更严格：必须放在主题过滤器的最后。home/#/temperature 是无效的，Broker 会直接拒绝这种订阅。这是 MQTT 规范的硬性要求，没有例外。每个主题过滤器只能出现一次。home/#/# 这种写法同样无效。前面必须有 / 分隔（除非 # 是整个过滤器的唯一内容，即单独订阅 #，这会匹配所有主题）。比如 home# 是无效的，home/# 才是正确的。单独订阅 # 是一个特殊用法——它匹配 Broker 上的所有主题。这在调试阶段偶尔有用，但在生产环境中极度危险，不仅会造成性能问题，还可能收到大量不相关的消息。+ 和 # 的组合使用两种通配符可以在同一个主题过滤器中组合使用，只要遵守各自的规则。最常见的组合模式是先用 + 固定某个层级，再用 # 捕获剩余部分：订阅：home/+/sensors/#匹配： home/livingroom/sensors/temperature ✓ home/livingroom/sensors/temperature/value ✓ home/bedroom/sensors/humidity ✓不匹配： home/sensors/temperature ✗（+不能匹配空层级） home/livingroom/sensors ✗（# 前缺少 /）订阅：sensor/+/#匹配： sensor/001/data ✓ sensor/001/data/temperature ✓ sensor/002/data/humidity/value ✓不匹配： sensor ✗（+至少需要一个层级） office/001/data ✗（第一层级不匹配）组合使用时，最容易犯的错误是在 # 后面继续加内容。记住一条原则：过滤器里出现了 #，它后面就不能再有任何东西。通配符只能用于订阅，不能用于发布这是一个初学者常踩的坑。MQTT 规范明确规定：通配符只适用于订阅（SUBSCRIBE）操作，发布（PUBLISH）时必须指定完整的确切主题。这意味着你不能往 home/+/temperature 发布消息，Broker 不会帮你把消息分发到 home/livingroom/temperature 和 home/bedroom/temperature。发布时，客户端必须明确指定目标主题，比如 home/livingroom/temperature。这个设计是合理的：如果允许通配符发布，消息的路由方向就变得不可预测，整个发布-订阅模型的确定性会被破坏。通配符匹配的实际示例理解规则是一回事，在实际场景中正确使用是另一回事。下面用几个常见场景来演示：场景一：监控所有温度传感器假设你的传感器主题结构为 sensors/{device_id}/temperature，你想接收所有设备的温度读数，订阅 sensors/+/temperature 即可。每台设备发布消息到自己的确切主题（如 sensors/001/temperature），而你的客户端只需要一条订阅规则就能全部收到。场景二：监控某个楼层所有设备主题结构为 building/floor1/{device_type}/{device_id}，你只关心一楼的全部数据，那就订阅 building/floor1/#。不管后面有多少层级、是什么设备类型，一楼的所有消息都会推送到你的客户端。场景三：订阅特定设备类型的状态主题结构为 device/{device_id}/status，你想监控所有设备的在线/离线状态。订阅 device/+/status，每台设备状态变化都能收到。场景四：订阅所有告警告警消息散布在多个层级中：alert/critical/overheat、alert/warning/low_battery、alert/info/maintenance。订阅 alert/# 一条规则覆盖全部告警类型。场景五：分层指标收集系统指标主题可能是 system/{service}/metrics/{metric_name}/{instance}。如果你想收集某个服务下所有实例的所有指标，可以订阅 system/payment/metrics/#。如果你需要所有服务的同一个指标名，则用 system/+/metrics/cpu_usage/#。通配符使用中的常见错误在实际开发中，以下错误反复出现：错误一：把 + 当成正则的 .+ 不是正则表达式里的 .，它匹配的是一整个层级，而不是一个字符。home/room+/temperature 不会匹配 home/room1/temperature，这是无效的订阅格式。错误二：把 # 放在中间home/#/temperature 看起来像"home 下面任意层级后面跟 temperature"，但 MQTT 不支持这种用法。# 只能在最后，没有例外。如果你需要这种模式，只能通过精确订阅多个主题来弥补。错误三：期望 + 匹配空层级home/+/temperature 不会匹配 home//temperature。空层级在实际业务中很少出现，但如果你手动拼接主题字符串时不小心产生了连续的 /，就会触发这个问题，而且很难排查。错误四：在生产环境订阅 #单独订阅 # 会收到 Broker 上的所有消息。调试时可能方便，但生产环境下这会给 Broker 和客户端同时带来不必要的负担，还可能暴露不该看到的数据。错误五：忘记 # 前面的 /home# 是无效的。如果你的主题层级超过一层，# 前面必须有 /。只有当 # 是整个过滤器的唯一字符时才不需要前面的 /。通配符对性能的影响通配符订阅不是免费的。Broker 收到每一条消息后，都需要遍历所有订阅进行主题匹配。精确订阅的匹配是 O(1) 的哈希查找，而通配符订阅需要逐个做模式匹配，复杂度至少是 O(n)，n 是通配符订阅的数量。实际影响取决于 Broker 的实现和你的订阅规模。EMQX、Mosquitto 等主流 Broker 都对通配符匹配做了优化（比如用 Trie 树），在几千个订阅的场景下，性能差异通常可以忽略。但当订阅数达到十万甚至百万级别时，通配符匹配的开销就会显现。几个性能方面的建议：能用精确订阅就不用通配符。如果你只需要三台设备的数据，分别订阅三个主题比 sensor/+/temperature 更高效。通配符越具体越好。building/floor1/# 比 building/# 的匹配范围小，Broker 的过滤效率也更高。主题层级不要太深。5 层以内的主题结构在匹配性能上不会有问题，超过 10 层的场景需要评估。避免大量客户端同时订阅宽泛通配符。1000 个客户端都订阅 # 比它们各自订阅不同的精确主题对 Broker 的压力大得多。通配符与安全控制通配符订阅天然和权限控制存在张力。一条 # 订阅就能绕过主题层级的隔离，所以 ACL（访问控制列表）的配置必须考虑通配符场景。主流 Broker 都支持基于主题模式的 ACL 规则。比如 EMQX 可以配置"允许客户端订阅 sensors/+/temperature，但拒绝 sensors/#"，从而限制客户端只能读取温度数据，不能读取湿度、压力等其他传感器数据。安全配置的核心原则是最小权限：只授予客户端完成其工作所需的最小订阅范围。如果某个客户端只需要一楼的数据，就只给它 building/floor1/# 的权限，而不是 building/#。另外，通配符订阅可能带来信息泄露风险。假设你的主题结构是 tenant/{tenant_id}/data，如果某个客户端订阅了 tenant/+/data，它就能收到所有租户的数据。在多租户系统中，这个问题尤其严重，ACL 必须严格限制跨租户的通配符订阅。代码示例Python（paho-mqtt）import paho.mqtt.client as mqttdef on_connect(client, userdata, flags, reason_code, properties): print(f"Connected: {reason_code}") # 订阅所有设备的温度数据（单级通配符） client.subscribe("sensors/+/temperature") # 订阅卧室的所有数据（多级通配符） client.subscribe("home/bedroom/#") # 组合使用：所有服务的指标数据 client.subscribe("system/+/metrics/#")def on_message(client, userdata, msg): print(f"Topic: {msg.topic}, Payload: {msg.payload.decode()}")client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)client.on_connect = on_connectclient.on_message = on_messageclient.connect("broker.example.com", 1883, 60)client.loop_forever()JavaScript（MQTT.js）const mqtt = require('mqtt');const client = mqtt.connect('mqtt://broker.example.com:1883');client.on('connect', () => { console.log('Connected'); // 单级通配符：所有设备的温度 client.subscribe('sensors/+/temperature'); // 多级通配符：卧室所有数据 client.subscribe('home/bedroom/#'); // 组合通配符：所有服务的指标 client.subscribe('system/+/metrics/#');});client.on('message', (topic, message) => { console.log(`Topic: ${topic}, Payload: ${message.toString()}`);});Java（Eclipse Paho）import org.eclipse.paho.mqttv5.client.MqttClient;import org.eclipse.paho.mqttv5.client.MqttConnectionOptions;import org.eclipse.paho.mqttv5.client.persist.MemoryPersistence;MqttClient client = new MqttClient( "tcp://broker.example.com:1883", "java-client-" + System.currentTimeMillis(), new MemoryPersistence());client.setCallback(new MqttCallback() { @Override public void messageArrived(String topic, MqttMessage message) { System.out.println("Topic: " + topic + ", Payload: " + new String(message.getPayload())); } // ... 其他回调方法省略});MqttConnectionOptions opts = new MqttConnectionOptions();opts.setAutomaticReconnect(true);client.connect(opts);// 单级通配符client.subscribe("sensors/+/temperature", 1);// 多级通配符client.subscribe("home/bedroom/#", 1);// 组合通配符client.subscribe("system/+/metrics/#", 1);主题设计建议通配符好不好用，很大程度上取决于你的主题结构设计。一个设计良好的主题结构能让通配符发挥最大价值，而一个糟糕的主题结构会让通配符变得鸡肋甚至无法使用。保持层级语义一致。 主题的每一层都应该有明确的含义。building/floor1/room2/temperature 这种结构中，每一层都是具体的分类维度，通配符可以精确地切入任何维度。如果主题层级含义混乱（比如 data/temperature/floor1/001），通配符就很难发挥筛选作用。层级不要太深。 3-5 层是最佳范围。层级过深会增加匹配开销，也让订阅规则变得难以阅读和维护。避免在层级中使用特殊字符。 主题层级中不要包含 +、#、/ 这些保留字符，也不要使用空格和通配符本身。MQTT 规范虽然没有禁止在主题内容中使用这些字符，但它们会干扰通配符的匹配逻辑。统一命名风格。 全部用小写、用下划线或连字符连接单词，不要混用 camelCase 和 snake_case。sensor/temperature/living_room 比 sensor/Temperature/LivingRoom 更不容易出错。为通配符预留扩展空间。 设计时考虑未来可能新增的层级。比如当前主题是 device/{id}/status，未来可能需要按区域分组，那不如一开始就设计成 region/{region}/device/{id}/status，这样 region/east/# 这样的订阅就有意义了。MQTT 主题通配符本质上是一种模式匹配机制，+ 匹配单层级，# 匹配多层级，两者都只能用于订阅。理解它们的匹配规则和使用限制是正确使用 MQTT 的前提，而良好的主题结构设计则决定了通配符在实际项目中能发挥多大的价值。

Ollama vs vLLM：定位完全不同Ollama 和 vLLM 虽然都能运行大语言模型，但定位截然不同。Ollama 追求一行命令跑起来的开发体验，vLLM 则是面向生产环境的高性能推理引擎。部署与上手Ollama 的安装极简——macOS、Windows、Linux 三端都有图形化安装包，装完后 ollama run llama3 即可启动对话，无需配置文件、无需 Docker、无需 Python 环境。模型管理采用类 Docker 的 pull/run 模式，开箱即用。vLLM 需要 Python 环境，通过 pip install vllm 安装后还需指定模型路径、GPU 设备、并发参数等启动配置，学习曲线明显更陡。不过 vLLM 也提供了 OpenAI 兼容的 API 服务端模式，启动后可直接替换 OpenAI API 使用。推理性能与并发能力这是两者差距最大的地方。以 Llama 3.1 8B 在 A100 80GB 上的基准测试为例：单用户场景：Ollama（Q4KM 量化）约 62 tokens/sec，TTFT 65ms，显存占用 5.2GB；vLLM（FP16）约 168 tokens/sec，TTFT 10.7ms，显存占用 16.8GB50 并发：Ollama 155 tokens/sec，vLLM 920 tokens/sec（约 6 倍）100 并发：Ollama 降至 142 tokens/sec 并出现性能衰减，vLLM 达 1,640 tokens/sec（约 11.5 倍）128 并发：Ollama 出现超时失败，vLLM 保持 100% 成功率性能差距的根源在于 vLLM 的两项核心技术：PagedAttention 将 KV 缓存按页管理，避免显存碎片化，显存利用率接近理论最优；Continuous Batching 动态填充 GPU 计算资源，请求完成后立即补入新请求，避免批处理空隙。多 GPU 与扩展性vLLM 支持张量并行（Tensor Parallelism），可将模型切分到多张 GPU 上并行推理，在 4x A100 配置上可运行 70B 级别的大模型。Ollama 不支持多 GPU 张量并行，大模型只能依赖单卡显存或部分层卸载到 CPU。在 NVIDIA Blackwell 架构（RTX 5090/RTX PRO 6000）上，vLLM 的扩展优势进一步放大至约 16.6 倍。vLLM v0.11.0 已支持 Blackwell 架构，Ollama 的适配仍在跟进中。何时选 Ollama个人学习和实验，消费级显卡（如 RTX 4060，8GB 显存）即可运行 7B 量化模型快速原型验证，需要频繁切换不同模型测试效果本地开发环境，作为 AI 应用的后端推理服务不想折腾 Python 环境和 GPU 驱动配置何时选 vLLM生产级 API 服务，需要支撑高并发请求企业级部署，对可用性（99.9%）和吞吐量有硬性要求多 GPU 服务器环境，需要横向扩展成本敏感场景：500+ 请求/小时时，vLLM 在 A100 上比 GPT-4o API 节省约 70% 成本一种务实的做法是用 Ollama 做原型开发和模型选型，确认方案后迁移到 vLLM 做生产部署，两者都提供 OpenAI 兼容 API，切换成本低。Ollama vs LM Studio：CLI 还是 GUIOllama 和 LM Studio 都基于 llama.cpp 推理后端，但面向不同用户群。交互方式Ollama 是 CLI-first 的无头守护进程设计，没有内置图形界面，通过命令行和 REST API 交互。适合已熟悉终端的开发者，也便于在服务器上以 systemd 服务运行。LM Studio 是 GUI-first 的桌面应用，提供模型浏览、下载、对话、参数调节的一站式体验。左侧模型库、右侧对话窗口的分栏布局，不碰命令行就能完成从下载到推理的全流程。性能差异两者都用 llama.cpp，但 Ollama 在推理速度上快约 10-20%，显存开销更低。Ollama 在模型空闲时自动卸载释放显存，LM Studio 在部分测试中显存占用可达 Ollama 的 5 倍。Ollama 对多 GPU 配置有更好的分层调度优化。模型支持Ollama 维护精选模型库，覆盖 100+ 模型家族（Llama、Mistral、Gemma、DeepSeek、Qwen、Phi 等），新模型上架速度快，2026 年已支持 Llama 4 Scout、Qwen 3.6、GLM-5.1 等。通过 Modelfile 可自定义模型参数、系统提示词和模板。LM Studio 内置模型市场，支持从 Hugging Face 搜索和下载 GGUF 格式模型，选择更灵活但对用户辨识模型质量的能力要求更高。生态集成Ollama 提供 Python 和 JavaScript SDK，被 Open WebUI、Dify、n8n 等 Agent 框架原生支持，有官方 Docker 镜像，CI/CD 集成方便。GitHub 星标 162,000+，社区活跃。LM Studio 的生态围绕桌面端展开，2026 年正在扩展 LoRA 微调和批量推理功能，但缺少 Docker 支持、命令行工具和 API 服务端模式，自动化集成能力有限。何时选 Ollama开发者日常工作流，需要 API 集成到应用中服务器部署和自动化场景多 GPU 环境下的性能优化需要模型频繁切换和脚本化管理何时选 LM Studio非技术背景用户，偏好图形界面操作快速探索不同模型的对话效果不需要 API 服务或自动化集成想要一站式桌面体验，零配置开箱即用两者也并不冲突——可以先用 LM Studio 在桌面端评估模型效果，确认目标模型后切到 Ollama 做 API 集成和生产部署。Ollama vs LocalAI：简洁还是全面LocalAI 的定位是 OpenAI API 的本地替代网关，支持文本、图像、音频、视频等多种生成能力。OpenAI API 兼容性这是 LocalAI 最核心的优势。它完整实现了 OpenAI API 规范，包括 /v1/chat/completions、/v1/embeddings、Function Calling（含并行函数调用）、Whisper 语音转写、TTS 语音合成、DALL-E 兼容图像生成等端点。从 OpenAI 云端迁移到 LocalAI，代码改动极小。Ollama 也提供 OpenAI 兼容端点，但覆盖范围有限，主要支持基础的 Chat Completions 和 Embeddings，Function Calling 支持较基础，不支持音频和图像生成端点。多模态能力LocalAI 集成了 Stable Diffusion、Flux 等图像生成后端、Whisper 语音转写和多套 TTS 引擎，一个服务即可同时提供文本、图像、音频推理。Ollama 在多模态方面主要依赖模型本身的多模态能力（如 LLaVA），不提供独立的图像/音频生成管道。性能对比在 Apple Silicon M2 16GB 上运行 Gemma 3 12B（Q4KM 量化）的测试中：Ollama：prompt 评估 76.5 tok/s，生成 13.6 tok/s，TTFT 287ms，峰值显存 8.2GBLocalAI：生成 11.8 tok/s，TTFT 约 500ms，峰值显存 9.1GBOllama 在推理速度和资源占用上有明显优势。LocalAI 因为功能更全面、后端更多，架构更重。部署灵活性Ollama 有原生桌面客户端，安装即用。LocalAI 主要以容器化方式部署，没有官方桌面应用，需要 Docker 或手动编译，配置也更复杂。不过 LocalAI 可纯 CPU 运行，不强制 GPU，适合没有独显的轻量服务器。何时选 Ollama以文本生成为主，追求部署简洁和推理性能个人开发者或小团队的本地推理需求不需要完整的 OpenAI API 兼容性何时选 LocalAI从 OpenAI 云端 API 迁移到本地，需要最小化代码改动需要多模态能力（图像生成、语音转写、TTS）的一站式服务需要完整的 Function Calling 支持在无 GPU 的服务器上运行推理Ollama vs Text Generation WebUI（Oobabooga）：API 还是交互Text Generation WebUI（常称 Oobabooga）是一个功能丰富的 Web 界面推理工具，侧重于交互式参数调整和模型实验。交互体验Text Generation WebUI 提供完整的 Web 界面，支持对话模式、笔记本模式、Instruct 模式等多种交互形式，可实时调整 Temperature、Top-p、Top-k、Repetition Penalty 等采样参数并即时观察效果变化。对于需要精细调控输出风格的场景非常实用。Ollama 通过 API 的方式暴露参数控制，调整参数需要修改请求 JSON 或 Modelfile 配置，交互性较弱，但适合程序化调用。功能丰富度Text Generation WebUI 支持 LoRA 加载、训练、模型合并、角色卡（Character Cards）、对话分支、Extensions 插件系统等高级功能，是模型实验和角色扮演场景的利器。Ollama 的功能集更聚焦——模型运行、API 服务、Modelfile 自定义，不提供训练或角色卡等功能。性能与部署Ollama 在推理速度和资源管理上优于 Text Generation WebUI，尤其是在模型加载/卸载、多模型切换等场景。Text Generation WebUI 基于 Gradio 构建，界面较重，多用户并发场景下性能瓶颈明显。何时选 Ollama需要 API 服务集成到应用中服务器部署场景，追求稳定和性能开发自动化工作流何时选 Text Generation WebUI需要可视化参数调优，实时观察模型输出变化角色扮演或创意写作场景LoRA 微调实验和模型合并需要插件扩展功能选型决策框架不同场景下的推荐方案：| 场景 | 推荐方案 | 理由 ||------|---------|------|| 个人学习/实验 | Ollama 或 LM Studio | 零门槛上手，消费级硬件可运行 || 本地开发 API 服务 | Ollama | OpenAI 兼容 API，自动模型管理 || 生产环境高并发 | vLLM | PagedAttention + Continuous Batching，6-16x 吞吐优势 || 从 OpenAI 迁移 | LocalAI | 完整 API 兼容，含 Function Calling 和多模态 || 需要图形界面 | LM Studio 或 Text Generation WebUI | 桌面端零代码操作 || 参数精细调优 | Text Generation WebUI | 实时可视化调参，LoRA 支持 || 多模态推理服务 | LocalAI | 一站式文本+图像+音频 |实际项目中，很多团队采用混合策略：本地开发用 Ollama 快速迭代，生产部署用 vLLM 保障性能，需要多模态时补充 LocalAI——三者都提供 OpenAI 兼容 API，在应用层切换几乎无感。