后端数字字符串需按用途安全处理：计算用Number()校验后转换，展示/比对保留原字符串，金融运算用BigInt或decimal.js；禁用parseInt/parseFloat，优先Number()+显式校验，注意空格、全角字符及null/undefined。
后端接口返回的数字常以字符串形式存在（比如 "123"、"0.00" 或 "1e5"），而前端计算或比较时若直接使用，容易引发隐式类型转换错误、精度丢失或逻辑异常。关键不是“统一转成数值”，而是根据用途选择**安全、明确、可预期**的处理方式。
区分用途：计算用 Number，展示/比对优先保留字符串
很多问题源于把所有数字字符串都无脑转 Number：
-
做加减乘除、大小比较？ → 用
Number(str)或一元加号+str，但必须先校验有效性 -
用于展示、传参、ID、金额格式化、等值判断（如
id === "123"）？ → 直接用原字符串，避免浮点误差和意外截断（例如Number("0.30") === 0.3为 true，但"0.30" === "0.3"为 false） -
需要高精度运算（如金融）？ → 不要用
Number，改用BigInt（整数）或专用库（如decimal.js）
安全转换：别信 parseInt 和 parseFloat，优先用 Number() + 显式校验
parseInt("123abc") 返回 123，parseFloat("0.001e2") 可能出人意料；而 Number() 对非法输入返回 NaN，更可控：
function safeToNumber(str) {
if (typeof str !== 'string') return NaN;
const num = Number(str);
return isNaN(num) ? null : num; // 或抛错、返回默认值
}
// ✅ 推荐用法
const price = safeToNumber(data.price); // "99.99" → 99.99；"abc" → null
if (price != null && price > 100) { ... }
保留原始语义：用字段标记或结构化处理
接口字段含义不同，处理策略应不同。可在解析响应时就分类：
立即学习“Java免费学习笔记（深入）”；
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- ID、编码类（如
"000123"）→ 始终保持字符串，避免前导零丢失 - 金额、数量（如
"123.45"）→ 转Number后参与计算，但渲染时用toFixed(2)或Intl.NumberFormat - 科学计数法（如
"1.23e-4"）→Number()可正确解析，但显示建议转回标准小数字符串
示例：
const parsed = {
id: data.id, // 字符串原样保留
amount: Number(data.amount), // 用于计算
displayAmount: (Number(data.amount) || 0).toLocaleString('zh-CN', {
minimumFractionDigits: 2,
maximumFractionDigits: 2
})
};
防坑细节：注意空格、全角字符、null/undefined
后端返回的字符串可能含隐藏字符：
-
" 123 "→ 先trim()再转 -
"１２３"（全角数字）→Number()返回NaN，需正则替换或用toLocaleString等间接处理 -
null、undefined、""→Number(null) === 0，Number(undefined) === NaN，务必提前判断
简单兜底写法：
const num = Number(String(rawValue || '').trim()) || 0; // 但更推荐显式分支，避免 0 值掩盖真实空数据
不复杂但容易忽略：类型混用问题本质是契约不清。前端应按字段语义决定处理方式，而不是写个万能 toNumber() 函数一转了之。
