将所有const std::string&替换为std::string_view是否始终是最佳选择？

你遇到的是std::string_view核心特性带来的问题：它本质是原字符串的轻量级视图，仅存储指向原数据的指针和长度，既不持有内存，也不会自动在视图末尾添加C风格字符串必需的终止符\0。

你的Split函数返回的std::vector<std::string_view>中，每个元素都是原字符串str的一段子区间视图。当调用v.front().data()时，返回的是原字符串str的起始指针（而非拆分后子串的独立内存），而原字符串中"asd"后面是'\n'不是'\0'，所以find接口会一直读到原字符串的'\0'，导致匹配失败。

除了构造std::string，还有以下更合适的处理方式：

• 修改容器键类型为std::string_view
  如果业务场景允许，直接把std::unordered_map的键类型改成std::string_view，这样查找时直接传入视图对象即可，完全不需要转换：

  std::unordered_map<std::string_view, int> m;
  m["asd"] = 2;
  const auto & v = Split(str, "\n");
  const auto & it = m.find(v.front()); // 直接传string_view
  

  注意：必须保证原字符串str的生命周期长于m和v，否则string_view会变成悬垂视图。

• 正确转换std::string_view为std::string
  如果必须用std::string作为键，不要用std::string(v.front().data())（这种方式会从指针位置读到\0才停止，完全没用到string_view的长度信息），直接用string_view构造std::string即可，它会自动根据视图的长度截取正确的子串：

  const auto & it = m.find(std::string(v.front()));
  

string_view确实能避免临时std::string的构造开销，但它不是银弹，以下场景不适合替换：

• 需要**C风格终止符\0**的接口：比如传给依赖\0判断字符串结束的C函数，或者像你这次一样直接用data()作为键查找（除非视图本身是原字符串的末尾，自带\0）。
• 视图生命周期超过原字符串：如果要把string_view长期存储（比如存在全局容器里），而原字符串可能被销毁，这时必须用std::string持有内存。
• 函数内部需要修改字符串内容：当然你原本用的是const std::string&，这个场景不涉及，但如果后续有修改需求，string_view本身是不可修改的。

std::string_view是优化字符串传递开销的好工具，但要牢记它是视图而非持有的核心特性，在使用时必须关注原字符串的生命周期，以及是否需要C风格终止符。不是所有const std::string&都适合替换成string_view，要根据具体场景判断。

内容的提问来源于stack exchange，提问作者kevin h