std::hex 没生效通常是因为误以为它只作用于当前输出，实际会持续影响后续所有整数输出，需配对使用 std::dec 重置；对浮点数无效，char 需转 int 才显示 ASCII 码。
用 std::hex 输出整数时为什么没生效？
因为 std::hex 只影响后续的整数输出，且不自动重置——它会一直生效，直到你显式切回 std::dec 或其他进制。很多人只写一次 std::hex 就以为完事了，结果后面所有 int 都变成十六进制，连调试用的行号、计数器都乱了。
实操建议：
- 每次用完
std::hex后，紧跟着加std::dec（尤其在日志或混合输出场景） - 避免在全局流（如
std::cout）上长期设置进制，优先用临时std::ostringstream - 注意：
std::hex对浮点数无效，对char默认按字符输出（不是0x61），想输出 ASCII 码得先转成int
示例：
std::cout << std::hex << 255 << " " << 100; // 输出：ff 64<br>std::cout << std::dec << 100; // 必须手动切回来，否则下一行还是 hex
怎么输出带 0x 前缀和固定宽度（比如 4 位补零）？
std::hex 本身不加前缀、不补零——这是格式控制的常见盲区。前缀和填充是独立开关，靠 std::showbase 和 std::setw/std::setfill 组合实现。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 加
0x前缀：必须配std::showbase，且要放在std::hex之后（顺序敏感） - 补零到固定宽度：用
std::setw(N)+std::setfill('0')，但std::setw只对下一个输出项生效 - 别漏掉
#include <iomanip>，否则std::setw和std::setfill不可用
示例：
std::cout << std::hex << std::showbase << std::setw(4) << std::setfill('0') << 0xA;<br>// 输出：0x000a<br>// 注意：setw 对下一项生效，如果后面还输出别的东西，要重新设
printf 的 %x 和 C++ IO 流哪个更靠谱？
纯性能看 printf 更快，但安全性、类型检查和可维护性上 C++ 流明显占优。真实项目里踩坑最多的是 printf 的类型错配：比如传 uint32_t 却用 %x（它期望 unsigned int），在 Windows/MSVC 上可能出错，在 Linux/gcc 上侥幸通过，导致跨平台 bug。
实操建议：
- 除非在极端性能敏感路径（如高频日志埋点），否则优先用
std::hex+std::ios_base::fmtflags控制 - 若坚持用
printf，整数类型务必匹配：用PRIx32（需<inttypes.h>）代替裸%x -
std::format（C++20）是未来方向，支持"{:#x}"这类 Python 风格语法，但目前编译器支持还不统一
输出大写十六进制（A-F）还是小写（a-f）？
C++ 标准流默认小写，没有内置开关切大写——这是很多人搜“C++ hex uppercase”却找不到答案的原因。你不能靠 std::uppercase（它只对科学计数法的 e 和十六进制浮点数的 p 生效）。
实操建议：
- 小写是标准行为，接受它；强行转大写得自己处理字符串（比如用
std::transform+std::toupper） - 如果只是偶尔需要，用
std::ostringstream先生成小写字符串，再转换，比污染全局流状态更安全 - 注意：某些嵌入式或协议场景要求大写（如 CAN 报文日志），这时提前封装一个
to_hex_upper(uint32_t)函数更清晰
示例：
std::ostringstream oss;<br>oss << std::hex << value;<br>std::string s = oss.str();<br>std::transform(s.begin(), s.end(), s.begin(), ::toupper); // 注意 ::toupper 防止重载歧义
真正麻烦的不是怎么输出十六进制，而是不同模块对前缀、大小写、宽度的隐含假设不一致——比如一个函数返回 "ff"，另一个期待 "0xFF"，中间一拼接就出逻辑错误。这种细节往往要到联调阶段才暴露。
