C++中std::string_view与const char*作为参数性能哪个更好？

你的写法确实属于不良实践，且存在未定义行为风险 #

• 核心问题1：你完全丢弃了std::string_view自带的长度信息，转而依赖C风格字符串的\0结束符判定边界。std::string_view本身不保证指向的内容以\0结尾：如果你后续给func传入的是某个长字符串切片得到的string_view，调用data()后传给需要C风格字符串/隐式构造std::string的接口时，会发生内存越界读取，属于未定义行为。
• 核心问题2：你当前的用法完全浪费了std::string_view的设计优势。string_view的核心价值是无需拷贝即可表示任意长度的字符串片段，同时自带长度属性，你现在的用法和直接传const char*没有任何区别，完全没必要用string_view。

是否要改回const char*？不建议优先这么做 #

改回const char*并没有解决依赖\0结束符的本质问题，同样会遇到字符串无结束符时的越界风险，更推荐的优化方案分场景选择：

• 如果你可以使用C17及以上标准，优先用std::from_chars替代std::stoi，它直接接收指针+长度参数，完美匹配string_view的data()和size()，不需要构造临时std::string，也不依赖\0结束符，性能更高更安全。C23标准已经新增了std::stoi的string_view重载，以及可直接接收string_view的std::ispanstream替换std::istringstream，都不需要额外转换。
• 如果你必须兼容旧标准，要调用只接收const std::string&的接口，请显式用std::string(str.begin(), str.end())构造临时字符串，这种方式会使用string_view自带的长度构造，不需要依赖\0结束符，避免越界。
• 如果你的函数内部绝大多数逻辑都必须依赖\0结束符的C风格接口，且几乎用不到string_view的长度属性，再考虑将入参改为const std::string&（调用者传const char*时会自动构造，不用你手动处理边界），或者确实需要兼容C风格调用的话再改回const char*。

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