c++oding="utf-8" ?>
std::to_chars仅官方支持十进制（base=10），虽签名含base参数，但libstdc++、libc++和msvc均未实现base=2/8/16，传入非10值将触发std::errc::invalid_argument或未定义行为；可靠替代方案为c++20的std::format或手写查表转换。
std::to_chars 不支持直接输出非十进制字符串
std::to_chars 是 C++17 引入的无格式化、无内存分配的底层转换函数，但它只接受 int、float、double 等类型，并**仅支持十进制（base = 10）**。传入其他进制（如 base = 16）会触发未定义行为——标准明确要求 base 必须是 2、8、10 或 16，但 std::to_chars 的重载目前**只实现了 base = 10 的整数版本**，其余进制在 libstdc++ 和 libc++ 中均未实现，调用时可能崩溃或静默失败。
常见错误现象：std::to_chars(buf, buf + size, 255, 16) 编译通过，但运行时报 std::errc::invalid_argument 或写入乱码；Clang/libc++ 甚至直接断言失败。
- 别信文档里“
base参数可选”的误导——实际可用范围是空集（除 10 外） - MSVC 的
std::to_chars同样不支持非十进制，行为一致 - 若你看到某处代码用
base=16成功了，大概率是误用了其他库（如 fmtlib）或混淆了std::from_chars
替代方案：用 std::format（C++20）或手动实现十六进制/二进制
真正能安全输出多进制字符串的是 std::format（C++20），它语法简洁且标准保证支持：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
char buf[32];
auto res = std::format_to(buf, "{:x}", 255); // → "ff"
std::format_to(buf, "{:#b}", 5); // → "0b101"
如果你卡在 C++17 或需极致性能（std::format 有动态内存和格式解析开销），就得手写：
- 十六进制：用查表法（
"0123456789abcdef"）+ 位运算，循环取低 4 位 - 二进制：类似，每次取低 1 位，但注意前导零控制
- 八进制：每次取低 3 位，最多 11 次（32 位 int）
- 务必从高位开始填充缓冲区，避免反转；预留足够空间（如 uint32_t 十六进制最多 8 字符 + '\0'）
为什么不用 sprintf / std::to_string + base 转换？
sprintf(buf, "%x", x) 可用，但它是可变参数函数，类型不安全，且无法直接返回 std::to_chars 那种 std::to_chars_result 结构体（含错误码和结束指针）；std::to_string 只支持十进制，强行转进制要依赖 std::stringstream，开销大、不可控。
-
sprintf在嵌入式或禁用 C 库场景下不可用 -
std::stringstream会分配堆内存，且格式控制弱（比如不能直接指定小写/大写十六进制） - 若你已在用
std::to_chars做高性能数字转字符串流水线，混入sprintf会破坏一致性
实际项目中怎么选？
判断依据就两条：C++ 标准版本、是否允许第三方依赖。
- C++20 可用 → 优先
std::format，语义清晰，标准保证，支持{:x}、{:X}、{:b}、{:o} - 必须 C++17 且拒绝第三方 → 手写十六进制转换（几十行足够），比调用
std::to_chars加后续进制转换更可靠 - 已引入
fmt库 → 用fmt::format("{:x}", x)，性能接近手写，API 更丰富 - 别尝试给
std::to_chars传非 10 的base——它不是预留接口，是未实现功能
真正容易被忽略的是：很多开发者看到 std::to_chars 函数签名里有 int base = 10 就默认它“支持进制切换”，结果在生产环境踩到未定义行为，而错误日志里只显示乱码或截断，很难溯源。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
