HTML5 input type="number" 不自动格式化数值，仅做基础约束；显示格式化需 JS（如 Intl.NumberFormat）或 CSS；Intl.NumberFormat 对 locale 敏感，需 fallback；移动端数字键盘应优先用 inputmode；旧项目易忽略空值和非法输入处理。
HTML5 的 input type="number" 真的能自动格式化数值？
不能——它只做基础约束，不负责千分位、小数点后几位、货币符号等“视觉格式化”。很多人误以为加了 type="number" 就能像 Excel 那样显示 1,234.56，结果发现输入框里始终是纯数字，连逗号都不出现。
- 浏览器原生
input[type=number]只控制：是否允许非数字字符、是否触发软键盘数字模式、是否支持上下箭头微调、是否校验min/max/step - 它返回的
value始终是字符串（如"1234.5"），valueAsNumber才是数字类型，但依然不带格式 - 真正做“显示格式化”的是 JS 层（比如
Intl.NumberFormat）或 CSS（仅限视觉欺骗，不可靠）
用 Intl.NumberFormat 格式化数值时，为什么 locale 一换就出错？
因为 Intl.NumberFormat 对 locale 参数极其敏感：传错值（比如 "zh-CN" 写成 "zh" 或 "cn"）、浏览器不支持该 locale、甚至 iOS Safari 对某些 locale 的兼容性差，都会导致回退到默认英文格式，或直接抛 RangeError。
- 安全写法是显式指定 fallback：
new Intl.NumberFormat(navigator.language || 'en-US', { minimumFractionDigits: 2 }) - 不要依赖用户
navigator.language的原始值——先用Intl.LocalesMatcher或简单白名单校验（如['en-US', 'zh-CN', 'ja-JP']） -
style: 'currency'必须配currency，否则报错；currencyDisplay: 'symbol'在旧版 Safari 中可能显示为代码（如USD）而非$
为什么在移动端，input type="number" 有时弹不出数字键盘？
不是 bug，是规范行为：Android Chrome 和 iOS Safari 会根据 pattern、inputmode 和 type 组合决定键盘类型。type="number" 本身不保证数字键盘，尤其当输入内容含小数点或负号时，部分系统会降级为全键盘。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 优先用
inputmode="decimal"（对小数）或inputmode="numeric"（对整数），它比type更直接控制键盘 -
pattern="[0-9]*"在 iOS 上可强制数字键盘，但会禁用粘贴和长按选中——权衡取舍 - 避免同时设
type="number"+inputmode="text"，行为未定义，Chrome 可能忽略后者
旧项目迁移到 HTML5 数值处理，最常漏掉的兼容性补丁是什么？
不是 polyfill valueAsNumber，而是忘记处理「空值」和「非法输入」的边界情况。HTML5 input[type=number] 在用户删光内容时，value 是空字符串 ""，valueAsNumber 是 NaN——但很多旧逻辑默认它至少是 0 或保持上一次有效值。
立即学习“前端免费学习笔记（深入）”；
- 读值时别直接
Number(input.value)，它把""转成0，掩盖了用户主动清空的意图 - 稳妥写法：
input.value === '' ? null : input.valueAsNumber - 监听
input事件时，需区分是用户输入、程序赋值、还是浏览器自动修正（如输入12.3.4后被截断为12.3）
真正的坑不在“怎么加新特性”，而在“旧逻辑是否还假设数值永远存在”。
