std::string::ends_with仅C++20支持，需编译器开启-std=c++20；兼容旧标准应手动实现，推荐用compare避免substr的异常与性能问题，并注意路径、编码、大小写等实际场景干扰。
用 ends_with 前先确认 C++ 标准版本
如果你的编译器报错说 std::string::ends_with 不存在，不是代码写错了，是标准没跟上——这个成员函数只在 C++20 起才被加入。GCC 10+、Clang 12+、MSVC 19.30+ 支持，但默认可能不开 C++20 模式。
实操建议：
- 编译时加
-std=c++20（GCC/Clang）或/std:c++20（MSVC） - 检查是否误用了旧版 STL 头文件（比如只包含
<string></string>是够的，不用额外头） - 若项目必须兼容 C++17 或更早，别硬上
ends_with，直接跳到下个副标题
手动实现后缀判断：用 substr 还是 compare？
substr 看起来直观，但容易触发隐式内存分配和拷贝——尤其对长字符串取后缀时，性能不划算。真正轻量、安全的做法是用 compare。
常见错误现象：s.substr(s.size() - suffix.size()) == suffix 在 suffix 比 s 还长时会抛 std::out_of_range 异常。
立即学习“C++免费学习笔记（深入）”；
正确写法（C++11 起通用）：
bool ends_with(const std::string& s, const std::string& suffix) {
if (suffix.size() > s.size()) return false;
return s.compare(s.size() - suffix.size(), suffix.size(), suffix) == 0;
}说明：
-
s.compare(pos, len, str)从pos开始比len个字符，不构造新字符串 - 无需检查空字符串：当
suffix.size() == 0，s.compare(...)返回 0，逻辑自然成立 - 如果
suffix是字面量（如"txt"），可改用const char*重载避免临时std::string构造
处理 std::string_view 时别掉进 substr 的坑
std::string_view 的 substr 不抛异常，但返回的是一个新 string_view，它可能指向已释放的内存——尤其当你从临时 std::string 构造 string_view 后再调 substr，极易引发未定义行为。
安全做法是全程用 compare：
bool ends_with(std::string_view s, std::string_view suffix) {
if (suffix.size() > s.size()) return false;
return s.compare(s.size() - suffix.size(), suffix.size(), suffix) == 0;
}关键点：
-
string_view::compare不涉及内存分配，也不延长底层数据生命周期 - 传入的
suffix如果是字面量（如"log"），自动推导为string_view，零开销 - 不要写
s.substr(s.size() - suffix.size()) == suffix——即使编译通过，也可能在运行时读越界
Windows 路径、大小写、Unicode：后缀判断的真实复杂点
纯 ASCII 字符串用 compare 没问题，但实际工程中常遇到三类干扰：
- 路径分隔符混用：
"file.TXT"vs"file.txt"——需先转小写再比，或用平台 API（如 Windows 的_stricmp） - UTF-8 编码的中文扩展名（如
"报告.pdf"）：不能按字节截取后缀，得用 ICU 或std::codecvt_utf8（已弃用）做 Unicode 边界识别 - Windows 下路径末尾可能带反斜杠：
"dir\file.txt\"——得先std::filesystem::path规范化，再取filename()后判断
这些都不是 ends_with 或 substr 能绕开的，得前置清洗。最常被忽略的是：你以为在比文件扩展名，其实输入是个带空格或控制字符的路径字符串，而你连 trim 都没做。
