为什么 "07" 正常但 "08" 不正常？
这跟 JavaScript 八进制解析的历史遗留行为有关：
在 JavaScript 的早期规范（ES3/ES5 non-strict mode）中，以 0 开头的数字字面量会被当作八进制数：
字符串 八进制解读 结果
"01" ~ "07" 合法的八进制数（0-7都在八进制范围内） 正常解析为 1~7 ✅
"08" 非法八进制（8不在0-7范围内） 解析失败 ❌
"09" 非法八进制（9不在0-7范围内） 解析失败 ❌
"10" 不以0开头，按十进制 正常解析为 10 ✅
虽然现代 JS 引擎（ES5 strict / ES6+）中 Number("08") 已经能正确返回 8，但宜搭的 numberField 组件内部可能使用了旧版解析逻辑或自定义校验，仍然保留了这种行为：
"01" ~ "07" → 恰好是合法八进制，解析成功，显示正常
"08", "09" → 非法八进制，解析失败，值被清空
"10" 及以上 → 不以单个 0 开头，按十进制解析，正常
这就是为什么偏偏只有8和9出问题，而不是所有带前导零的学号都出问题。 这个规律完美匹配你观察到的现象。
加了 parseInt(str, 10) 后，第二个参数 10 强制按十进制解析，"08" → 8、"09" → 9，彻底绕过了这个问题。
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
这个现象大概率不是数字组件“存错了”，而是取值之后经过了一次不带基数的整数解析，08、09 被当成了八进制或非法八进制字面量。
可以按下面几步定位：
08，再在提交动作里用 console.log 或流程变量查看原始值。如果原始值还是字符串 "08"，说明问题在后续计算。parseInt(value)、parseInt(value, 8)、Number("0" + value) 这类写法。parseInt("08", 8) 会得到 0，parseInt("09", 8) 会得到 NaN；在严格模式下，08、09 本身也不是合法的八进制字面量。Integer.decode() 这类按前缀判断进制的方法，它会把前导 0 当八进制。修复建议：
parseInt(value, 10)，不要省略第二个参数。08 这种形式。String(value).padStart(2, "0") 展示，存储仍用整数。/^(0|[1-9]\d*)$/，拒绝前导零输入，避免脏数据进入流程。我这边没法直接看到你的表单配置，如果方便，把“数字组件 → 提交动作 → 公式/流程节点”的截图发出来，尤其是中间有没有 parseInt 或类型转换，基本就能定位到具体是哪一步把 08 变成了 0。
宜搭 numberField 组件存在八进制解析 Bug。
现象：输入 "01"~"07" 正常，但 "08"、"09" 被清空或报错。
原因：底层可能沿用了旧版 JS 逻辑（如 parseInt 未指定基数时，以 0 开头的字符串会被误判为八进制）。八进制仅含 0-7，故 8 和 9 非法导致解析失败。
解决：在数据提交或校验环节，强制使用 parseInt(str, 10) 明确按十进制解析，即可修复。建议官方尽快更新组件逻辑，统一采用显式基数解析以避免此类历史遗留问题。
官方详细解决方案：https://www.aliyun.com/product/applicationservice/yida
