char*适用于明确生命周期的只读或简单遍历场景，比std::string更轻量，但需规避段错误、别名干扰向量化、缓存行未对齐及string_view悬垂指针等风险。
用 char* 直接操作内存，绕过 std::string 的构造/析构开销
当字符串生命周期明确、内容只读或仅需简单遍历（如解析日志行、校验协议头），char* 比 std::string 更轻量。它不携带容量、引用计数或分配器信息，指针移动就是地址加减，没有隐藏的函数调用或异常检查。
常见错误是把 char* 当作“可变字符串”直接写入：比如对字面量指针 char* s = "hello" 执行 s[0] = 'H'，会触发段错误——因为字面量存储在只读段。
- 只读场景优先用
const char*，配合strlen、strncmp等 C 函数，避免构造临时std::string - 需要修改时，必须确保指向堆或栈上可写的内存：
char buf[256]; strcpy(buf, "hello"); - 若需动态长度，用
new char[n+1]+strcpy，但务必配对delete[]；更安全的做法是封装为 RAII 类（如知识库中MyString的第一版）
避免指针别名干扰编译器向量化
当你用多个 char* 处理同一块内存（例如同时读 src、写 dest），编译器无法确定它们是否重叠，会保守地禁用 SIMD 优化。这在批量字符转换、编码解码等场景下损失显著。
典型现象：循环体里有 dest[i] = toupper(src[i])，但生成的汇编仍是单字节处理，而非 16 字节宽的 AVX 指令。
- 显式使用
__restrict__（GCC/Clang）或restrict（C++20 起支持）标注指针：void to_upper(char* __restrict__ dest, const char* __restrict__ src, size_t n) - 不要混用
char*和std::string::data()在同一函数中传参——后者返回的指针可能被std::string内部逻辑复用，破坏 restrict 语义 - 注意：restrict 是承诺，不是约束；若实际发生别名，行为未定义
按缓存行对齐访问，减少 LLC miss
现代 CPU 对连续内存访问友好。用 char* 遍历字符串时，若数据分散在不同缓存行（64 字节），每次跨行访问都会触发一次缓存填充，拖慢速度。
对比链表节点中存 char* 和结构体内嵌固定数组：前者每跳一次指针都可能引发新缓存行加载；后者只要首地址对齐，后续几十个字符大概率落在同一行。
- 批量处理时，尽量让字符串连续存放：
std::vector<char> buffer</char>+ 多个char*指向其内部偏移，比多个独立new char[]快得多 - 必要时用
alignas(64)对齐缓冲区起始地址，尤其在高性能 parser 或 tokenizer 中 - 避免在循环内反复计算
ptr += step后再解引用；先算好目标地址，再一次性读取多个字节（如用uint64_t*强制转换读 8 字节）——但需确保内存对齐且不越界
std::string_view + char* 混用时的生命周期陷阱
std::string_view 本质是 const char* + size_t，零拷贝但不管理内存。和裸 char* 混用时，最容易忽略的是源数据销毁早于 view 使用。
典型错误：函数返回局部 std::string 的 c_str()，再转成 string_view——c_str() 指针在函数退出后失效，view 变成悬垂指针。
- 接受
std::string_view参数的函数，内部若需长期持有，必须复制内容到自有缓冲区（如用std::string成员变量保存） - 从
char*构造string_view前，确认该指针指向的内存生命周期覆盖整个 view 使用期；不确定时，宁可用std::string构造 - 调试时可开启 AddressSanitizer：它能捕获大多数悬垂指针访问，包括 string_view 越界读
真正关键的不是“用不用指针”，而是清楚每一块内存归谁管、生命周期到哪一刻、编译器能否推断出无别名——这些细节漏掉一个，性能优势就可能变成崩溃或未定义行为。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
