Number.parseInt() 不解析科学计数法，仅提取前导整数部分；它忽略空白、识别符号、按进制读取连续数字，遇e/E/.等即停止，适用于提取版本号、ID等开头整数，而非替代parseFloat()或Number()。
Number.parseInt() 本身不会解析科学计数法（如 "1e3"、"2.5e-2"），它只按指定进制读取**前导数字字符**，遇到非数字字符（包括 e、E、.）就停止。这看似是“缺陷”，但在处理含科学计数法的原始字符串时，反而能避免 parseInt() 被误当作数值解析而产生意外结果——但前提是你要清楚它**不是用来替代 parseFloat() 或 Number() 的**。
明确 parseInt() 的行为边界：它不理解浮点或指数
Number.parseInt()（等价于全局 parseInt()）设计目标是解析整数，规则如下：
- 忽略开头空白；
- 识别可选正负号；
- 从左到右按指定进制（默认 10）收集连续数字字符（对十进制就是
0–9）； - 一旦遇到非有效数字字符（如
e、E、.、+、-在数字后出现），立即停止解析，返回已得整数； - 若首个非空白字符就非法，返回
NaN。
例如：
Number.parseInt("123e4") → 123Number.parseInt("1e23") → 1Number.parseInt("-45.67e-8") → -45Number.parseInt("e10") → NaN
为什么这能“规避 Bug”？关键在控制解析意图
所谓“Bug”，常出现在开发者本意想提取字符串中**开头的整数部分**（比如版本号 "2.15.3e1"、日志 ID "ID123e45"），却错误使用 parseFloat() 或 Number() 导致被解释为科学计数法数值（parseFloat("123e4") === 1230000），或使用 parseInt() 却未意识到它会截断——而这恰恰是预期行为。
因此，“规避 Bug”的本质是：用对函数，做对事。当你只需要开头整数，就用 parseInt()；当你需要完整数值语义，就用 parseFloat() 或 Number()，并自行校验是否含 e/E 等可能引发歧义的字符。
安全提取整数部分的推荐做法
-
显式传入进制：永远写
Number.parseInt(str, 10)，避免八进制误解析（如"012"）； -
先校验格式（可选）：若需确保字符串“纯整数”，可用正则
/^-?\d+$/预检，再用parseInt； -
区分场景选择 API：
- 要整数 ID、序号、版本主版本号 →
Number.parseInt(str, 10)； - 要还原原始数值含义（如配置项
"3.2e-5"）→ 先用/[eE]/.test(str)判断，再用parseFloat(str)并检查isFinite()； - 要严格拒绝科学计数法输入 → 正则匹配
/^-?\d+(\.\d+)?$/后转Number()。
- 要整数 ID、序号、版本主版本号 →
一个典型对比示例
输入字符串："100e2abc"
-
Number.parseInt("100e2abc", 10)→100（安全截断，符合“取开头整数”意图） -
parseFloat("100e2abc")→10000（解析为100 × 10²，后续"abc"被静默忽略） -
Number("100e2abc")→NaN（整个字符串无法转为有效数值）
三者结果不同，没有“对错”，只有是否匹配你的业务逻辑。
