std::deque 的 push_back 在连续写入场景下比 vector 慢约12%～18%，主因是非连续内存导致分支判断和缓冲区切换；仅当需频繁 pop_front 或中间插入时才值得选用 deque。
std::deque 的 push_back 性能是否真比 vector 慢？
不是绝对慢，但关键在「连续写入」场景下，std::deque 的内存非连续特性会让每次 push_back 触发分支判断和可能的缓冲区切换。实测中，对 10 万次小字符串分割（平均长度 5），std::deque 比 std::vector 多花约 12%～18% 时间——但这不意味着它不适合，而是提醒你：别为了“可两端插入”而默认选 deque。
如果你只需要从左到右依次存分割结果（绝大多数分隔场景），std::vector + reserve() 仍是更快更稳的选择；只有明确需要后续频繁 pop_front() 或中间插入时，才值得为 deque 的 O(1) 前端操作买单。
用 std::string_view 配合 find_first_of 避免拷贝
传统 std::string::find() + substr() 会反复分配临时字符串，对长输入或高频调用很伤。换成 std::string_view 可完全避免堆分配：
std::deque<:string_view> parts;
std::string_view sv = input;
size_t start = 0, pos = 0;
while ((pos = sv.find_first_of(" \t\n\r", start)) != std::string_view::npos) {
if (pos > start) {
parts.emplace_back(sv.substr(start, pos - start));
}
start = pos + 1;
}
if (start <p>注意点：</p>
<ul>
<li>
<code>std::string_view</code> 持有的是原字符串的引用，确保 <code>input</code> 生命周期长于 <code>parts</code>
</li>
<li>
<code>find_first_of</code> 比循环调用 <code>find</code> 更适合多分隔符场景（如空格、制表符混用）</li>
<li>
<code>emplace_back</code> 直接构造，避免 move 构造开销</li>
</ul>
<h3>std::regex_token_iterator 为什么慎用于高频分割</h3>
<p>虽然 <code>std::regex_token_iterator</code> 写起来简洁，但它内部会编译正则、维护状态机、动态分配匹配对象，在简单分隔（如按空格、逗号）时纯属杀鸡用牛刀：</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2823" title="C++14"><img
src="https://img.php.cn/upload/manual/001/431/639/6ac8b33c327c4749.png" alt="C++14" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="overflowclass">C++14</a>
<p class="overflowclass">C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。</p>
</div>
<a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<ul>
<li>对 10K 次分割，正则版本比手写 find 循环慢 3～5 倍</li>
<li>首次调用有明显延迟（正则编译缓存未命中）</li>
<li>无法复用 <code>std::string_view</code>，必须传 <code>std::string</code> 引用，触发隐式转换</li>
<li>若分隔符含特殊字符（如 <code>"."</code>），还得多写转义，出错率上升</li>
</ul>
<p>只在真正需要模式匹配（如“跳过引号内空格”）时才考虑它，否则绕开。</p>
<h3>预估容量 + deque::resize 不起作用？</h3>
<p><code>std::deque</code> 不支持 <code>reserve()</code>，调用 <code>resize(n)</code> 是直接构造 n 个默认对象，不是预留空间——这对字符串分割毫无意义，反而白占内存。</p>
<p>真正有效的做法只有两个：</p>
<ul>
<li>如果分隔符数量可预估（如 CSV 固定字段数），用 <code>std::vector</code> + <code>reserve()</code>，完事再 move 到 deque（仅当后续真要两端操作）</li>
<li>如果必须用 deque 且性能敏感，改用 <code>std::deque<:string_view></:string_view></code> + 手动管理生命周期，避免字符串拷贝才是关键路径</li>
</ul>
<p>别指望靠“扩容策略”优化 deque，它的设计目标从来不是吞吐优先，而是操作灵活性。想快，就接受 vector；想灵活，就接受那点常数级损耗。</p></:string_view>C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
