int.TryParse 是判断字符串是否为整数最稳妥的方式，它不抛异常、支持负号和空格、返回明确 bool 值，性能优于正则且语义清晰。
用 int.TryParse 判断字符串是否为整数最稳妥
绝大多数情况下，你根本不需要正则——int.TryParse 是 C# 里判断「纯整数字符串」最快、最安全、最符合直觉的方式。它不抛异常、能处理负号和空格（可选）、返回明确的 bool 结果。
常见错误现象：int.Parse("123abc") 直接炸出 FormatException；Convert.ToInt32("") 炸出 ArgumentNullException；自己写循环逐字符判断容易漏掉 "-0" 或开头空格。
- 只验证整数？用
int.TryParse(input, out int _)，别管输出值，只看返回值 - 想允许开头/结尾空格？默认就支持，无需额外 trim
- 要严格禁止空格（比如协议字段）？先
input.Trim() == input再试 - 性能上，
TryParse比正则快 5–10 倍，且无编译/缓存开销
验证浮点数用 double.TryParse 而不是正则
正则写 ^-?\d+\.?\d*$ 看似简单，实则漏掉科学计数法（"1e-3"）、Unicode 数字、甚至合法的 "NaN" 或 "Infinity"。而 double.TryParse 内置支持所有 .NET 数值格式约定。
使用场景：表单输入校验、配置文件读取、API 参数解析——只要最终要转成数值参与计算，就该用 TryParse。
- 默认使用当前线程文化（如小数点是逗号），需跨文化一致时传
CultureInfo.InvariantCulture -
"123."和".45"在某些文化下合法，在另一些下不合法，TryParse自动适配 - 别用
float.TryParse验证用户输入，精度丢失太容易误导（比如"0.1"存成0.10000000149011612）
正则只在「模式匹配」时才值得用，比如提取数字或校验格式
如果你不是为了转数字，而是要确认字符串「长得像电话号码」「含且仅含 6 位数字」「开头是字母后跟 4 位数字」——这时候正则才有意义。拿它做类型判断，属于工具错配。
常见错误现象：Regex.IsMatch(input, @"^\d+$") 认为 "0123" 合法（前导零没问题），但 int.Parse("0123") 解析出来还是 123；更糟的是，它把 "\u0661\u0662\u0663"（阿拉伯数字）判为不合法，而 int.TryParse 能正确识别。
- 必须用正则？至少加上
RegexOptions.CultureInvariant避免文化干扰 - 验证「纯数字字符串」且要求无前导零？用
^[1-9]\d*|0$，但注意这和数值合法性无关 - 性能敏感场景（如日志行过滤），预编译正则：用
static readonly Regex s_digitOnly = new(@"^\d+$")
IsNumeric 不存在，别搜这个函数名
C# 没有全局的 IsNumeric 方法，.NET 6+ 的 string.IsAsciiDigit() 只判单字符，char.IsDigit() 会把全角数字也当真——这些都不是你想要的「字符串能否转成数字」的等价判断。
容易踩的坑：有人翻文档看到 Microsoft.VisualBasic.Information.IsNumeric，但它行为诡异（"123E4" 返回 true，"123.45.67" 也返回 true），且依赖 VB 运行时，纯 C# 项目不该引入。
- 别封装一个叫
IsNumeric的方法对外暴露，调用方会误以为它覆盖所有数字形式 - 如果业务上真需要「宽松数字」（如接受逗号分隔符、货币符号），明确命名成
IsMoneyLike或CanParseAsCurrency - 最复杂的其实是「带单位的数字」（如
"12.5MB"），这种必须拆解 + 自定义规则，TryParse 和正则都解决不了
事情说清了就结束
