面试题手册

C++ 提供三种智能指针，均位于 <memory> 头文件。unique_ptr 独占所有权，不可拷贝只能移动，开销接近裸指针，是默认首选。shared_ptr 共享所有权，内部维护引用计数，最后一个持有者销毁时释放资源，拷贝和赋值增加计数。weak_ptr 是 shared_ptr 的观察者，不增加引用计数，通过 lock() 获取临时 shared_ptr 访问对象，用于打破循环引用。make_unique 和 make_shared 在单次分配中同时构造对象和控制块（后者），比单独 new 更高效且异常安全。自定义删除器允许在析构时执行特定操作，如 unique_ptr<FILE, decltype(&fclose)> 或传入 lambda 关闭文件句柄、释放 C 库资源。选择原则：独占用 unique_ptr，共享用 shared_ptr，观察用 weak_ptr，尽量避免混用裸指针持有所有权。追问makeshared 比 sharedptr(new T) 好在哪？make_shared 一次分配同时容纳对象和控制块，减少一次内存分配，且提高缓存局部性。但会延迟对象内存释放：即使引用计数归零，若 weak_ptr 仍存在，对象内存不会回收，直到 weak_ptr 也销毁。uniqueptr 的自定义删除器为什么比 sharedptr 更重？unique_ptr 的删除器类型是模板参数的一部分，影响指针类型本身，可能导致不同的 unique_ptr 类型不兼容。shared_ptr 的删除器类型在运行时擦除，不影响 shared_ptr<T> 类型，使用更灵活。智能指针线程安全吗？控制块（引用计数）的修改是原子的，shared_ptr 拷贝/析构线程安全。但访问所指对象不是线程安全的，多线程读写对象本身仍需加锁。unique_ptr 整体非线程安全，移动操作需外部同步。什么时候仍需要裸指针？不涉及所有权时用裸指针或引用作为观察者，如函数参数传递、遍历容器元素。裸指针不管理生命周期，只是访问地址，比 weak_ptr 更轻量。

C++ 程序的内存分为栈（自动管理，函数结束释放）、堆（手动 new/delete）、全局/静态区（程序生命周期）和常量区（只读）。堆内存需开发者显式申请和释放，是内存泄漏的重灾区。泄漏的常见原因：new 后忘记 delete、异常导致跳过 delete、指针被覆写丢失地址。检测工具中，Valgrind 在运行时插桩检查，AddressSanitizer（ASan）由编译器插桩，开销更小、报错更直接。现代 C++ 的核心防御手段是 RAII 原则：资源获取即初始化，将资源生命周期绑定到栈对象，析构时自动释放。智能指针是 RAII 的典型应用：unique_ptr 独占所有权离开作用域自动释放，shared_ptr 引用计数归零释放，基本取代裸 new/delete。常见陷阱包括：悬空指针（访问已释放内存）、双重 delete（同一指针释放两次）、delete 配 new[] 或 delete[] 配 new 导致未定义行为。追问栈和堆的分配速度差异为何这么大？栈分配只需移动栈顶指针，相当于一次整数加法。堆分配需遍历空闲链表查找合适块，可能触发系统调用（brk/mmap），还涉及内存碎片整理。AddressSanitizer 和 Valgrind 怎么选？开发阶段优先 ASan：编译时加 -fsanitize=address，运行开销约 2x，报错精确到源码行。Valgrind 无需重编译，但开销 10-20x，适合测试第三方二进制或无法重编译的场景。循环引用导致 shared_ptr 泄漏怎么办？将其中一方改为 weak_ptr，它不增加引用计数，打破循环。访问时通过 lock() 提升为 shared_ptr，若对象已释放则返回空。RAII 只适用于内存吗？不是。文件句柄、锁（lock_guard）、网络连接、数据库连接等有限资源都适用 RAII。核心思想是资源生命周期与对象绑定，析构函数负责释放。

模板特化允许为特定类型提供与通用版本不同的实现。全特化指定所有模板参数，为某一具体类型提供完全定制版本，全特化后的模板不再有模板参数。偏特化仅适用于类模板和变量模板，对部分参数做约束，保留剩余参数的通用性。例如 template<typename T> class A<T*> 为所有指针类型提供统一实现，T 仍为参数。函数模板不支持偏特化，只能用重载或全特化替代。SFINAE（替换失败并非错误）是模板元编程的基础规则：在模板实参替换阶段，若某个候选的替换导致类型错误，该候选被静默剔除而非编译报错。std::enable_if 利用 SFINAE，通过条件编译控制模板是否参与重载决议，是 C++17 之前约束模板的主要手段。追问全特化和偏特化的实例化优先级如何？编译器优先选择最特化的版本。全特化比偏特化更特化，偏特化比通用模板更特化。若两个偏特化同等特化则二义报错。函数模板为什么不能偏特化？函数模板支持重载，重载已能实现类似效果。若允许偏特化，与重载决议的交互会带来复杂歧义，标准因此禁止。enable_if 的 ::type 在条件为 false 时是什么？不存在。enable_if<false, T> 没有嵌套 type 类型，导致替换失败触发 SFINAE，该模板被剔除。C++14 提供了 enable_if_t 别名简化写法。C++17 的 if constexpr 能替代 SFINAE 吗？部分场景可以。if constexpr 在编译期根据条件丢弃分支代码，比 SFINAE 更直观。但它无法控制函数签名层面的重载决议，仍需 SFINAE 或 C++20 concepts。

C++11 引入移动语义解决不必要的深拷贝问题。核心在于区分左值（可取地址、具名）和右值（临时、不可取地址）。右值引用 T&& 可绑定到右值，表示该对象资源可被"窃取"而非复制。移动构造函数和移动赋值运算符通过转移资源（如指针、文件句柄）而非复制，显著提升性能。std::move 本质是无条件转为右值引用的 static_cast，并不移动任何东西，只是让重载决议选择移动版本。完美转发指函数模板将参数以原始值类别（左值/右值）传递给另一函数，借助 std::forward<T> 实现。T&& 在模板推导中是万能引用：实参为左值时 T 推导为左值引用，实参为右值时 T 推导为非引用类型，配合 std::forward<T> 按原始类别转发。引用折叠规则决定了最终类型：只有 T&& && 折叠为 T&&，其余均折叠为 T&。追问std::move 之后原对象还能用吗？可以，但处于"有效但未指定"状态。可安全赋值或析构，不应读取其值。移动后应将原对象置空或重置，保持语义清晰。万能引用和右值引用怎么区分？看 T 是否需要推导：template<typename T> void f(T&& x) 中 T&& 是万能引用；void f(std::string&& x) 中是右值引用。auto&& 也是万能引用。完美转发中为什么必须用 std::forward 而非 std::move？std::move 总是转为右值，会错误地将左值参数也转为右值。std::forward<T> 仅当 T 为非引用类型时才转为右值，保留原始值类别。引用折叠的四种情况是什么？T& & → T&、T& && → T&、T&& & → T&、T&& && → T&&。只有右值引用到右值引用折叠为右值引用，其余均折叠为左值引用。

C++ 多态分编译时和运行时两种。编译时多态通过函数重载和模板实现，编译器根据参数类型或模板实参在编译期确定调用目标，零运行开销。运行时多态依赖虚函数机制：每个含虚函数的类拥有一张虚函数表（vtable），存储各虚函数的入口地址；每个对象实例持有指向所属类 vtable 的虚指针（vptr）。调用虚函数时，通过 vptr 查 vtable 完成动态绑定，实现了根据实际对象类型调用对应版本。纯虚函数使类成为抽象类，强制子类必须实现。析构函数声明为虚函数可确保 delete 基类指针时正确调用派生类析构，避免资源泄漏。多重继承下对象可能包含多个 vptr，分别指向不同基类的 vtable。追问vtable 存在哪里？每个对象都有独立的 vtable 吗？vtable 通常在编译期生成，存于只读数据段。同一类的所有对象共享同一张 vtable，各对象只存一个 vptr 指向它。构造函数可以是虚函数吗？不能。构造时对象类型尚未完整，vptr 还未初始化完成，虚函数机制尚未就绪，无法进行动态绑定。虚函数调用一定有运行开销吗？大多数情况有一次间接寻址开销。但编译器若能在调用点确定实际类型（如通过 final 类或显式限定），会进行去虚化（devirtualization）优化为直接调用。多重继承下 vptr 怎么布局？对象按继承顺序排列各基类子对象，每个有虚函数的基类子对象各有一个 vptr。通过不同基类指针访问时，指针值可能需要偏移调整（this adjustment）。

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 实例，避免语言状态跨请求污染。