Number.isInteger不会将字符串"123"当作整数，它只对number类型且为整数的值返回true；需先用Number()转换再校验，并结合范围判断确保业务安全。
Number.isInteger 会把字符串 "123" 当成整数吗
不会。Number.isInteger 只对真正的 number 类型且为整数的值返回 true，遇到字符串、null、undefined、NaN 或小数一律返回 false。业务中常见的参数如 URL 查询参数、表单输入、JSON 接口字段，多数是字符串，直接传进去必然失败。
实操建议：
- 先用
parseFloat或一元加号+尝试转为数字，再判断是否为有效整数 - 注意
parseFloat("123abc")会返回123，而Number("123abc")返回NaN，后者更严格 - 避免只靠
parseInt，它会截断（如parseInt("12.9") === 12），且默认十进制但可能误判进制（parseInt("010")在旧环境是八进制）
如何安全校验一个可能为字符串的业务参数
典型场景：API 接收 id=123（字符串）或 page=2（字符串），需要确认它是合法整数且在合理范围内。
推荐写法：
function isValidInteger(str) {
const num = Number(str);
return Number.isInteger(num) && num >= 0 && num <= 999999;
}
关键点：
- 用
Number()而非parseInt或parseFloat：它对非数字字符串（如"12a"、""、" "）统一返回NaN，语义更干净 -
Number.isInteger(NaN)是false，所以无需额外判断isNaN - 业务通常有取值范围（如分页
page不能为负），必须叠加范围检查，否则-123或极大数（如1e20）也会通过isInteger
Number.isInteger 在 Node.js 和浏览器中的兼容性差异
Number.isInteger 是 ES6 标准方法，在 IE 全系不支持，Node.js 0.12 及更早版本也不支持。但实际项目中，只要不是维护老 IE 系统，基本可放心使用。
如果真要兼容：
- 不建议手写 polyfill（比如
typeof x === 'number' && x % 1 === 0）——它对Infinity和-Infinity返回true，而原生Number.isInteger返回false - 更稳妥的是用
Number.isSafeInteger替代（它同时检查整数性和安全整数范围），但要注意：它会拒绝大于2^53-1的整数，而业务 ID 若来自后端 bigint，可能被误判 - 现代项目优先用 Babel 或 TypeScript 编译，无需手动处理兼容性
为什么不能只用 typeof value === 'number' 做判断
因为 typeof 12.5 === 'number' 也成立，但 12.5 不是整数；typeof NaN === 'number' 同样成立，但它根本不是有效数字。
常见错误现象：
- 接口收到
{ page: "2.5" }，仅用typeof req.query.page === 'number'判断，结果永远是false（因为它是字符串），看似“防住了”，实则掩盖了类型转换缺失的问题 - 前端传了
id: 12.0（JS 数字字面量），后端用Number.isInteger(12.0)是true，但若后续做数据库查询时误当浮点处理，可能触发隐式类型转换或精度问题 - 某些框架（如 Express）会自动把查询参数转成字符串，但 body-parser 解析 JSON 时又可能是数字——这种不一致必须在验证层统一收口
真正要守住的，是「输入 → 显式转数字 → 整数性 + 范围校验」这个链条。少一步，参数就可能在下游引发 TypeError 或逻辑错乱。
