parseInt返回int基本类型，valueOf返回Integer包装类对象；前者适用于数值计算，后者适用于集合存储和缓存优化（-128~127），但二者对null、空字符串等均抛NumberFormatException，且进制解析需显式指定。
parseInt 返回基本类型，valueOf 返回包装类对象
两者都做字符串转整数，但返回值类型不同：Integer.parseInt("123") 返回 int，而 Integer.valueOf("123") 返回 Integer 对象。这直接影响后续是否能调用 toString()、compareTo() 这类对象方法，也影响自动拆箱场景下的空指针风险。
常见错误现象：把 valueOf 结果直接赋给 int 变量看似没问题，但如果传入 null 或非法字符串，抛出的异常一样是 NumberFormatException；但若先用 valueOf 得到 null（比如缓存范围外又没处理好），再调用 .intValue() 就会触发 NullPointerException。
- 需要数值计算、传参给接受
int的方法时，优先用parseInt - 需要放进集合（如
ArrayList<integer></integer>）、参与泛型操作、或想利用缓存优化时，用valueOf -
valueOf在-128到127范围内复用缓存对象；超出范围每次新建Integer实例
空字符串、null 和空白字符都会导致 NumberFormatException
很多人以为只有字母才会报错，其实 parseInt("")、parseInt(" ")、parseInt(null) 全部抛 NumberFormatException。JVM 不做 trim，也不接受空值——这点和 Double.parseDouble 一致，但和某些工具类（如 Apache Commons Lang 的 NumberUtils.toInt）不同。
使用场景：从 HTTP 参数、配置文件读取数字时，原始字符串很可能带空格或为空。别指望 parseInt 自动容错。
立即学习“Java免费学习笔记（深入）”；
- 务必在调用前用
str != null && !str.trim().isEmpty()做基础校验 - 如果想统一兜底（比如转失败就返回 0），自己封装一层，别依赖 JDK 默认行为
- 注意
trim()会产生新字符串，在高频调用场景下有 GC 压力，可改用循环跳过首尾空白字符的轻量判断
进制参数容易被忽略，导致十六进制或二进制解析出错
parseInt 和 valueOf 都支持第二个参数指定进制，比如 parseInt("FF", 16) 返回 255。但如果不传，默认是十进制——这意味着 parseInt("0xFF") 会直接抛异常，因为 x 不是十进制合法字符。
常见错误现象：从日志或调试器里复制了带 0x 前缀的十六进制数，直接丢给 parseInt，结果崩溃；或者误以为字符串开头的 0 表示八进制（Java 中不成立，那是老式 C 风格，JDK 不识别）。
- 十六进制字符串必须去掉
0x前缀，再显式传16；八进制同理去0前缀 + 传8 - 二进制用
parseInt("1010", 2)，不能写成"0b1010"（JDK 7+ 支持字面量但不支持字符串解析） - 进制值必须在
Character.MIN_RADIX（2）到Character.MAX_RADIX（36）之间，否则抛IllegalArgumentException
性能差异微乎其微，但缓存行为会影响内存和比较逻辑
单纯看执行耗时，parseInt 和 valueOf 在 HotSpot 上几乎没差别。真正要注意的是：用 valueOf 时，小整数（-128~127）复用同一个对象，所以 valueOf(42) == valueOf(42) 是 true；而 parseInt(42) == parseInt(42) 是数值相等，但它们是两个独立的 int 值，没法用 == 比对象引用。
容易踩的坑：有人用 valueOf 后习惯性写 == 比较，结果在缓存范围外突然失效；还有人把 valueOf 当作“更安全”的替代方案，其实它对输入校验一点不比 parseInt 宽松。
- 永远不要用
==比较两个Integer对象的值，用.equals()或先intValue() - 如果业务明确只处理小整数且频繁创建，
valueOf省点对象分配开销；否则选parseInt更直白 - GC 压力敏感场景（如实时数据处理），避免无意义地用
valueOf包装再立刻拆箱
最麻烦的其实是混合使用——比如 DAO 层用 valueOf 存进 Map，Service 层用 parseInt 做计算，中间还穿插了 == 判断。这种隐式类型跳跃，比转换本身更容易埋雷。
