因为频繁构造/拷贝std::string会触发堆分配和内存复制，而裸指针配合预分配缓冲区可规避构造、析构及引用计数开销，前提是数据生命周期可控、长度可预估且不跨线程共享。
为什么不用 std::string 做模糊匹配反而更快？
因为频繁构造/拷贝 std::string 会触发堆分配和内存复制，尤其在短字符串高频匹配（如日志过滤、协议解析）中，开销明显。用裸指针配合固定长度字符数组或预分配缓冲区，能完全规避构造函数、析构函数和引用计数——关键不是“指针本身快”，而是你绕过了 C++ 字符串对象的运行时包袱。
常见错误是以为“用指针 = 手动管理 = 一定快”，结果因未对齐访问、越界读或忘记终止符导致崩溃或未定义行为。真正提速的前提是：你知道源数据生命周期可控、长度可预估、且不跨线程共享。
memcmp + 指针偏移比 std::string::find 快在哪？
当你要找的是子串（非正则），且模式串长度已知、目标串为连续内存（如 char* 或 std::array<char n></char>），直接用 memcmp 配合指针滑动，比 std::string::find 少至少两次函数调用和一次内部迭代器检查。
- 模式串长度
n固定：循环中用memcmp(ptr + i, pattern, n)，i从0到len - n - 必须确保
ptr指向的内存末尾有足够 padding（至少n字节），否则memcmp可能读越界 —— 这是 Segmentation fault 最常见原因 - 若目标串以
\0结尾但长度已知，优先传入长度而非依赖strlen，避免重复扫描
如何安全地用指针做通配符匹配（如 ? 和 *）？
纯指针无法替代完整 NFA/DFA，但简单通配符（单字符 ?、任意长 *）可用双指针 + 回溯实现，无需动态分配。核心是避免递归和 std::vector 存储状态。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
示例逻辑（C 风格）：
bool wildcard_match(const char* s, const char* p) {
const char* star = nullptr;
const char* ss = s;
while (*s) {
if (*p == '?' || *p == *s) { s++; p++; }
else if (*p == '*') { star = p++; ss = s; }
else if (star) { p = star + 1; s = ++ss; }
else return false;
}
while (*p == '*') p++;
return !*p;
}
注意：star 存的是模式串指针，ss 存的是文本串指针，两者必须指向有效内存；若 p 来自字符串字面量（如 "a*b?"），不可修改；若来自用户输入，需确认其以 \0 结尾。
什么时候该停手，老老实实用 absl::string_view？
当你开始写内存对齐判断、手动处理 UTF-8 多字节、或需要部分匹配（如前缀+通配）时，裸指针的维护成本已超过收益。此时 absl::string_view 是更优解：它本质就是 const char* + size_t，零开销，自带边界检查（Debug 模式），且与 STL 算法兼容。
容易被忽略的一点：即使你坚持用指针，也别自己写 strlen —— 编译器对 __builtin_strlen 或 strlen 的内联优化远超手写循环；更别用 while(*p++) 数长度，现代 CPU 对 repnz scasb 类指令做了深度优化。
