JavaScript校验用户输入关键在确认值是否可安全用于业务逻辑：数字需经parseFloat、isNaN、isFinite及字符串全等验证；邮箱/URL需前后端结合语义与结构校验；手机号、身份证须按号段和国标算法校验；日期、数值范围须转数字后严格判断。

JavaScript 实战中校验用户输入合法性，关键不是“判断类型”，而是“确认值是否可安全用于后续逻辑”。因为用户输入永远是字符串（或 undefined、null），直接用 typeof 或 instanceof 没有意义。真正要解决的是：这个输入能不能当数字用？是不是邮箱？是否符合身份证规则？有没有超出业务允许的范围？

数字类输入：别信 parseFloat 单独结果

用户输“10px”、“ 123 ”、“1e2”、“Infinity”，都可能被 parseFloat 解析出数字，但业务上往往只接受纯整数或常规十进制小数。

• 先用 parseFloat(str) 尝试提取数值候选
• 再用 Number.isNaN() 排除解析失败（如 “abc”）
• 接着用 Number.isFinite() 拦截 Infinity 和 -Infinity
• 最后用 Number(str) == str 验证转换前后字符串一致——这能筛掉 “10px”、“ 123 ”（带空格）、“0x10”（十六进制）等非常规写法

邮箱与 URL：语义 + 结构双校验

HTML5 的 type="email" 只做基础格式检查，比如 a@b.c 会被放过，但它根本不是合法邮箱。实战中建议分两层：

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

• 前端用正则粗筛：/^[^\s@]+@[^\s@]+\.[^\s@]+$/ —— 至少含 @、点、非空段落
• 后端必须做 DNS/MX 记录验证或发送确认邮件；前端可加一层“域名白名单”（如限制只能是 @company.com）提升业务安全性
• URL 同理，new URL(str) 可捕获协议和结构错误，但无法判断链接是否真实可达，需服务端探测

手机号与身份证号：地域规则不能省

单纯匹配“11位数字”远远不够。中国手机号前三位有明确号段（如 139、147、150–159、170–189、190–199），且不同运营商号段在动态更新；身份证第17位奇偶性决定性别，最后一位是根据前17位算出的校验码。

• 手机号推荐用权威号段库（如工信部公开数据）做前缀匹配，而非仅靠 /^1[3-9]\d{9}$/
• 身份证必须实现 GB11643-1999 标准的加权求和+模11校验算法，小写 x 要转大写再比对
• 注意兼容性：用户可能粘贴带空格、短横线、括号的格式（如 “110101 19900307 221X”），应先清洗再校验

日期与数值范围：避免字符串比较陷阱

用户输入 “2025-13-01” 或 “2025-02-30”，正则能过，但不是有效日期。用 new Date(str) 判断容易受浏览器差异影响（如 Safari 对 “2025/13/01” 返回 Invalid，Chrome 可能自动进位）。

• 优先用 date-fns 或 dayjs 等成熟库解析，它们对非法日期返回 Invalid Date 更稳定
• 手动解析时，拆成年、月、日三个数字，分别验证范围（月 1–12，日按年月查当月天数），再组合判断是否真实存在
• 数值范围校验（如年龄 18–120）务必在数字转换成功后进行，而不是对字符串做 >= '18' —— 字符串比较会出错（“100”

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南