揭开parseInt的面纱：掌握JavaScript数字转换的核心秘诀

OK,咱们今天就来聊聊JavaScript里那个看起来简单、用起来却经常让人挠头的parseInt，说真的，我第一次用它的时候，觉得这玩意儿不就是把字符串转成数字吗？能有啥坑？结果，现实狠狠给我上了一课。

记得那是一个深夜,我还在赶一个前端需求，页面上有几个输入框，用户输入数字，我拿值做计算，用parseInt转呗，多自然，测试的时候，输入“10”没问题，输入“010”的时候……等等，怎么变成8了？我当时就懵了，反复检查代码，差点怀疑人生，后来才知道，哦，原来parseInt会自作主张地把以0开头的字符串当成八进制处理！这什么古董设定啊……

所以你看,parseInt根本不是我们想象中那么“单纯”，它有时候特别有主见，甚至有点固执，比如它还有一个隐藏技能：允许字符串后面跟非数字字符。parseInt("123abc")居然返回123，它也不报错，就默默忽略掉不能转换的部分——这脾气，说好听点是宽容，说难听点就是不负责任啊。

而且很多人可能从来没注意过第二个参数：进制基数，如果你不传，parseInt就自己猜，有时候猜对，有时候猜错，全看字符串长什么样，0x10”会被当成十六进制处理，返回16，但如果你明确传了10，那它就会老老实实按十进制来，我现在养成了一个习惯：只要用parseInt，必传第二个参数，就算写parseInt("10", 10)显得有点啰嗦，但也比半夜debug强对吧？

说到这里,我想起另一个坑，parseInt还会自动截断小数部分，但不是四舍五入，是直接砍掉。parseInt("10.9")给你10，一点都不带犹豫的，如果你需要处理小数，还不如直接用Number()或者parseFloat()，至少人家诚实。

不过话说回来,parseInt也不是一无是处，在处理一些宽松格式的用户输入时，它的这种“随意”反而成了优点，比如用户输入“¥100”，你用Number直接转得到NaN，但用parseInt还可能捞回来个100（虽然货币符号其实也不该这么处理……），但这就像用一把钝刀切菜，有时候能切，有时候却搞得一团糟。

我现在越来越觉得,parseInt就像那个性格有点古怪的老朋友——你们很熟，但偶尔还是会因为它的一些老习惯而头疼，真正掌握它，不是死记它的规则，而是理解它为什么这样设计（哪怕有些设计已经过时），然后知道在什么时候该用它，什么时候该换更合适的工具。

所以下次当你顺手写下parseInt的时候,不妨停一下，问问自己：这个字符串到底长什么样？我需要处理进制吗？需不需要严格转换？也许很多时候，Math.floor()、Number()或者一元运算符+反而是更清晰的选择。

好了,今天就唠叨这么多，希望你们能少走一点我当年走过的弯路——虽然debug的夜晚也挺令人怀念的，哈哈。