std::stoi不能直接处理"0x"开头的字符串，因其默认按十进制解析，需显式传入base=0才能自动识别前缀；正确用法是std::stoi("0xFF", nullptr, 0)返回255。
std::stoi 为什么不能直接处理 "0x" 开头的字符串？
因为 std::stoi 默认按十进制解析，除非显式指定进制。传入 "0xFF" 会停在 'x' 处，只转出 0，并抛出 std::invalid_argument 或静默截断——这和你期望的十六进制转换完全不符。
正确做法是传入第三个参数 0，让函数自动识别前缀：std::stoi("0xFF", nullptr, 0) 返回 255；std::stoi("FF", nullptr, 16) 也返回 255，但必须确保输入不含前缀。
- 前缀
"0x"或"0X"仅在base == 0时被识别 - 若字符串含空格或不可见字符（如
"\tFF"），std::stoi会直接失败，需提前trim - 超出
int范围（如"0xFFFFFFFF"）触发std::out_of_range，应改用std::stoul或std::stoull
如何安全地从任意长度十六进制字符串转 uint64_t？
用 std::stoull + base=16 是最简方案，但必须处理异常和溢出边界。C++ 标准库不提供“只读有效字符”的解析，所以 "FFG" 这种非法字符会抛 std::invalid_argument。
示例：
立即学习“C++免费学习笔记（深入）”；
try {
auto val = std::stoull("1A3F", nullptr, 16); // 返回 6719
} catch (const std::invalid_argument&) {
// 输入含非 hex 字符（如 'G', ' ', '\n'）
} catch (const std::out_of_range&) {
// 超过 uint64_t 表示范围（> 0xFFFFFFFFFFFFFFFF）
}- 不要依赖
nullptr作为idx参数——它无法告诉你实际解析了多少位 - 若需校验是否“全部字符都被消费”，传入非空
size_t* idx并检查*idx == input.length() - 小写和大写字母都支持，
"a"和"A"均被接受
手写 hex 转数字时容易忽略的边界：空字符串、全空白、超长
标准库函数已覆盖大部分场景，但若需极致控制（比如嵌入式无 STL 环境），手写解析必须直面三类输入：
-
""：返回 0 还是报错？取决于协议，但多数协议视为空值，应明确约定 -
" \t\n "：std::isspace检查后跳过，否则stoull直接抛异常 -
"00000000000000000000FF"：虽合法，但stoull仍能处理；手写时若用uint32_t累加，会在第 9 个字符就溢出
关键点：十六进制每字符代表 4 bit，20 个字符即 80 bit —— 已超出 uint64_t。此时必须用大数库或拒绝输入。
std::from_chars 是 C++17 的更优选择吗？
是，但限制明显：std::from_chars 不支持自动前缀识别（"0x"），也不支持大小写混合输入（它只认 'a'–'f'，不认 'A'–'F'），且不跳过空白。
示例：
立即学习“C++免费学习笔记（深入）”；
std::string s = "FF";
uint64_t val;
auto [ptr, ec] = std::from_chars(s.data(), s.data() + s.size(), val, 16);
if (ec == std::errc()) {
// 成功，val == 255
}- 输入必须全小写，
"ff"可行，"FF"返回std::errc::invalid_argument - 返回的
ptr指向第一个未转换字符，可用于判断是否“全吃掉” - 无异常、无内存分配，性能优于
stoull，但可移植性差——MSVC 2019+、GCC 11+、Clang 12+ 才完整支持
真正难处理的不是转换逻辑本身，而是输入清洗和语义定义：你到底想把 "0xGG" 当错误、截断，还是忽略非法字符继续？这个决策比选哪个函数更重要。
