IE11企业模式下parseInt解析带前导零日期组件异常求助

该异常是parseInt的历史兼容行为导致的，和split拆分日期字符串的逻辑无关。
在ES5规范正式统一解析规则之前，parseInt的默认进制采用动态判断逻辑：如果待解析字符串以"0"开头，引擎会自动将其识别为八进制数处理。Chrome、Edge等现代浏览器遵循ES5及后续规范，对带前导零的字符串默认按十进制解析，因此可以正确将"03"解析为数值3；但IE11企业模式通常会模拟旧版IE的脚本执行环境，沿用了ES5之前的老解析规则：

• 对于"03"这类八进制合法值，解析结果虽然数值碰巧和十进制一致，但遇到"08"、"09"这类八进制规则下不存在的数字时，会直接截断解析返回0，完全不符合业务预期。

给每一处parseInt调用显式传入第二个参数10，强制指定按十进制规则解析，彻底消除旧引擎的自动进制判断逻辑，即可覆盖所有兼容场景。
修改后的代码示例：

var inputDateText = $(this).val(); // 示例输入：30/03/2021
var splitComponents = inputDateText.split('/');  // 拆分结果：['30','03','2021']

if (splitComponents.length === 3) {
    // 所有parseInt统一指定十进制基数
    var day = parseInt(splitComponents[0], 10); // 正确返回30
    var month = parseInt(splitComponents[1], 10); // 正确返回3
    var year = parseInt(splitComponents[2], 10); // 正确返回2021
}

• 通用兼容最佳实践：所有使用parseInt的场景，都建议显式传入进制参数10，不要依赖浏览器默认的判断逻辑，从根源上避免旧版浏览器的历史规则带来的兼容问题。
• 原代码的长度判断splitComponents.length > 0存在逻辑漏洞：只要拆分出任意非空片段就会进入后续流程，实际日期格式校验需要拿到完整的日、月、年三段，建议改为严格判断长度为3，避免非法输入导致的计算异常。
• 替代实现：也可以使用Number()方法直接转换分段字符串，该方法对带前导零的字符串默认按十进制解析，不存在八进制自动判断的历史问题，效果和显式传10的parseInt完全一致，适合更简洁的代码写法。

内容的提问来源于stack exchange，提问作者user10216769