标准库函数在绝大多数场景下比手写代码快，但前提是用对函数、传对参数、数据类型匹配；std::sort是introsort并含多种优化，手写难及；std::memcpy/fill/copy对POD类型远快于循环；std::string::substr有SSO和批量拷贝优势；误用会导致错误而非性能问题。
标准库函数在绝大多数场景下比手写代码快，但前提是用对函数、传对参数、数据类型匹配。
std::sort vs 手写快排/冒泡
现代 std::sort 是 introsort（混合堆排+快排+插入排序），对小数组自动切到插入排序，对退化情况降级为堆排，还做了分支预测和缓存友好优化。手写快排若没做这些，实测慢 2–5 倍；即使写得“正确”，也很难在通用性、边界处理、迭代器适配上达到标准库水平。
- 必须确保容器支持随机访问迭代器（
std::vector、std::array可以，std::list不行） - 自定义比较函数要
noexcept且不抛异常，否则可能禁用某些优化 - C++17 起可加
std::execution::par启用并行，手写并行逻辑极易出错
std::memcpy / std::fill / std::copy vs 循环赋值
对 POD 类型（如 int、float、struct 无虚函数/非 trivial 构造），std::memcpy、std::fill、std::copy 几乎总是更快——编译器会把它们直接映射成 rep movsb 或向量化指令。手写 for 循环哪怕用 restrict，也常因边界检查、指针别名分析失败而无法充分向量化。
-
std::copy(src.begin(), src.end(), dst.begin())在src和dst都是 POD 且内存连续时，内部大概率调用memcpy -
std::fill对std::vector的填充，效果等同于memset+ 类型转换，比循环v[i] = x快 10–100 倍 - 但若目标是非 POD 类型（如含虚表或自定义构造的类），
std::fill会调用构造函数，此时不能简单替换成memset
std::string::substr vs 手动字符拷贝
很多人以为“少一次函数调用就快”，结果手写 for 拷贝反而更慢。因为 std::string::substr 在 SSO（小字符串优化）启用时，短字符串根本不分配堆内存；即使触发堆分配，其内部也使用 memcpy 批量拷贝，并做了长度预判和对齐优化。
- 手动拷贝需自己管理目标缓冲区大小、越界检查、空终止符，代码膨胀且易出错
- 若目标是
std::string，直接用substr；若目标是char*，优先考虑std::string_view避免拷贝，而非手撕循环 - 注意：
substr返回新对象，若只是临时查看内容，用std::string_view(s.data() + pos, len)零拷贝更优
真正容易被忽略的点是：性能优势只在“用对”时成立。比如对 std::list 调用 std::sort 会编译失败；对非 POD 类型误用 memcpy 导致析构函数不调用；或者在 std::vector 上用 std::copy 却没意识到它是特化位容器——这些不是标准库慢，是你没看清契约。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
