当函数参数只读、生命周期明确且不需修改或拥有数据时，优先用 std::string_view；它零拷贝、无堆分配，但不可用于需修改、长期缓存或传给要求 null-terminated 的 c api 场景。
什么时候该用 std::string_view 而不是 std::string
当函数参数只读、生命周期明确且不需修改或拥有数据时，优先选 std::string_view。它只是指向已有字符序列的轻量视图，零拷贝、无堆分配。
常见错误是把临时字符串字面量转成 std::string_view 后，又把它存进容器或返回给调用方——比如 return std::string_view("hello")，此时视图指向的字符串字面量虽常驻内存，但若换成 return std::string_view(std::string("hello")) 就悬垂了。
- 适用场景：函数入参（尤其模板泛化）、配置解析中的键名匹配、日志消息切片
- 不适用：需要拼接、替换、大小写转换等修改操作；需要保证数据长期有效（如缓存、异步回调）
-
std::string_view不保证以'\0'结尾，c_str()不可用；传给 C API 前得确认是否需要 null-terminated
std::span 和复制 vector 的边界在哪
std::span 是 C++20 引入的只读（或可写）连续内存视图，适合替代裸指针+长度组合。但它不管理内存，也不延长所指对象的生命周期。
典型误用：对局部 std::vector 取 std::span 并返回——std::span 本身没析构问题，但所指内存随 vector 析构而失效。
- 推荐用法：函数参数接收已知生命周期的数组或 vector（如传入
std::vector<int>&</int>再构造std::span<const int></const>） - 避免用法：存储
std::span到类成员中，除非你能 100% 控制底层容器的生命周期 - 性能影响：
std::span是两个字段（指针+长度），比std::vector小得多；但若后续频繁调用data()和size()，编译器通常能优化掉冗余访问
自定义类型怎么安全提供只读视图接口
如果你的类内部持有 std::vector<t></t> 或 std::string，对外暴露只读访问时，别直接返回引用或指针，而应封装为视图类型。
例如，不要写 const std::vector<int>& data() const { return m_data; }</int> ——这泄露了实现细节，也强迫调用方理解所有权模型；更糟的是，若未来改成 std::unique_ptr<:vector>></:vector>，接口就崩了。
- 推荐做法：返回
std::span<const t></const>（C++20）或gsl::span<const t></const>（C++17），或封装简单结构体含begin()/end() - 关键约束：视图返回值必须和宿主对象绑定同一生命周期；若宿主被 move，视图应失效（可通过断言或文档明确）
- 注意 const 成员函数不能返回可写视图；若需读写视图，单独提供非 const 版本，并确保调用方清楚副作用风险
跨线程传递视图为什么特别危险
视图本身是 POD，可以自由拷贝，但它的有效性完全依赖原始数据的存活和线程安全访问。一旦原始容器在另一线程被修改或销毁，所有视图立刻变成未定义行为。
常见陷阱：主线程创建 std::string_view 传给工作线程处理，同时主线程很快释放了源字符串——工作线程可能刚读到一半就 crash 或读到垃圾数据。
- 安全做法：跨线程必须传递副本（
std::string、std::vector），或使用共享指针包裹数据 + 视图（如std::shared_ptr<const std::string></const>） - 没有银弹：即使加锁保护原始容器，也不能解决“视图生命周期 > 锁持有时间”的问题；锁只能保访问原子性，不保生存期
- 调试提示：开启 ASan + UBSan，这类悬垂访问往往能捕获；但生产环境未必触发，所以设计阶段就要规避
视图不是语法糖，它是把内存生命周期责任显式甩给程序员的契约。用错一次，可能不会立刻出错，但会在最意想不到的并发路径或重构后爆发。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
