服务端面试题手册

C++11 起 是并发编程的核心。std::thread 创建线程，必须 join() 或 detach()，否则析构时 terminate。共享数据用 std::mutex 保护，lockguard 在作用域自动加解锁，uniquelock 支持手动加解锁和配合条件变量。conditionvariable 解决生产者-消费者问题：wait 释放锁并阻塞，notifyone/all 唤醒等待线程，注意用谓词版本 wait(lock, pred) 防虚假唤醒。std::atomic 无锁原子操作，支持 fetchadd、compareexchange_weak(CAS)，可选内存顺序。std::async 启动异步任务返回 future，get() 阻塞等结果。死锁避免：固定加锁顺序或用 std::lock 同时加多个锁。追问lockguard 和 uniquelock 有什么区别？lockguard 构造加锁析构解锁，不可手动控制，轻量。uniquelock 同样 RAII 但支持手动 lock/unlock、deferlock 延迟加锁、配合 conditionvariable 的 wait。只用简单的临界区保护用 lockguard，需要条件变量或灵活控制用 uniquelock。条件变量为什么会有虚假唤醒？POSIX 标准允许条件变量在没有 notify 的情况下唤醒，这是实现上的妥协。所以必须用 while 循环或谓词版本 wait(lock, pred) 检查条件，不能假设被唤醒就代表条件成立。memoryorderrelaxed 和 memoryorderseq_cst 有什么区别？relaxed 只保证原子操作本身的原子性，不保证操作间的顺序可见性，性能最好但容易出 bug。seqcst 是默认顺序，全局顺序一致，所有线程看到相同的操作顺序。绝大多数情况用默认 seqcst，只有确认安全的性能热点才降级到 acquire/release 或 relaxed。std::async 和直接创建 thread 有什么区别？async 返回 future，能拿到返回值和异常；thread 拿不到返回值，异常会导致 terminate。async 的 launch::policy：async 强制新线程，deferred 延迟到 get() 时在当前线程执行。默认策略由实现决定，要保证异步就传 launch::async。

STL 容器分四类。序列容器：vector 连续内存随机访问 O(1) 尾插 O(1) 中间插 O(n)；deque 双端队列两端 O(1)；list 双向链表任意位置 O(1) 但不支持随机访问。关联容器：map/set 基于红黑树有序 O(log n)，map 存键值对 set 存键。无序容器：unorderedmap/unorderedset 基于哈希表平均 O(1) 最坏 O(n)。容器适配器：stack（默认 deque）、queue（默认 deque）、priorityqueue（默认 vector+堆算法）。常用算法：sort O(nlogn)、find O(n)、copy、transform、accumulate。选容器先看需求：随机访问选 vector，频繁头插选 deque，频繁中间插选 list，查找为主选 unorderedmap/set，需要有序选 map/set。追问vector 扩容机制是什么？怎么避免？vector 满了重新分配更大内存（通常翻倍），把旧元素拷贝/移动过去，再释放旧内存。这会导致迭代器失效和性能抖动。提前 reserve(预估大小) 可避免运行时扩容，shrinktofit 可释放多余容量。map 和 unordered_map 怎么选？需要键有序遍历、范围查询用 map。只做查找/插入/删除不关心顺序用 unorderedmap，平均 O(1) 比 O(log n) 快。unorderedmap 的坑：最坏 O(n)（哈希冲突严重时）、自定义类型要手写 hash 函数和相等判断。什么操作会使迭代器失效？vector：insert/erase 当前位置及之后失效，reserve 后全部失效。list：只有被删除位置的失效，其他不受影响。map/set：只有被删除元素的失效。遍历中删除元素要用 it = container.erase(it) 模式。emplaceback 和 pushback 有什么区别？pushback 先构造临时对象再移动/拷贝进容器。emplaceback 直接在容器内存中原地构造参数，省去一次移动。对于简单类型差别不大，对复杂对象 emplace_back 更高效。

C++ 异常用 try/catch/throw 处理运行时错误。throw 抛出异常对象，catch 按类型匹配捕获，catch(…) 捕获所有异常。标准异常继承自 std::exception，分 logicerror（编程错误）和 runtimeerror（运行时错误）两大分支。自定义异常继承 std::runtimeerror 或 std::exception，重写 what() 返回错误信息。异常安全三个级别：基本保证（异常后对象仍有效）、强保证（异常后状态回滚）、不抛保证（noexcept）。RAII 是异常安全的基石——栈展开时局部对象的析构函数保证执行，智能指针和 lockguard 就是典型应用。析构函数绝不能抛异常，否则栈展开期间会调 terminate。noexcept 告诉编译器函数不抛异常，vector 扩容时会根据移动构造是否 noexcept 决定用移动还是拷贝。追问析构函数为什么不能抛异常？栈展开时如果析构函数再抛异常，C++ 运行时无法同时处理两个异常，直接调 std::terminate 程序崩溃。如果析构中调用的函数可能抛异常，用 try/catch 在析构函数内部吞掉。catch 的匹配顺序是怎样的？按出现顺序从上到下匹配，匹配第一个符合条件的 catch 就执行，不会找"最佳匹配"。所以要把最具体的异常类型放前面，std::exception 放后面，catch(…) 放最后。noexcept 函数里抛了异常会怎样？运行时调 std::terminate 直接结束程序，不会栈展开。所以给函数加 noexcept 要确认真的不会抛，或者内部全部 catch 了。但 noexcept 让编译器优化更激进，移动构造加 noexcept 后 vector 扩容会用移动而非拷贝，性能更好。异常和错误码怎么选？异常用于不可预期的错误（内存分配失败、文件打不开），错误码用于可预期的分支逻辑（查找失败、无效输入）。异常的缺点是有性能开销（栈展开、异常对象构造），且跨动态库边界可能出问题。性能敏感路径用 error_code 或 optional。

C++ 每个版本都有高频考点。C++11 最重要：auto 类型推导、range-for 循环、lambda 表达式（捕获列表是重点）、智能指针三件套（uniqueptr 独占、sharedptr 共享引用计数、weakptr 打破循环）、右值引用与移动语义（避免深拷贝）、nullptr 替代 NULL、constexpr 编译期计算。C++14 补充了泛型 lambda（参数用 auto）和 makeunique。C++17 重点：结构化绑定、if constexpr 编译期分支、optional/variant/any 三种可选类型、stringview 避免字符串拷贝。C++20 大更新：concepts 约束模板参数、ranges 组合式数据处理、协程（coyield/co_await）、modules 替代头文件、三路比较运算符 。追问uniqueptr 和 sharedptr 的主要区别是什么？uniqueptr 独占所有权，不可拷贝只能移动，零开销。sharedptr 引用计数共享所有权，拷贝时计数加一，有原子操作开销。优先用 uniqueptr，需要共享时才用 sharedptr，weakptr 解决 sharedptr 循环引用。移动语义解决了什么问题？右值引用（T&&）绑定到临时对象，移动构造/赋值直接"窃取"资源指针而非深拷贝。典型场景：函数返回大对象、vector 扩容时移动而非拷贝元素。std::move 本身不移动，只是把左值转成右值引用。lambda 捕获列表 [=] 和 [&] 有什么坑？[=] 按值捕获，若捕获 this 指针，实际捕获的是指针而非对象副本，对象析构后 this 悬空。[&] 按引用捕获，引用的局部变量出了作用域就失效。异步回调中用这两种捕获极易出 bug，推荐显式列出要捕获的变量。C++20 concepts 相比 SFINAE 有什么优势？concepts 用 requires 子句或 concept 名直接约束模板参数，编译错误信息可读，报错位置准确。SFINAE 用 enable_if，报错信息是一堆模板展开的乱码，调试困难。concepts 还能作为类型标注放在参数位置，代码更清晰。

C++ 设计模式面试常考的是单例、工厂、观察者和策略这四个。单例用 Meyer's Singleton（局部静态变量），线程安全且简洁。工厂模式分简单工厂和抽象工厂，核心是用虚函数延迟到子类决定创建哪种对象。观察者模式在事件系统中到处都是，注意生命周期管理。策略模式用组合替代继承，运行时切换算法。追问单例模式的线程安全怎么保证？Meyer's Singleton（函数内 static 局部变量）C++11 起保证线程安全，编译器自动加锁。不要用双重检查锁定（DCLP），早期 C++ 下有指令重排问题，现代 C++ 直接用 static 就行。抽象工厂和简单工厂有什么区别？简单工厂一个类通过参数决定创建哪种产品，违反开闭原则。抽象工厂定义接口，每个子类创建一族产品，新增产品族加子类即可，但新增产品类型要改所有工厂。观察者模式有什么坑？观察者持有主题的引用或指针，主题析构时观察者可能收到通知访问野指针。解注册要在观察者析构时做，推荐用 weak_ptr 打破循环引用。策略模式和模板方法模式怎么选？策略是组合，运行时通过指针/引用切换算法，灵活但有虚函数开销。模板方法是继承，编译期确定算法骨架，子类只重写部分步骤。需要运行时切换用策略，算法骨架固定用模板方法。

C++ 性能优化的核心原则是"先测量，再优化"。编译器层面，-O2 是发布标配，-O3 会启用更激进的自动向量化和循环展开但可能引入浮点精度变化；-flto 链接时优化让编译器跨翻译单元内联，-march=native 生成针对当前 CPU 的指令，非同构集群部署时禁用。内存层面，缓存命中率是第一瓶颈——CPU 从 L1 读数据约 1ns，从主存读约 100ns，差两个数量级；数据结构要按访问模式紧凑排列，避免伪共享（多线程各自原子递增同一缓存行的不同变量，每次都要跨核同步缓存行）。算法层面，选对容器比微优化重要百倍：vector 连续内存缓存友好，unordered_map 查找 O(1) 但每个桶都是堆分配的链表节点，随机访存对缓存不友好。并发层面，atomic 比 mutex 轻量但要选对 memory_order，无锁不等于高性能——CAS 自旋在竞争激烈时比互斥锁更慢。追问-O2 和 -O3 实际差多少？-O3 相比 -O2 额外开启循环向量化、循环内条件外提等优化。数值密集型计算在 -O3 下可能快 10-30%，但 -O3 会把 memcpy 语义的 struct 拷贝优化成逐成员赋值，可能破坏 volatile 语义；浮点运算会重排顺序导致精度差异。建议默认 -O2，对确定的热点模块单独开 -O3，配合 benchmark 验证。缓存友好的数据布局具体怎么做？核心思路：把经常一起访问的字段放在同一条缓存行（64 字节）。SoA（Structure of Arrays）——float x[N], y[N], z[N]，比 AoS（Array of Structures）缓存利用率更高。避免 vector<bool>，它用位压缩存储，比 vector<char> 慢 5-10 倍。伪共享问题用 alignas(64) 对齐解决。移动语义什么时候不生效？几种情况：对象没有移动构造函数；移动构造函数被隐式删除（类里有 const 或引用成员）；返回值优化（RVO）已经省去了拷贝/移动，此时 return std::move(local) 反而阻止了 RVO——直接 return local 让编译器做消除更好。atomic 的 memory_order 怎么选？默认 memory_order_seq_cst 最强但开销最大。acquire（读）+ release（写）是最常用的放松组合，适合生产者-消费者模型。relaxed 只保证原子性不保证顺序，适合计数器，绝对不能用来做同步标志。性能分析工具怎么用？perf record -g 采集调用栈，perf report 看热点函数。perf stat 看 IPC，IPC < 1 说明 CPU 在等内存，优化方向是缓存友好。valgrind --tool=cachegrind 模拟缓存行为。先看总耗时排名，再看 call count 判断单次调用是否才是瓶颈。

C++ 网络编程的核心是套接字（socket）加 I/O 多路复用。TCP 服务端流程：socket() 创建监听套接字 → bind() 绑定地址端口 → listen() 开始监听 → accept() 取出已连接套接字 → recv()/send() 读写数据。UDP 不需要 listen/accept，直接 recvfrom()/sendto() 收发数据报。当并发连接数上来后，需要 I/O 多路复用：select 用位图监控 fd 集合，每次调用都要重新构建，有 1024 个 fd 的上限；poll 用数组替代位图，没有数量限制，但仍然是 O(n) 遍历；epoll 是 Linux 专属方案，内核维护就绪队列，epoll_wait 只返回就绪的 fd，O(1) 复杂度，配合 EPOLLET 边缘触发模式可以进一步减少系统调用次数。生产环境几乎都选 epoll（Linux）或 kqueue（macOS/FreeBSD）。追问select、poll、epoll 各自适用什么场景？select 的优势是跨平台，连接数少于 100 且短连接为主时够用。poll 去掉了 1024 限制，但和 select 一样每次调用都要把全部 fd 从用户态拷贝到内核态，fd 数量到几千时性能明显下降。epoll 适合 C10K 甚至 C100K 场景：epoll_ctl 只在 fd 增删时调用一次，epoll_wait 只拷贝就绪 fd，不遍历全部。但 epoll 是 Linux 专有 API，跨平台项目用 Boost.Asio 或 libuv 封装层更好。LT（水平触发）和 ET（边缘触发）有什么区别？LT 模式下，只要 socket 上有数据没读完，epoll_wait 每次都会返回该 fd——你可以每次只读一部分，下次继续。ET 模式只在 socket 状态变化时通知一次，如果没读完数据，下次 epoll_wait 不会再返回，必须循环 recv 直到 EAGAIN。ET 模式效率更高（减少 epoll_wait 调用次数），但编程难度大：必须设非阻塞 + 循环读到底，漏读就会丢数据。Nginx 用 ET 模式，Redis 用 LT 模式。非阻塞 I/O 为什么要配合多路复用？单独设 O_NONBLOCK 后，recv 没数据时立刻返回 EAGAIN 而不是阻塞等待。但你不该用忙轮询来等数据——这会 100% 占满 CPU。多路复用的作用就是替你等待：epoll_wait 阻塞直到某个 fd 有数据可读，然后你调一次 recv 就能拿到数据。非阻塞 + epoll 的组合意义在于：epoll 通知你数据到了，但 recv 可能只读了一部分，非阻塞模式下你可以安全地循环读，不会因为没有更多数据而卡住。线程池模型怎么设计比较合理？常见模型：主线程 epoll_wait 检测到新连接，把已连接 fd 分发给工作线程处理。更好的方案是 One Loop Per Thread（muduo 模型）：每个线程各自跑一个 epoll 循环，主线程 accept 后通过 eventfd 唤醒某个工作线程注册该 fd，线程间无共享 fd 集合，扩展性更好。线程数一般设为 CPU 核心数，I/O 密集型可以翻倍。

C++ 智能指针通过 RAII 原则自动管理堆内存生命周期：对象在构造时获取资源，析构时释放资源，即使异常抛出也能保证析构函数执行。unique_ptr 表达独占所有权，不可拷贝只能移动，零开销抽象，性能等价于裸指针；shared_ptr 表达共享所有权，内部维护引用计数，最后一个 shared_ptr 析构时释放资源，引用计数操作是原子的所以线程安全，但指向对象本身的并发访问需要额外同步；weak_ptr 是 shared_ptr 的弱引用观察者，不增加引用计数，用来打破循环引用和实现缓存/观察者模式。优先用 make_unique/make_shared 创建智能指针：make_shared 一次分配同时构造对象和控制块，减少内存碎片且异常安全；直接 new 传给 shared_ptr 构造函数则分两次分配，且在函数参数求值顺序未定义时可能泄漏。追问uniqueptr 和 sharedptr 性能差异有多大？unique_ptr 零开销，析构直接 delete，编译后和裸指针一样。shared_ptr 的开销来自三处：一是控制块（强引用计数 + 弱引用计数）占 16 字节；二是拷贝/析构时原子操作引用计数，每次 fetch_add/fetch_sub 约 20-50ns；三是 make_shared 合并分配导致对象和控制块在同一内存块，即使所有 shared_ptr 释放了，只要还有 weak_ptr 持有控制块，对象占的内存就不会归还——这叫"对象悬挂"问题。高频场景下 shared_ptr 明显慢于 unique_ptr，但绝大多数业务代码中差异可以忽略。什么时候用 weak_ptr？不只是循环引用？最常见的场景确实是打破循环引用：双向链表 next 用 shared_ptr、prev 用 weak_ptr；观察者模式中 Subject 持有 vector<weak_ptr<Observer>>，通知时先 lock() 再调用，已销毁的 Observer 自动跳过。但 weak_ptr 还有两个实用场景：缓存系统用 weak_ptr 持有缓存对象，内存紧张时对象可以被释放，下次访问时 lock() 返回空再重新加载；工厂函数返回 weak_ptr 给调用者，工厂内部用 shared_ptr 管理生命周期，调用者通过 lock() 检查对象是否还活着。enablesharedfrom_this 是怎么回事？当一个对象已经被 shared_ptr 管理，在成员函数里需要把自己作为 shared_ptr 传出去时，必须用 enable_shared_from_this。直接 shared_ptr<this>(this) 会创建第二个控制块，引用计数从 1 开始，导致对象被 delete 两次。典型场景：异步回调里捕获 shared_from_this() 延长对象生命周期，确保回调执行时对象还没被销毁。前提是调用 shared_from_this() 时对象已经被 shared_ptr 管理——构造函数里调会抛 bad_weak_ptr 异常。自定义删除器怎么用？unique_ptr 的删除器是模板参数的一部分，类型不同就不能互相赋值。shared_ptr 的删除器是运行时参数，构造时传入就行，类型相同可以放在同一容器里。实际场景：管理 FILE* 用 fclose 作删除器、管理 POSIX 文件描述符用 close、管理 sqlite3* 用 sqlite3_close。

i18next 是 JavaScript 生态中最成熟的国际化框架，核心定位是"框架无关的翻译运行时"。它不绑定 React/Vue/Angular，核心库可以在 Node.js、浏览器、React Native 任何环境运行。核心特性包括：命名空间——把翻译按模块拆成多个 JSON，按需加载，避免单文件膨胀；插值——{{name}} 语法在翻译文本中嵌入动态值，支持格式化函数；复数——内置各语言的复数规则（英语 1 item / 2 items，阿拉伯语有 6 种复数形式），不需要手动判断；延迟加载——配合 i18next-http-backend 按语言+命名空间异步加载，首屏只拉当前语言的核心翻译；插件生态——语言检测、缓存、后端加载全部通过 .use() 注入，核心包保持精简。与 react-intl、vue-i18n 相比，i18next 的优势在于跨框架复用同一套翻译资源和配置逻辑，以及更灵活的插件体系。追问i18next 和 react-i18next 是什么关系？i18next 是纯翻译引擎，不关心 UI 框架。react-i18next 是 i18next 的 React 绑定层，提供 useTranslation hook、<Trans> 组件、withTranslation HOC。它通过 initReactI18next 插件把 i18next 实例挂到 React context 上，组件内调用 useTranslation() 时能响应语言切换并触发重渲染。不用 react-i18next 直接在 React 里调 i18next.t() 也行，但语言切换后组件不会自动更新——你得手动监听 languageChanged 事件再 forceUpdate。插值 {{}} 和 组件分别适合什么场景？简单变量替换用 {{name}} 插值：t('greeting', { name: '张三' })，翻译文件写 "greeting": "你好，{{name}}"。当翻译文本包含 React 组件（比如 <strong>、<Link>）时必须用 <Trans>：<Trans>阅读<Link to="/terms">条款</Link></Trans>，i18next 会把组件位置记录为索引占位符，翻译文件里写 "阅读<1>条款</1>"。混用没问题，但不要在 <Trans> 内部再嵌套 {{}} 做复杂逻辑，翻译人员看不懂。复数处理在不同语言下有什么坑？英语只需要 item 和 items 两个 key。斯拉夫语系（俄语、波兰语）有 3-4 种复数形式，阿拉伯语有 6 种，i18next 内置了 CLDR 复数规则能自动处理，但你得在翻译文件里提供完整的 key："item_zero"、"item_one"、"item_two"、"item_few"、"item_many"、"item_other"。常见坑是只写了 item 和 item_plural，切换到俄语时所有数量都回退到 item_other。另一个坑是 count 参数必须传数字类型，传字符串 "2" 不会触发复数逻辑。延迟加载的翻译在组件首次渲染时闪烁怎么办？i18next-http-backend 异步加载翻译，组件首次渲染时翻译还没到，t('key') 返回 key 本身。解决方案有三种：一是用 React Suspense 包裹根组件，useTranslation 内部会 suspend 直到翻译加载完成；二是检查 useTranslation 返回的 ready 状态，ready 为 false 时显示 loading；三是在 SSR 场景下把翻译资源预注入到 HTML，客户端直接从 window.__I18N_DATA__ 读取，跳过首次请求。方案一最简洁，但需要 React 18+ 的 Suspense 支持。

i18next 初始化配置是前端国际化的核心环节。i18next.init() 接收一个配置对象，最关键的几个选项：lng 设置当前语言，fallbackLng 指定翻译缺失时的回退语言，resources 直接内联翻译资源，ns 和 defaultNS 管理命名空间拆分。React 项目需要通过 initReactI18next 插件注入 i18next 实例，否则 useTranslation hook 无法工作。语言检测用 i18next-browser-languagedetector，可以按 querystring → cookie → localStorage → navigator 的顺序探测用户语言偏好。大型项目推荐用 i18next-http-backend 按需加载翻译文件，避免把所有语言的 JSON 打包进主 bundle。interpolation.escapeValue 在 React 中要设为 false，因为 React 自带 XSS 转义。开发阶段开启 debug: true 可以在控制台看到翻译 key 缺失的警告。追问resources 内联和 HTTP 后端加载怎么选？小项目（2-3 种语言、翻译总量不超过 50KB）直接内联 resources，启动快、无额外请求。中大型项目用 i18next-http-backend，翻译文件按语言和命名空间拆成独立 JSON，首屏只加载当前语言的 translation 命名空间，其他页面切换时再按需加载。注意 HTTP 后端是异步的，init() 返回的 Promise resolve 之前组件渲染会拿到空翻译，需要配合 React Suspense 或 useTranslation 的 ready 状态处理。命名空间怎么划分比较合理？常见做法是 translation（公共文案）、common（按钮/标签等高频复用）、validation（表单校验提示）、errors（错误码映射）。按页面拆命名空间（如 home、profile）也可以，但粒度太细会增加维护成本——每个命名空间对应一个 JSON 文件，翻译人员要在多个文件间切换。实际项目中 3-6 个命名空间基本够用，超过 10 个就该考虑合并了。fallbackLng 配置不当会导致什么问题？fallbackLng 默认是 "dev"，翻译缺失时 key 会直接显示在页面上。如果设为 "en"，中文用户看到的是中英混杂的界面——部分 key 有中文翻译，缺失的回退到英文。更隐蔽的问题：fallbackLng 设为数组 ["zh", "en"] 时，i18next 会按顺序查找，key 查找链变长影响性能。建议设为项目的主要语言（比如 "zh"），开发时靠 debug: true 发现缺失的 key，而不是依赖 fallback 兜底。init() 的回调写法和 Promise 写法有什么区别？回调写法 i18next.init(config, (err, t) => {...}) 在 i18next 早期版本就支持，t 函数在回调里直接可用。Promise 写法 await i18next.init(config) 更直观，但要注意 HTTP 后端加载时 Promise resolve 不代表所有命名空间都加载完了——如果配置了 partialBundledLanguages，部分命名空间可能是异步加载的。React 项目一般用 initReactI18next 中间件，内部处理了等待逻辑，不需要手动处理回调。

i18next 的插值通过 {{variable}} 语法实现变量替换，如 t('hello', { name: 'Tom' }) 对应翻译文件中 Hello {{name}}。数组插值用 {{arr,0}} 按索引取值。嵌套插值用 $t(key) 引用其他翻译条目，实现翻译文本的复用。复数处理根据语言类型自动匹配：英语等单复数语言使用 key_one/key_other 后缀，俄语等有复杂复数规则的语种遵循 CLDR 规范自动映射对应后缀（如 key_zero/key_one/key_few/key_many/key_other）。上下文功能通过 context 选项让同一 key 根据语境返回不同翻译，如 t('friend', { context: 'male' }) 匹配 friend_male。格式化方面，i18next 内置 format 函数，可自定义格式化器处理日期、数字等，插值时通过 {{value, formatter}} 调用。转义默认开启，{{var}} 输出 HTML 转义后的值，{{-var}} 输出原始值，用于嵌入 HTML 片段。追问复数后缀的完整规则是什么？英语只需 _one 和 _other。斯拉夫语系需要完整的 CLDR 后缀：_zero（0个）、_one（1个）、_few（2-4个）、many（5-20个）、other（其余）。阿拉伯语还有 _two 后缀。i18next 内置了 CLDR 复数规则，只需按规范提供对应后缀的翻译条目即可自动匹配。context 和复数可以组合吗？可以。格式为 key_context_plural，如 friend_male_one。i18next 会按 key_context_plural → key_context → key_plural → key 的顺序回退查找：{ "friend_male_one": "一个男朋友", "friend_male_other": "{{count}}个男朋友"}如何自定义格式化函数？在 init 时注册：i18n.init({ interpolation: { format: (value, format, lng) => { if (format === 'date') return new Intl.DateTimeFormat(lng).format(value); if (format === 'uppercase') return value.toUpperCase(); return value; } }});翻译文件中使用 {{date, date}}、{{name, uppercase}} 调用。$t 嵌套插值有什么限制？$t() 不能循环引用，否则会抛出异常。嵌套深度没有硬限制但不建议超过 2 层，影响可读性和性能。$t() 引用的 key 仍可接收插值参数：$t(greeting, { "name": "Tom" })。

react-i18next 是 i18next 的 React 绑定层，核心 API 有三个：useTranslation Hook、withTranslation HOC、Trans 组件。useTranslation 是最常用的方式，返回 t 函数和 i18n 实例，组件内调用 t('key') 即可获取翻译文本，语言切换时自动重渲染。withTranslation 是类组件的对应方案，通过 props 注入 t 函数。Trans 组件用于处理含 HTML 标签的翻译，如 Hello <bold>World</bold>，翻译文件中对应 Hello <1>World</1>，避免用 dangerouslySetInnerHTML。I18nextProvider 用于向组件树注入 i18n 实例，通常在根组件外层包裹一次即可。Suspense 配合方面，当使用异步加载后端时，翻译资源未就绪会触发 Suspense fallback，需在 init 时设置 react.useSuspense: true。追问useTranslation 如何指定命名空间？const { t } = useTranslation('common');t('greeting'); // 读取 common 命名空间的 key// 同时使用多个命名空间const { t } = useTranslation(['common', 'auth']);t('common:title');t('auth:login');Trans 组件的索引规则是什么？Trans 按子元素出现顺序编号，从 0 开始，纯文本节点不占索引（旧版行为），标签节点占索引。React 中组件包裹也算一个节点：<Trans>Read <a href="/doc">the doc</a> for details</Trans>// 翻译文件：Read <1>the doc</1> for details空字符串节点和换行符是否占索引取决于 i18next 版本，建议用 i18next-parser 自动提取。类组件如何使用 react-i18next？import { withTranslation } from 'react-i18next';class MyComponent extends React.Component { render() { const { t } = this.props; return <p>{t('hello')}</p>; }}export default withTranslation()(MyComponent);withTranslation 支持 withTranslation(['ns1', 'ns2']) 指定命名空间。Suspense 模式下加载失败怎么处理？在 Suspense 外层的 ErrorBoundary 中捕获加载异常，展示降级 UI。也可关闭 Suspense 模式，改用 t() 的 fallback key 机制：t('key', '默认文本')，当资源未加载时直接返回默认值。

i18next-http-backend 是 i18next 官方的远程翻译资源加载插件，核心配置项 loadPath 指定资源 URL 模板，支持 {{lng}} 和 {{ns}} 占位符，插件会在初始化或切换语言时自动请求对应 JSON 文件。savePath 用于回写（如新增 key 时持久化），默认 /locales/add/{{lng}}/{{ns}}。自定义请求可通过 request 选项替换默认 fetch 实现，适用于需要加鉴权头或自定义错误处理的场景。缓存方面，配合 i18next-localstorage-backend 可将已加载资源缓存到浏览器本地，设定过期时间避免重复请求。重试机制通过 reloadInterval 控制定时重新加载，也可在加载失败时调用 i18n.reloadResources() 手动触发。SSR 场景下使用 i18next-fs-backend 从文件系统读取资源，接口与 http-backend 一致。追问如何给请求添加自定义 Header？通过 request 选项覆盖默认实现：backend: { loadPath: '/api/locales/{{lng}}/{{ns}}', request: (url, payload, callback) => { fetch(url, { headers: { Authorization: 'Bearer xxx' } }) .then(res => res.json()) .then(data => callback(null, { data, status: 200 })) .catch(err => callback(err)); }}如何实现多语言批量加载？设置 allowMultiLoading: true，loadPath 中使用 {{lng}} 和 {{ns}} 会以 + 连接多个值，服务端需支持返回合并后的 JSON。例如请求 /locales/en+zh/common+admin 返回对应结构，减少请求次数。加载失败如何降级？配置 backend 的同时设置 fallbackLng，当目标语言资源加载失败时 i18next 会回退到 fallback 语言。也可监听 failedLoading 事件做上报和兜底提示：i18n.on('failedLoading', (lng, ns, msg) => { console.error(`${lng}/${ns} 加载失败:`, msg);});SSR 中如何使用 fs-backend？const FsBackend = require('i18next-fs-backend');i18n.use(FsBackend).init({ backend: { loadPath: './locales/{{lng}}/{{ns}}.json' }});读取本地文件系统而非发 HTTP 请求，接口与 http-backend 一致，SSR 预渲染时确保同步拿到翻译内容。

i18next 性能优化的核心思路是减少首次加载体积和降低不必要的重渲染。延迟加载命名空间是最直接的手段，将非关键翻译（如后台管理页面的文案）设为按需加载，首屏只加载 common 等必要命名空间。配合 i18next-http-backend 实现翻译资源的远程加载，避免将全部语言的 JSON 打进 JS Bundle。语言维度同样按需加载，当前语言加载完毕后再预加载用户可能切换的语言。Bundle 层面，i18next 内部依赖了 lodash，应使用 lodash-es 或手动替换为轻量实现以支持 tree-shaking。React 侧，react-i18next 的 useTranslation 已做细粒度订阅，只监听当前 key 对应的命名空间变化，但仍需避免在渲染函数中频繁调用 t() 生成复杂字符串导致子组件不必要更新，可通过 memo 或提取翻译结果到变量来规避。追问如何配置命名空间按需加载？i18n.use(HttpBackend).init({ ns: ['common', 'admin'], defaultNS: 'common', backend: { loadPath: '/locales/{{lng}}/{{ns}}.json' }});// 页面中按需加载const { t } = useTranslation('admin');访问组件时 admin 命名空间才会被请求。预加载其他语言怎么做？i18n.loadLanguages(['ja', 'ko']).then(() => { // 日韩资源已缓存，切换无延迟});适合在用户 hover 语言切换按钮时触发。localStorage-backend 缓存策略是什么？i18next-localstorage-backend 将请求到的翻译 JSON 存入 localStorage，设置过期时间（默认 7 天）。下次加载直接读缓存，跳过网络请求。需注意缓存失效后的更新策略，可在 allowMultiLoading 模式下批量更新。如何减少 React 重渲染？useTranslation 默认只订阅当前命名空间的语言变化。若组件只用到 t('key')，可指定 keyPrefix 缩小订阅范围。对纯展示组件使用 React.memo 包裹，或将翻译结果作为 props 传入，避免因语言上下文变化导致整棵子树重渲染。

i18next 通过 i18next-browser-languagedetector 插件实现语言检测，默认按 querystring → cookie → localStorage → navigator → htmlTag 的顺序依次探测，命中即停止。检测结果默认写入 localStorage 和 cookie 做持久化，可通过 cacheUserLanguage 自定义缓存方式。手动切换语言调用 i18n.changeLanguage('zh')，该方法内部会重新触发初始化流程并发出 languageChanged 事件。在 React 中，react-i18next 订阅了该事件，语言切换后自动触发组件重渲染。服务端场景下不使用浏览器检测插件，而是从请求头 Accept-Language 或 URL 路径中提取语言标识。追问检测顺序可以自定义吗？可以。配置 order 数组即可调整检测顺序或增删检测源：i18n.use(LanguageDetector).init({ detection: { order: ['localStorage', 'navigator'] }});如何让用户首次访问时默认使用某种语言？设置 lookupQuerystring、lookupCookie 等对应的 key，并在缓存中预写该值。更直接的方式是配置 supportedLngs 和 fallbackLng，当检测到的语言不在支持列表内时回退到 fallbackLng。changeLanguage 是异步的吗？是的，它返回 Promise。切换后需等待资源加载完成再渲染内容，否则会显示旧语言或 fallback 文本：await i18n.changeLanguage('ja');// 此时新语言资源已就绪服务端如何实现语言检测？SSR 中不引入浏览器检测插件，一般从 req.headers['accept-language'] 解析，或根据 URL 前缀（如 /en/about）提取。解析结果通过 i18n.changeLanguage() 注入当前请求实例。每个请求应使用独立的 i18n 实例，避免语言状态跨请求污染。

测试 i18next 分三层：翻译函数本身、React 组件集成、边界情况（缺失 key、懒加载）。翻译函数测试最简单——初始化一个独立的 i18next 实例，注入 mock 翻译资源，断言 t('key') 的返回值，覆盖简单 key、插值（{{name}}）、复数形式。React 组件测试需要用 I18nextProvider 包裹被测组件，传入配置好的 i18n 实例，这样组件内的 useTranslation 和 Trans 才能正常工作。语言切换测试调用 i18n.changeLanguage() 后用 waitFor 断言 UI 文案变化。缺失 key 测试开启 saveMissing: true，配合 missingKeyHandler 断言回调被调用，或直接断言 t('nonexistent') 返回 key 本身作为 fallback。追问为什么不用真实的翻译文件跑测试，而要 mock 资源？真实翻译文件会变——翻译团队随时可能改文案，如果测试断言了具体翻译文本，每次文案调整测试就挂了。mock 资源让测试只关心"key 能正确解析"这个逻辑，不绑定具体文案内容。另外 mock 资源体积小、加载快，避免测试里引入大量 JSON 文件。最佳实践：mock 资源只放测试需要的 key，用 i18next.createInstance() 隔离，避免测试间互相污染。Trans 组件和 t() 函数测试有什么区别？t() 是纯函数，输入 key 和参数返回字符串，测试最简单。Trans 组件渲染包含 HTML 标签的翻译内容（如 Welcome <1>{{name}}</1>），需要验证组件嵌套是否正确，不能只断言文本内容——Trans 可能渲染出 <strong>John</strong> 也可能渲染出纯文本 John，取决于翻译 key 的定义。测试 Trans 时要用 container.innerHTML 或 within 查询，确认标签结构正确，而不仅是文本存在。命名空间怎么测试？懒加载命名空间呢？命名空间测试关键是每个命名空间独立初始化资源，断言 t('ns:key') 能正确解析跨命名空间 key。懒加载命名空间测试用 useSuspense: false 模式——组件先渲染 loading 状态（ready 为 false），然后通过 addResourceBundle 手动注入资源，用 waitFor 断言组件渲染出翻译内容。注意懒加载测试不要用 Suspense 包裹，否则 React Testing Library 无法捕获 loading 态。快照测试适合 i18next 吗？有什么坑？不太适合。快照会把翻译文案写死到 .snap 文件里，翻译改了快照就挂，维护成本高。而且快照只能告诉你"渲染结果和之前一样"，不能告诉你翻译是否正确。如果一定要用，只对组件结构做快照（用 render 后取 asFragment()），不要断言具体翻译文本。更好的替代方案是用 t() 的 mock 验证调用参数是否正确，而不是验证返回值。// 独立实例 + mock 资源的翻译测试import i18next from 'i18next';describe('i18next translations', () => { let i18n; beforeEach(() => { i18n = i18next.createInstance(); i18n.init({ lng: 'en', resources: { en: { translation: { hello: 'Hello', greet: 'Hi {{name}}' } }, zh: { translation: { hello: '你好', greet: '你好 {{name}}' } } } }); }); test('简单 key', () => expect(i18n.t('hello')).toBe('Hello')); test('插值', () => expect(i18n.t('greet', { name: 'Li' })).toBe('Hi Li')); test('缺失 key 返回 key 本身', () => expect(i18n.t('missing')).toBe('missing'));});// React 组件测试（I18nextProvider 包裹）import { I18nextProvider } from 'react-i18next';import { render, screen, waitFor } from '@testing-library/react';function Greeting() { const { t, i18n } = useTranslation(); return <> <span>{t('hello')}</span> <button onClick={() => i18n.changeLanguage('zh')}>切换</button> </>;}test('语言切换', async () => { render(<I18nextProvider i18n={i18n}><Greeting /></I18nextProvider>); expect(screen.getByText('Hello')).toBeInTheDocument(); fireEvent.click(screen.getByText('切换')); await waitFor(() => expect(screen.getByText('你好')).toBeInTheDocument());});

WebSocket 连接管理围绕生命周期展开：建立、保活、重连、清理。建立时客户端发起连接，服务端做鉴权和元数据登记（用户 ID、设备信息），然后双方进入通信状态。保活用心跳机制——客户端定时发 ping，服务端回 pong，超时未收到 pong 则认为连接已死，这是检测"半开连接"（对端已断开但本端不知道）的唯一可靠手段。重连是客户端的职责，核心策略是指数退避：首次 1 秒后重试，之后 2s、4s、8s，上限 30s，避免服务端刚恢复就被雪崩式重连打垮。加随机抖动（jitter）防止大量客户端同时重连。清理是关闭连接后释放定时器、事件监听器、内存中的消息队列等资源，避免泄漏。追问指数退避为什么要加随机抖动？如果 1000 个客户端同时断线，都在 1s、2s、4s 后重连，会出现"惊群效应"——服务端刚恢复就被第一波重连打垮，然后再次宕机，下一波重连又打垮，形成恶性循环。加 jitter（如 delay = baseDelay * 2^retry + Math.random() * 1000）让各客户端的重连时间错开，将瞬间冲击分散到时间窗口内。AWS 和 Google 的重连库都默认启用 jitter。心跳间隔设多少合适？太短和太长各有什么问题？通常 30 秒。太短（如 5 秒）会浪费带宽和服务端资源，10 万连接每 5 秒 ping 一次就是 2 万次/秒；太长（如 120 秒）无法及时发现半开连接，用户可能等 2 分钟才知道消息收不到了。移动端建议 30-45 秒，服务端 idle timeout 设为心跳间隔的 2-3 倍（如 90 秒），给网络波动留余量。Nginx 代理 WebSocket 时也要配置 proxy_read_timeout 与之一致。连接池在什么场景下需要？单连接不够用吗？浏览器对同一域名的 WebSocket 连接数没有硬限制（不像 HTTP/1.1 的 6 个），所以大多数场景单连接就够了，在应用层做消息多路复用（通过 type 字段区分业务）。需要连接池的场景：不同业务域隔离（聊天和行情走不同连接，避免互相阻塞）；大规模数据传输（单连接带宽不够时分流）；高可用（主连接断开时备用连接无缝切换）。不要为了"看起来专业"而引入连接池，多连接意味着多倍的心跳和内存开销。页面切换或组件卸载时 WebSocket 连接怎么处理？SPA 路由切换时不要断开重连，把 WebSocket 实例提升到全局（Redux store 或 Context），路由组件只订阅/取消订阅消息，连接本身持续存在。组件卸载时必须移除事件监听器，否则闭包引用的旧 state 会导致内存泄漏和僵尸回调。页面真正关闭（beforeunload）时发关闭帧优雅断开。React 项目推荐用自定义 Hook 封装，useEffect 的 cleanup 中移除 listener。// 指数退避 + 随机抖动重连function createReconnectingWebSocket(url) { let ws; let retryCount = 0; const maxRetries = 10; const baseDelay = 1000; const maxDelay = 30000; function connect() { ws = new WebSocket(url); ws.onopen = () => { retryCount = 0; // 连接成功，重置计数 }; ws.onclose = (event) => { if (event.code === 1000 || retryCount >= maxRetries) return; const delay = Math.min(baseDelay * Math.pow(2, retryCount), maxDelay) + Math.random() * 1000; // 随机抖动 retryCount++; setTimeout(connect, delay); }; } connect(); return ws;}// 心跳机制function startHeartbeat(ws, interval = 30000) { const timer = setInterval(() => { if (ws.readyState === WebSocket.OPEN) { ws.ping(); // 或 ws.send(JSON.stringify({ type: 'ping' })) } }, interval); return timer; // 组件卸载时 clearInterval(timer)}

WebSocket 的安全威胁主要来自四方面：窃听、劫持、伪造和洪泛。防护的核心是强制 WSS（TLS 加密）防止窃听，验证 Origin 头防止跨站 WebSocket 劫持（CSWSH），在握手阶段或首条消息中完成身份认证防止伪造，速率限制和消息校验防止洪泛和注入攻击。WSS 是底线——ws:// 明文传输下，中间人可以读取甚至篡改所有消息。Origin 验证同样关键：浏览器发起 WebSocket 连接时会自动携带 Cookie，如果服务端不校验 Origin，恶意页面可以伪造用户身份建立连接（即 CSWSH 攻击）。认证方面，URL 查询参数传 token 会泄露到日志，更安全的做法是连接建立后通过首条消息发送 JWT，服务端验证失败立即关闭连接（code=1008）。追问CSWSH 攻击是怎么发生的？和 CSRF 有什么区别？CSWSH 利用浏览器自动携带 Cookie 的特性：恶意网站用 JS 创建 new WebSocket('wss://victim.com/socket')，浏览器会带上 victim.com 的 Cookie，服务端如果只看 Cookie 不看 Origin，就会把连接当作合法用户。和 CSRF 的区别在于：CSRF 只能触发请求不能读取响应（同源策略限制），而 WebSocket 连接建立后恶意页面可以双向通信、读取服务端推送的敏感数据，危害更大。防护就是服务端必须校验 Origin 头。URL 参数传 Token 和连接后发认证消息，哪个更安全？连接后发认证消息更安全。URL 参数中的 token 会被记录在服务端访问日志、浏览器历史、代理日志中，且很难清除。连接后发消息的方式 token 只在 WebSocket 帧中传输，WSS 加密后中间人看不到。但连接后认证有一个窗口期：连接已建立但未认证，这段时间内服务端不能处理任何业务消息。实践中两者可以组合——URL 传短期一次性 ticket，连接后再用 JWT 换取长期会话。WebSocket 上的 XSS 攻击怎么防？WebSocket 传输的文本如果直接插入 DOM（innerHTML），和 HTTP 一样存在 XSS 风险。防护手段：消息内容做 HTML 转义后再渲染，或用 textContent 替代 innerHTML；服务端过滤消息中的 <script>、javascript:、onerror= 等危险模式；消息大小限制（如 10KB）防止超长 payload；消息结构白名单校验，只允许预定义的 type 字段。记住 XSS 的根源是渲染层，不是传输层。怎么防止 WebSocket 连接被用于 DDoS？服务端侧：限制单 IP 最大连接数（如 50），超出拒绝握手；单连接消息速率限制（如每分钟 100 条），超限断开；消息体积上限（如 64KB），防止内存炸弹；空闲连接超时断开（idleTimeout）。架构层：前端用 Nginx 做 WebSocket 代理，配置 limit_conn 和 limit_req；启用 DDoS 防护服务（Cloudflare 等）；连接鉴权增加攻击成本，未认证的连接快速关闭不占资源。// 服务端安全校验示例wss.on('connection', (ws, req) => { // 1. Origin 校验 const origin = req.headers.origin; if (!['https://yourdomain.com'].includes(origin)) { return ws.close(1003, 'Forbidden origin'); } // 2. 身份认证（首条消息） ws.authenticated = false; ws.once('message', (msg) => { const { type, token } = JSON.parse(msg); if (type !== 'auth') return ws.close(1008, 'Auth required'); try { const user = jwt.verify(token, SECRET); ws.authenticated = true; ws.userId = user.id; } catch { return ws.close(1008, 'Invalid token'); } }); // 3. 速率限制 ws.messageCount = 0; ws.on('message', () => { ws.messageCount++; if (ws.messageCount > 100) ws.close(1008, 'Rate limit'); });});

WebSocket 性能优化集中在三个层面：协议层压缩与传输格式、应用层消息策略、架构层连接管理。协议层最有效的是启用 permessage-deflate 扩展，文本消息可压缩 60-80%，但小消息（<1KB）压缩反而增加开销，建议设 threshold=1024，压缩级别用 3（速度与压缩率平衡）。传输格式上，大数据场景用二进制（ArrayBuffer/TypedArray）替代 JSON 字符串，解析更快、体积更小；高频结构化消息可用 Protocol Buffers 或 MessagePack 替代 JSON。应用层关键是消息批处理，把短时间内的多条小消息合并成一条发送，减少网络往返次数。架构层用连接池复用连接、用 uWS 替代 ws 库（性能高 10-20 倍）、通过 Redis Pub/Sub 分发消息实现多进程横向扩展。追问permessage-deflate 压缩在什么场景下反而降低性能？消息小于 1KB 时压缩开销大于收益，因为压缩本身消耗 CPU，且 deflate 帧头和上下文开销可能让数据反而变大。高并发场景下 CPU 是瓶颈，压缩会加剧竞争。实践中建议设 threshold 只压缩大消息，或者在 CPU 占用超过 70% 时关闭压缩。另外 clientNoContextTakeover: true 可以限制服务端内存占用，但会降低压缩率。消息批处理的延迟和吞吐怎么取舍？批处理本质是用延迟换吞吐——攒一批再发，单次传输数据量更大，网络效率更高，但接收端看到消息的时间晚了。实时聊天场景 batchTimeout 不宜超过 50ms，行情推送可设 100-200ms。可以动态调整：消息积压多时加大 batch 减少发送次数，消息稀疏时减小 timeout 保证低延迟。为什么 uWS 比 ws 库快那么多？有什么代价？uWS 用 C++ 编写，直接操作 epoll/kqueue，避免了 Node.js 事件循环的开销；ws 库是纯 JS 实现，每条消息都经过 V8 的 JS/C++ 边界。代价是 uWS 的 API 不兼容 ws，调试困难，社区生态小，遇到问题难以排查；而且它不支持 permessage-deflate 的所有配置项。对性能要求不极致的项目，ws 的开发效率更高。如何监控 WebSocket 连接的性能瓶颈？核心指标：单连接消息吞吐量（条/秒）、端到端延迟（ping-pong RTT）、服务端内存和 fd 占用、消息队列积压深度。用 PerformanceObserver 或自定义中间件采集每个连接的发送/接收字节数和延迟分布，P99 延迟超过 200ms 或内存持续增长说明有瓶颈。线上可用 Prometheus + Grafana 做大盘，重点关注连接数突增和消息积压告警。// permessage-deflate 配置示例（Node.js ws 库）const wss = new WebSocket.Server({ perMessageDeflate: { threshold: 1024, // 超过 1KB 才压缩 zlibDeflateOptions: { level: 3, // 压缩级别，3 是速度与压缩率平衡点 concurrency: 10 }, clientNoContextTakeover: false, // 允许上下文复用，压缩率更高 serverNoContextTakeover: false }});// 消息批处理class MessageBatcher { constructor(ws, batchSize = 10, batchTimeout = 100) { this.ws = ws; this.queue = []; this.timer = null; this.batchSize = batchSize; this.batchTimeout = batchTimeout; } add(msg) { this.queue.push(msg); if (this.queue.length >= this.batchSize) this.flush(); else if (!this.timer) { this.timer = setTimeout(() => this.flush(), this.batchTimeout); } } flush() { if (!this.queue.length) return; this.ws.send(JSON.stringify({ type: 'batch', messages: this.queue })); this.queue = []; clearTimeout(this.timer); this.timer = null; }}

WebSocket 是基于 TCP 的全双工通信协议，属于 HTML5 规范的一部分。与 HTTP 最大的区别在于通信模式：HTTP 是请求-响应模型，客户端发起请求后服务端才能返回数据，每次请求都携带完整头部（数百字节），连接完即断；WebSocket 通过 HTTP Upgrade 机制握手一次（客户端发送 Upgrade: websocket 头，服务端返回 101 Switching Protocols），之后在同一条 TCP 连接上双方可随时互发数据，头部开销仅 2-10 字节。这意味着服务端可以主动推送，延迟从 HTTP 轮询的数百毫秒降到毫秒级，适合聊天、实时行情、协同编辑、在线游戏等场景。WebSocket 连接是持久的，除非任一方发送关闭帧或网络中断，否则连接一直保持。追问WebSocket 握手为什么基于 HTTP？能不能跳过 HTTP 直接建立连接？不能跳过。WebSocket 复用 HTTP 握手是为了兼容现有基础设施——浏览器先发一个标准 HTTP GET 请求（携带 Upgrade 头），中间的代理、负载均衡、防火墙都能识别并放行；如果直接用新协议，这些中间件会拒绝或破坏连接。握手成功后协议才切换为 WebSocket，之后的数据帧完全脱离 HTTP 格式。HTTP/2 的 Server Push 能替代 WebSocket 吗？不能。HTTP/2 Server Push 是服务端主动推送资源到浏览器缓存，本质还是服务于请求-响应模型，客户端无法通过 JavaScript 读取推送的原始内容；而且 Push 的资源受浏览器缓存策略控制，不适合实时数据流。WebSocket 是真正的双向消息通道，客户端可以用 JS 直接处理每一条推送消息。WebSocket 连接断开时如何判断是网络问题还是服务端主动关闭？WebSocket 关闭帧（Close Frame）携带状态码：1000 表示正常关闭，1001 表示端点离开，1006 表示异常关闭（没有收到关闭帧，通常是网络中断）。浏览器 onclose 事件的 code 和 reason 字段可以区分：code=1006 是网络问题需要重连，code=1000/1001 是正常关闭不需要重连。大量 WebSocket 连接会压垮服务端吗？怎么控制？会。每个 WebSocket 连接占用一个文件描述符和内存（约 10-50KB），单机默认 fd 上限通常 65535。控制手段：用 ulimit -n 或 systemd 调高 fd 上限；设最大连接数阈值超限拒绝；用 Redis Pub/Sub 做跨进程消息分发，单机只维护本机连接；横向扩展用 sticky session 或网关层路由，把同一用户的连接固定到同一后端。// WebSocket 握手过程示例const ws = new WebSocket('wss://example.com/socket');ws.onopen = () => { console.log('连接已建立，协议已升级'); ws.send('hello'); // 直接发送，无需 HTTP 请求};ws.onmessage = (event) => { console.log('收到服务端推送:', event.data);};ws.onclose = (event) => { console.log('关闭码:', event.code, '原因:', event.reason); // code=1006 说明是异常断开，需要重连};