用std::hex配合std::ostringstream可将long long转为小写十六进制字符串，如"123456789abcdef"；需组合std::uppercase、std::showbase、std::setw和std::setfill实现大写、前缀及补零。
用 std::hex 和 std::ostringstream 转 long long 为小写十六进制字符串
直接用 std::hex 配合 std::ostringstream 是最可控、最常用的方式，它不依赖平台字长，能正确处理 long long（通常为 64 位）。
关键点：必须搭配 std::showbase（可选）和 std::noshowbase（默认），且 std::hex 只影响整数输出格式，不自动补零、不转大小写。
#include <sstream>
#include <iomanip>
#include <string>
long long val = 0x123456789ABCDEFLL;
std::ostringstream oss;
oss
<ul>
<li>
<code>std::hex</code> 是流操纵器，只对后续整数类型起作用；浮点数不受影响</li>
<li>默认输出不含 <code>0x</code> 前缀；加 <code>std::showbase</code> 才会显示（但对 <code>long long</code> 有些旧编译器可能不支持前缀）</li>
<li>输出字母为小写；要大写需额外加 <code>std::uppercase</code>
</li>
<li>不会自动补零到固定宽度——需要 <code>std::setw</code> + <code>std::setfill('0')</code>
</li>
</ul>
<h3>补零、大写、带 0x 前缀的完整控制写法</h3>
<p>实际项目中常需统一宽度（如 16 字符表示 64 位）+ 大写 + 前缀。这时必须组合多个操纵器，顺序很重要：填充和宽度要在值输出前设置，且 <code>std::hex</code> 必须在 <code>std::setw</code> 之后、值之前。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill5502" title="C++ Code Review Master"><img
src="https://img.php.cn/upload/skill/000/000/081/179051228971575.jpg" alt="C++ Code Review Master" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill5502" title="C++ Code Review Master" class="overflowclass">C++ Code Review Master</a>
<p class="overflowclass">组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。</p>
</div>
<a rel="nofollow" href="/xiazai/skill5502" title="C++ Code Review Master" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<pre class="brush:php;toolbar:false;">std::ostringstream oss;
oss
-
std::setw是**一次性**的，只作用于下一个插入操作；多次输出需重复设 -
std::setfill会持续生效，直到再次调用；推荐在同一流中配对使用 -
std::showbase对long long在 GCC/Clang 上有效，在 MSVC 2019+ 也支持；但某些极老标准库可能忽略它 - 注意
0X（而非0x）——std::uppercase会把前缀也转成大写
避免用 sprintf 或 snprintf 直接格式化 long long
用 C 风格函数容易因平台差异出错：%llx 在 Linux/GCC 安全，但在 Windows MSVC 中，long long 应用 %I64x；混用会导致未定义行为或截断。
- MSVC 下
sprintf(buf, "%llx", val)可能只读低 32 位（尤其开启 /W4 时会报警 C4305） - 跨平台项目若坚持用 C 风格，必须条件编译：
#ifdef _MSC_VER分支用%I64x，否则用%llx - 更糟的是，
std::to_string不支持进制控制——std::to_string(255)永远是"255"，不能变"ff"
性能与隐式转换陷阱：别让 std::hex 影响后续流状态
std::hex、std::dec、std::oct 是流的持久状态。如果复用同一个 std::ostringstream 多次格式化不同类型数据，上次的进制设置可能污染下一次输出。
std::ostringstream oss; oss
- 误区：以为
std::hex会影响字符串拼接或后续非整数输出——它只影响后续的整数插入（/<code>） - 但如果你封装了一个通用日志流对象并长期复用，忘记重置
std::dec，下个就真输出 <code>"7b"了 - 安全做法：局部构造
std::ostringstream，或每次格式化前显式写oss
long 和 long long 的行为差异会突然暴露。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
