std::vector 與 std::StringBuilder：動態數組的優化策略與適用邊界

核心定位：線性動態數組

std::vector 管理一塊連續、可動態增長的線性內存。std::StringBuilder（StdExt 庫）基於 vector 實現，所有結論對其同樣適用。本文聚焦 vector 的加速技巧、固有缺陷與分配器選擇。

兩大加速鐵律

1. 預分配：reserve(size)

若能預估元素數量，插入前調用 reserve() 可避免多次擴容與搬移，將 push_back 穩定為真 O(1)。

2. 只在尾部操作

vector 無 push_front，因頭部插刪需搬移所有元素（O(N)）。需大量頭部操作時，改用 deque（兼具隨機訪問）或 list。

致命缺陷：海量數據與內存碎片

• 海量數據瓶頸： 線性內存要求連續大塊地址空間，數億元素級別極易分配失敗或觸發嚴重碎片。
• 碎片製造機： 頻繁擴容/縮容產生大量中小塊空閒內存，長期運行導致堆碎片化，影響進程整體分配性能。

對策： 超大字符串/文本處理請改用 std::TextPool（基於 deque）或 std::Rope（樹結構），它們不要求物理連續。

分配器選擇：無需 GC Allocator

vector 模板參數 AllocT 預設 std::allocator。GC Allocator 擅長小塊頻繁分配，但 vector 的線性大塊增長模式無法受益，反而增加開銷。同理 std::string（basic_string）也不適用。

替代方案導航

• std::deque：海量數據、雙端操作、隨機訪問三全其美
• std::list：純粹高頻中間插刪，無隨機訪問需求
• std::StringBuilder：小字符串構建，配合 reserve 極快
• std::TextPool / Rope：巨型文本、頻繁修改、子串操作

認清 vector 的「線性連續」本質與邊界，才能在架構選型中避開性能陷阱。