不能直接用 std::merge 是因为它要求输出空间预先分配且足够大；实际中需动态构造结果，应先 reserve 再 merge，否则用 back_inserter 会导致频繁重分配；原始指针需手动确保缓冲区大小；std::merge 不验证输入有序性；手写归并推荐三段式 while 循环处理边界。
合并两个已排序数组时，为什么不能直接用 std::merge 就完事？
因为 std::merge 要求输出空间已分配且足够大，而实际中常需动态构造结果——比如合并两个 std::vector<int></int> 并返回新容器。直接传入 std::back_inserter 会导致频繁内存重分配，性能掉得明显。
- 正确做法是预先计算总长度，用
reserve()避免扩容：std::vector<int> result; result.reserve(a.size() + b.size());
- 若原数组是原始指针（如
int*），必须手动管理输出缓冲区大小，漏算一个元素就可能越界 -
std::merge内部是稳定归并，但不检查输入是否真有序——乱序输入会得到不可预测结果，调试时容易误判为算法 bug
手写归并函数时，边界条件怎么写才不容易出错？
核心在于三段式推进：左未尽、右未尽、任一耗尽。用 i、j 分别遍历左右数组，k 写入结果位置，关键不是“谁小谁进”，而是“谁还有剩谁就得处理”。
- 推荐统一用
while (i 处理公共段，再用两个独立 <code>while收尾——比嵌套if更清晰、更少漏分支 - 索引变量必须是
size_t或有符号类型一致，混用int和size_t在j--时可能绕成极大正数 - 如果合并的是自定义类型，比较操作符
必须满足严格弱序，否则归并过程可能卡在相等元素间反复横跳
归并排序递归实现里，临时缓冲区该复用还是每次 new？
每次递归都 new 临时数组，堆分配开销会吃掉一半性能；全用一个全局缓冲区又容易因递归深度导致栈溢出或线程不安全。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 最佳实践是把临时缓冲区作为参数传入递归函数，顶层一次性分配：
std::vector<int> temp(arr.size()); merge_sort(arr, 0, arr.size(), temp);
- 缓冲区大小只需和原数组相同，不必按子区间大小动态调整——归并过程只读写对应区间，多余空间无影响
- 若用
std::array替代std::vector，必须编译期确定最大长度，不适合运行时尺寸未知的场景
用 std::inplace_merge 做原地归并，有什么隐藏代价？
std::inplace_merge 看似省空间，但它内部可能分配临时内存（标准未强制要求真正原地），且对随机访问迭代器有强依赖——std::list::iterator 不支持，强行用会编译失败。
立即学习“C++免费学习笔记（深入）”；
- 它要求输入已是“两段有序”结构，比如
[1,3,5,2,4,6]中前半和后半各自有序，不能用于任意打乱后的分段 - 时间复杂度仍是
O(n)，但常数因子比手写归并高，尤其在小数组上，cache miss 更频繁 - 若容器是
std::deque，inplace_merge可能退化为多次块搬移，实测比复制到新 vector 再 merge 还慢
实际写归并排序时，最易被忽略的是：递归分割点取 mid = first + (last - first) / 2，而非 (first + last) / 2——后者对大地址可能整数溢出，尤其在 32 位环境或 ptrdiff_t 较小时。
