内存重复拷贝主要发生在字符串拼接、结构体入队、序列化打包三环节，解法是移动语义+预分配+零拷贝视图协同；需reserve避免string realloc、手写noexcept移动构造函数、用string_view替代substr、emplace_back代替push_back、SerializeToArray替代SerializeToString。
弹幕下发场景下，内存重复拷贝最常发生在字符串拼接、结构体入队、序列化打包三个环节，直接导致 CPU 占用飙升、GC 压力大（若混用 JNI）、延迟毛刺明显。核心解法不是“少拷贝”，而是“让拷贝不发生”——靠移动语义 + 预分配 + 零拷贝视图协同生效。
std::string 拼接时反复 realloc 的坑
弹幕文本、用户 ID、时间戳拼成一条完整 JSON 或二进制包时，若用 += 逐段追加且未 reserve()，std::string 会按几何增长策略多次重分配堆内存，每次都要 memcpy 原内容。100 条弹幕每条平均 200 字节，实际可能触发 3–5 次 realloc，总拷贝量翻倍。
- 实操：预估单条最大长度（比如含 emoji 和 base64 头像 URL），调用
result.reserve(512)再循环+= - 更稳做法：改用
std::string构造时传入容量，或直接用std::vector<char></char>手动管理缓冲区（尤其对接 protobuf 序列化） - 注意：
substr()返回新std::string，不是视图——弹幕池里取字段时别写msg.substr(pos, len)，改用std::string_view(msg.data() + pos, len)
弹幕结构体进队列时的深拷贝开销
把 Danmaku 结构体 push 到 std::queue 或 std::vector 时，若没写移动构造函数，扩容或传参过程会触发完整深拷贝——尤其是结构体里含 std::string、std::vector 等成员时，指针转移变内存复制。
- 必须手写移动构造函数，并标注
noexcept：Danmaku(Danmaku&& other) noexcept : text(std::move(other.text)), uid(std::move(other.uid)) { /* other 资源置空 */ } - 容器插入优先用
emplace_back替代push_back，避免临时对象构造+移动两步；例如queue.emplace(text_view, uid_str, timestamp) - 若弹幕只读分发，考虑用
std::shared_ptr<const danmaku></const>代替值存储，多线程读取无锁，但注意引用计数原子操作成本
序列化阶段绕过 string 拷贝的实操路径
JSON 序列化库（如 nlohmann/json）默认对 std::string 成员做深拷贝；Protobuf 的 SerializeToString() 也会 new 一块 buffer 再 copy。这两步在高频弹幕下发中是性能黑洞。
立即学习“C++免费学习笔记（深入）”；
- 用
std::string_view初始化 JSON 对象字段，nlohmann/json 支持直接接受string_view，内部不拷贝原始数据 - Protobuf 推荐用
SerializeToArray()+ 预分配 buffer，避免SerializeToString()的额外分配；buffer 可来自内存池 - 终极零拷贝：用
flatbuffers或capnproto，序列化结果就是一段连续内存，弹幕结构体字段直接映射到 buffer 偏移，连string_view都省了
最容易被忽略的是：移动语义只在右值或显式 std::move() 时触发，而函数返回值是否 RVO（返回值优化）取决于编译器和代码结构——复杂 if 分支、多个 return 点都会禁用 RVO。所以对关键路径，宁可显式 return std::move(result)，也不赌编译器。
