std::partial_sort适合k接近n的场景；当k超过数组长度10%～20%时更稳定，时间复杂度o(n log k)，但k增大时趋近完整排序开销，且要求k有效、不越界。
std::partial_sort 适合 K 接近 N 的场景
当你要取前 K 个最小（或最大）元素，且 K 超过整个数组长度的 10%～20%，std::partial_sort 往往更稳。它内部通常用堆 + 部分堆排序实现，时间复杂度是 O(N log K)，但常数偏大；一旦 K 变大，log K 接近 log N，它就退化成接近完整排序的开销。
实操建议：
- 用
std::partial_sort(first, first + K, last)，注意中间迭代器指向第K个位置（即前K个有序，其余无序） - 如果后续还要对这
K个结果做遍历/二分查找，它天然满足有序性，省去额外排序 - 别传
K == 0或越界值——std::partial_sort不检查，行为未定义 - 在 MSVC 和 libstdc++ 上，它对小数组（
N ）可能直接切到插入排序，但别依赖这点做性能假设
std::nth_element 更快，但只保证“第 K 位正确”
std::nth_element 是 Top-K 的真正轻量解：它只确保第 K 个位置放好“应该在这儿”的元素，左边全 ≤ 它、右边全 ≥ 它，但左右两段各自不排序。平均时间复杂度 O(N)，最坏 O(N²)（实际实现多用 introselect，基本能避免）。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 误以为调用后前
K个就是最小的 —— 实际上它们只是“都 ≤ 第K个”，彼此顺序随机 - 想拿前
K个做二分查找，结果出错，因为没排好序 - 传入
K >= N，触发断言失败（libstdc++）或静默 UB（某些旧 MSVC 版本）
使用场景：你只要最小的 K 个值（不要求顺序），或者只需要中位数、Top-1、P95 延迟阈值这类单点定位。
性能差异真正在意的不是理论复杂度，而是缓存和分支预测
实测中，std::nth_element 在 K 时几乎总是赢，尤其当数据随机或部分有序；但若数据已近乎升序，<code>std::partial_sort 的堆操作反而更可预测，std::nth_element 的 partition 步骤可能因大量分支跳转变慢。
参数差异关键点：
-
std::nth_element第三个参数是nth迭代器，不是数量K—— 写成v.begin() + K，不是K - 两者都支持自定义比较器，但注意：传递
std::greater<int>{}</int>会让std::nth_element找“第 K 大”，而非“前 K 大”——这是语义区别，不是 bug - 并行版本（C++17
std::execution::par）对std::nth_element加速比std::partial_sort明显，但要注意线程安全和 small N 下的调度开销
别忽略 std::partial_sort_copy 和 std::nth_element 的组合用法
如果你不能修改原数组，又只要前 K 个有序结果，std::partial_sort_copy 比先 std::nth_element 再手动拷贝 + 排序前 K 个更干净。但它会分配 K 空间并复制最多 N 次元素 —— 当 K 小但 N 极大（比如 10M 元素里取 Top-10），std::nth_element + 手动筛选（一次遍历比对）反而内存友好。
容易被忽略的地方：
-
std::nth_element不改变等值元素的相对顺序（stable？不，它不保证稳定），但如果你靠相等性做业务逻辑（比如时间戳相同取先到的），得自己加索引字段再重写比较器 - 所有这些算法都要求迭代器是 RandomAccessIterator，
std::list或std::forward_list上用不了 —— 别试，编译不过 - 调试时打印中间状态？别在 release 模式下打，
std::nth_element的实现可能在 debug 版本插桩，影响性能判断
