裸指针易拖慢性能因缓存不友好、未对齐访问或越界导致CPU停顿；应改用std::string_view+预分配缓冲区、环形缓冲区配原子指针，或std::span/移动语义管理生命周期。
为什么日志里用裸指针反而容易拖慢性能
直接用 char* 或 void* 指向日志缓冲区，看似绕过拷贝，实则常因缓存不友好、未对齐访问或意外越界导致 CPU 停顿甚至段错误。现代日志库（如 spdlog、g3log）默认禁用裸指针写入，正是为避免这类非确定性开销。
真正提升性能的关键不是“用不用指针”，而是：是否复用内存、是否避免格式化时的临时字符串分配、是否绕过锁竞争。裸指针若没配合环形缓冲区+原子游标，往往得不偿失。
用 std::string_view + 预分配缓冲区替代指针传参
多数日志函数接口设计成接受 const char*，但调用方若每次拼接 std::string 再取 c_str()，就触发堆分配。更优解是让日志前端持有固定大小的线程局部缓冲区（如 1024 字节），用 std::string_view 将其视作只读切片传入。
- 缓冲区用
thread_local char log_buf[1024]声明，避免锁和跨线程同步 - 格式化时用
snprintf(log_buf, sizeof(log_buf), "%s:%d %s", file, line, msg)，不依赖std::ostringstream - 日志后端接收
std::string_view view{log_buf, len}，直接 memcpy 到队列，不额外拷贝 - 注意
log_buf必须以\0结尾，否则string_view构造可能越界
环形缓冲区中用 char* 管理写位置，但必须配原子操作
若实现无锁日志队列，确实需要指针跟踪写入位置，但绝不能用普通 char* 自增——多线程下 ptr++ 非原子，会丢失日志。
立即学习“C++免费学习笔记（深入）”；
- 用
std::atomic<char></char>存储当前写地址，初始化指向缓冲区首址 - 写入前用
fetch_add(n, std::memory_order_relaxed)预留空间，返回旧指针 - 确保
n不超剩余空间：需先计算空闲长度，失败则丢弃或阻塞（取决于日志等级） - 写完后不更新指针，由消费者负责推进读位置；写指针只进不退，避免 ABA 问题
示例关键片段：
auto pos = writer_ptr.fetch_add(len, std::memory_order_relaxed);
if (pos + len > buffer_end) { /* 处理溢出 */ }
memcpy(pos, data, len);
什么时候该放弃指针，改用 std::span 或移动语义
当日志内容来自已有容器（如 std::vector<uint8_t></uint8_t> 的网络包头），用 char* 易引发生命周期错配：缓冲区提前析构，指针变悬垂。
- 优先传
std::span<const char></const>，编译期绑定长度，且不拥有内存 - 若日志需异步落盘且内容可转移（如 JSON 序列化结果），直接移动
std::string：接收参数用std::string&&，避免深拷贝 - 慎用
std::shared_ptr<const char></const>：引用计数本身有开销，且易造成循环引用延迟释放
真正难处理的从来不是指针语法，而是日志上下文的生命周期边界——它往往横跨线程、模块、甚至 DLL 边界。
