因为 std::hex 只影响整数类型的格式化输出，对 std::string 类型无作用；std::string 不是整数，无法直接被 std::hex 解释为十六进制数值。
直接用 std::hex 配合 std::setw 和 std::setfill 输出，但注意：它只对整数有效，不能直接作用于 std::string；想把字符串每个字节转成两位十六进制字符（如 "ab" → "6162"），必须逐字节处理。
为什么不能直接用 std::cout
因为 std::hex 是流操纵符，只改变后续整型（int、unsigned char 等）的输出进制，而 std::string 的 operator 会直接输出原始字符内容，完全忽略进制设置。常见错误现象是：输出仍是明文，甚至触发隐式转换导致乱码或截断。
std::cout → 编译失败（C 字符串不能隐转整数）std::cout → 输出 <code>AB，不是4142- 若误写成
std::cout 但没设宽度，<code>'A'变成41，'\n'变成a（缺前导零）
安全可靠的逐字节转换方法（推荐 std::ostringstream + static_cast<unsigned char></unsigned>）
关键点有三个：确保字节按无符号解释（避免负值补码干扰）、强制两位宽度、不带 0x 前缀。使用 std::ostringstream 比 sprintf 更安全，且支持流式组合。
- 必须用
static_cast<unsigned char>(c)</unsigned>转换每个字符，否则char在平台为 signed 时，值如0xFF会被当 -1，再转int后变成大负数，std::hex输出异常长的十六进制（如ffffffff） - 每次写入前调用
os ，顺序不能颠倒；<code>std::hex是状态保持的，设一次即可，但setw只对下一个输出项生效 - 示例代码片段：
#include <sstream>
#include <iomanip>
std::string to_hex(const std::string& s) {
std::ostringstream oss;
oss << std::hex << std::setfill('0');
for (unsigned char c : s) {
oss << std::setw(2) << static_cast<int>(c);
}
return oss.str();
}
// to_hex("A\n") → "410a"
性能敏感场景：用查表法（lookup table）替代流操作
如果每秒要转换 MB 级字符串（如日志二进制 dump、网络包解析），std::ostringstream 的格式化开销明显。此时预建 256 项静态数组，将 0–255 映射为两个 ASCII 字符（如 0x9a → '9','a'），可提速 3–5 倍。
立即学习“C++免费学习笔记（深入）”；
- 查表数组声明：
static constexpr char hex_chars[] = "0123456789abcdef"; - 对每个字节
b，取hex_chars[b >> 4]和hex_chars[b & 0x0f]，直接写入目标 buffer - 注意：目标 buffer 长度必须是原字符串长度 × 2 + 1（末尾 '\0'），且需手动管理内存或用
std::vector<char></char> - 不推荐新手一上来就写查表——逻辑清晰度和可维护性下降，除非 profiler 明确指出这里是瓶颈
最易被忽略的是符号扩展问题：哪怕只是临时调试打印，用 (int)s[i] 而不加 unsigned char 强转，在含非 ASCII 字符（如 UTF-8 中文、二进制数据）的字符串上必然出错。宁可多敲几个字符，别省这个 static_cast。
