JS Math.max 求最大值？小心这几个隐藏“陷阱”

日常开发里，面对一堆数据需要找出那个“领头羊”时，Math.max 几乎是第一时间跳出来的解决方案。但在实际项目中，直接套用往往容易翻车。这个看似简单的原生方法，在处理边界情况时其实挺“倔强”。

最常见的情况莫过于参数类型不对。很多人习惯拿到数组直接传进去，比如 Math.max([10, 20, 30])，结果返回了 NaN。这是因为 Math.max 本质上接收的是不定长的独立参数列表，而不是一个可迭代对象。当它接收到一个数组时，会尝试把整个数组当作一个数值去解析，自然失败了。

解决这个问题最顺手的办法是使用展开运算符。将数组打散成独立参数，写成 Math.max(...[10, 20, 30]) 或者 ES6 之前的 Math.max.apply(null, arr)。现在推荐直接用前者，代码直观且性能足够好。

比参数错误更隐蔽的坑，来自空数组。如果你的数据集可能为空，直接求最大值会得到 -Infinity。这在计算报表峰值或判断业务阈值时会引发逻辑漏洞。比如前端展示最高分，若无人提交时显示负无穷，体验极差。务必加上空值校验，在求值前判断数组长度，或者提供默认值兜底，像 Math.max(0, ...arr) 这样能确保最小不会低于基础阈值。

还有一个容易被忽视的性能边界：当数组数据量极大（例如超过几十万甚至百万条）时，使用展开运算符可能会触发调用栈溢出（Maximum call stack size exceeded）。JS 引擎对函数调用栈的深度有限制，一次性传递太多参数会导致内存爆炸。这时候千万别硬撑，改用循环遍历更稳妥。可以借助 Array.prototype.reduce 手动累加比较：

const maxVal = arr.reduce((a, b) => a > b ? a : b, arr[0]);

这种写法虽然少了点语法糖的帅气，但在处理海量日志分析或金融数据流时，稳定性远胜展开符。

此外，现实数据往往不是纯数字，而是包含对象的复杂结构。比如有一组用户信息，需要找出其中年龄最大的那位。这时不能直接把对象扔给 Math.max，得先提取关键字段。先用 map 映射出数字数组，再求最大，最后通过查找索引回到原对象。这种“先拆解后聚合”的思路，能保证逻辑清晰且不易出错。

掌握这些细节，能让你的代码更健壮。工具本身没有好坏，关键在于是否用在了合适的场景。下次遇到最大值需求时，多花两秒钟确认一下数据规模和格式，能省下后续不少排查 bug 的时间。毕竟，稳扎稳打的代码，才是团队资产中最有价值的部分。