strcmp逐字节比较ascii值，不识别utf-8等编码和locale语义，仅适用于纯ascii场景；需确保参数非空且以'\0'结尾，std::string须用c_str()转换，推荐优先使用std::string::compare或operator
strcmp 比较的是字节序，不是字符语义
用 strcmp 判断两个 C 风格字符串大小，本质是逐字节比较 ASCII 值，遇到第一个不同字节就返回差值。它不识别编码（比如 UTF-8），也不理解 locale（比如德语 ß 和 ss 的等价性）。所以 strcmp("café", "cafe") 一定不为 0，哪怕你本地显示一样——因为 é 是多字节 UTF-8 编码，而 strcmp 把它拆成多个字节比，结果完全不可控。
常见错误现象：strcmp 在含中文、emoji 或带重音字母的字符串上返回“意外”结果；或在 Windows 控制台用 GBK 编码跑 UTF-8 字符串时崩溃（遇到非法字节序列）。
- 只用于纯 ASCII 场景，比如协议字段、文件名、环境变量键名
- 若需语言敏感比较（如排序用户姓名），改用
std::strcoll+setlocale，或 C++20 的std::locale+std::collate - 确保两个参数都非空且以
'\0'结尾，否则行为未定义
std::string 不能直接传给 strcmp
strcmp 只接受 const char*，而 std::string 不是裸指针。直接写 strcmp(s1, s2) 会编译失败；有人误用 s1.c_str() 却忽略 s2 可能为空——std::string 对象可以为空，但 c_str() 返回的指针始终合法；真正危险的是调用前没确认对象是否有效（比如临时对象已析构）。
使用场景：需要和 C API 交互，或性能关键路径避免 std::string 构造开销。
立即学习“C++免费学习笔记（深入）”；
- 安全写法：
strcmp(s1.c_str(), s2.c_str())，前提是 s1/s2 是存活的std::string对象 - 更推荐：用
std::string自带的operator 或 <code>compare()方法，它们语义清晰、空安全、支持子串比较 - 注意
compare()返回值和strcmp一致（负/零/正），但参数更灵活，比如s1.compare(2, 3, s2, 0, 4)
返回值不是布尔，别当成 if 条件直接用
strcmp 返回的是整数差值，不是 0/1。写成 if (strcmp(a, b)) 能运行，但逻辑反直觉：它在“不相等”时为真，等于时为假。更糟的是，有人写 if (strcmp(a, b) == true)，而 true 是 1，漏掉所有返回 -1、2、-5 等非零值的情况。
性能影响：无，但可读性和维护性极差；跨平台时某些旧编译器对负返回值处理有差异。
- 判断相等：用
strcmp(a, b) == 0 - 判断 a 小于 b：用
strcmp(a, b) ，不是 <code> - 避免隐式转换：绝不写
if (strcmp(...))或== true/== false
Windows 下 CRT 和 UCRT 的 strcmp 行为微差
Visual Studio 2015+ 默认用 UCRT（Universal CRT），它对无效多字节序列的处理比老 CRT 更严格。比如传入一个中间截断的 UTF-8 字节序列，老 CRT 可能继续比到下一个 \0，UCRT 可能提前返回负值或触发断言（取决于调试模式）。这不是 bug，是标准允许的未定义行为落地差异。
容易踩的坑：代码在 Linux GCC 下测试通过，迁移到 Windows 后出现随机比较失败或 crash；或者用 MinGW 编译时表现又不同。
- 开发期打开编译器警告：/Wall（MSVC）或 -Wstringop-overflow（GCC/Clang），能捕获部分越界传参
- CI 中至少覆盖 MSVC（x64 + x86）、GCC、Clang 三套工具链
- 若必须处理未知编码输入，先做轻量验证（如检查 UTF-8 格式），再决定走
strcmp还是转码
字符串比较这件事，表面是函数怎么调，实际是数据来源、编码假设、生命周期管理全得对齐。错一个环节，strcmp 就只是个放大器。
