Convert.ToInt32(string, 16) 是最快最稳的十六进制转整数方法，但需显式指定基数16；带"0x"前缀或非法字符会抛异常，应先清理前缀或改用int.TryParse(s, NumberStyles.HexNumber, ...)容错处理。
用 Convert.ToInt32(string, 16) 最快最稳
直接调用 .NET 内置方法就行，不用自己写循环或查表。它专为这种场景优化，处理合法十六进制字符串（如 "FF"、"0x1A"、"aB3"）没问题。
注意：必须传入进制基数 16，漏掉会默认按十进制解析，结果完全不对 —— 比如 Convert.ToInt32("FF") 得到的是 FF 十进制值 255？错，它其实解析成十进制的 255，但字符串 "FF" 并不是十进制写法，这步会直接抛 FormatException。
-
Convert.ToInt32("FF", 16)→ 返回255 -
Convert.ToInt32("0x1A", 16)→ 报错，Convert不识别0x前缀 - 字符串含空格、换行、中文字符？一律抛
FormatException - 超范围（如
"FFFFFFFF"转int）会抛OverflowException
处理带 0x 前缀的字符串得先清理
很多硬件协议、调试日志、JSON 字段里十六进制数带 0x，比如 "0xFF" 或 "0xdeadbeef"。Convert.ToInt32 不吃这套，必须手动去掉前缀再转。
别用 .Replace("0x", "") —— 它会误杀中间含 0x 的字符串（比如 "abc0xdef"）。稳妥做法是检查开头：
-
str.StartsWith("0x", StringComparison.OrdinalIgnoreCase)→ 然后取str.Substring(2) - 或者更懒但安全：用正则
Regex.Replace(str, "^0x", "", RegexOptions.IgnoreCase) - 如果不确定有没有前缀，统一走
TryParse更省心（见下节）
要容错就用 int.TryParse(string, NumberStyles.HexNumber, ...)
线上代码别裸奔 Convert.ToInt32，一出错就崩。用 TryParse 是标准防御姿势，尤其面对用户输入、日志解析、配置文件等不可信来源。
NumberStyles.HexNumber 是关键：它允许前导空格、0x 前缀、大小写字母，比手撕判断靠谱得多。
- 支持
" 0xFF "、"0Xab"、"dead"，全部能成功解析 - 失败时不抛异常，只返回
false，变量保持原值或初始化为 0 - 记得传
CultureInfo.InvariantCulture，避免某些区域设置把字母当数字（极少见但存在） - 示例：
int.TryParse("0x1F", NumberStyles.HexNumber, CultureInfo.InvariantCulture, out int result)
大数或无符号数不能硬塞 int
十六进制字符串可能超 int.MaxValue（0x7FFFFFFF），比如 "FFFFFFFF" 是 4294967295，已超出有符号 32 位范围。这时候转 int 必炸，但实际你可能只需要 uint、long 或 ulong。
- 转无符号：
uint.TryParse(s, NumberStyles.HexNumber, null, out uint u) - 转 64 位：
long.TryParse(s, NumberStyles.HexNumber, null, out long l) - 超 8 字节？上
BigInteger.Parse(s, NumberStyles.HexNumber)，但注意它不带TryParse版本，仍需 try/catch - 别图省事全用
long—— 小数值用int更省内存、CPU 缓存友好
进制转换本身没玄学，难的是边界判断和上下文适配。比如一个日志字段写着 "0x00000001"，看着小，但若协议定义它是 64 位标志位的一部分，你就得按 ulong 解析，否则高位全丢。这种隐含契约，比语法更常埋雷。
