Integer.parseInt返回int并抛NumberFormatException，Integer.valueOf返回Integer缓存对象（-128~127）；二者对null/空串处理一致，均抛异常；性能差异仅在高频场景显著；比较值须用equals()。
Integer.parseInt 会抛异常，Integer.valueOf 可能返回缓存对象
两者都用于把 String 转成整数，但行为差异明显：Integer.parseInt 返回的是基本类型 int，而 Integer.valueOf 返回的是包装类 Integer 对象。这意味着前者不涉及对象创建开销，后者在 -128 到 127 范围内会复用缓存实例。
-
Integer.parseInt("123")直接返回int值，若字符串非法（如"abc"或null），抛出NumberFormatException -
Integer.valueOf("123")先调用parseInt解析，再通过Integer.valueOf(int)包装——这个重载方法会对 [-128, 127] 的值返回缓存对象，超出范围则新建Integer - 如果后续要调用
intValue()或参与算术运算，用parseInt更轻量；若需传入泛型集合（如List）或作为对象传递，valueOf是更规范的选择
空字符串和 null 的处理方式完全一致
二者对非法输入的反应没有区别：遇到 null、空字符串 ""、仅含空白字符的字符串（如 " "），都会抛出 NumberFormatException。Java 不做隐式空值转换，也不会返回默认值。
- 不要指望
Integer.parseInt(null)返回0或null—— 它一定崩 - 校验建议统一前置：
str != null && !str.trim().isEmpty()，再调用转换方法 - 如果业务允许默认值，自己封装一层更安全，例如：
str == null || str.trim().isEmpty() ? 0 : Integer.parseInt(str.trim())
性能差异只在高频创建场景下才值得关心
单次调用几乎无差别，但循环中大量构造 Integer 对象时，valueOf 在缓存范围内有微弱优势；而 parseInt 始终略快，因为它跳过了对象包装步骤。
- 缓存范围固定为 [-128, 127]，由 JVM 参数
-Djava.lang.Integer.IntegerCache.high=xxx可调高上限，但不推荐随意改动 - 用
==比较两个Integer时，-128~127 内可能为true，超出范围一定是false——这是缓存导致的陷阱，比较值请始终用.equals()或先转int - 如果只是解析后立刻做计算（比如累加、比较大小），优先选
parseInt；如果要放进Map这类容器，必须用valueOf（或让自动装箱帮你做）
自动装箱不会绕过 parseInt 的异常逻辑
写 Integer i = "123" 是错的，Java 不支持字符串直接赋值给 Integer；但有人误以为 Integer i = Integer.parseInt("123") 会触发装箱优化——其实不会，这里只是把 int 结果赋给引用变量，JVM 会自动调用 Integer.valueOf(int) 来装箱，所以依然受缓存影响。
立即学习“Java免费学习笔记（深入）”；
- 下面两行效果等价：
Integer a = Integer.valueOf("123");和Integer b = Integer.parseInt("123");（后者靠自动装箱补全） - 但
Integer c = Integer.parseInt("200");和Integer d = Integer.valueOf("200");得到的是两个不同对象（c != d），尽管值相等 - 真正容易忽略的是：异常发生在解析阶段，不是装箱阶段——哪怕你写了
Integer x = someStr;（语法错误），编译就过不去，根本轮不到运行时异常
