indexOf和lastIndexOf是List接口方法，不支持原始数组；基本类型数组需转为包装类型再用Arrays.asList()；返回-1表示未找到，非异常；依赖equals()比较，注意泛型与自动装箱陷阱。
Java 中 indexOf 和 lastIndexOf 只适用于 List 实现类，不支持原始数组
这两个方法是 java.util.List 接口定义的，所以只有 ArrayList、LinkedList 这类对象能直接用；如果你手头是个 int[] 或 String[]，调用会编译报错——因为数组不是 List。
常见错误现象：int[] arr = {1,2,3}; arr.indexOf(2); // 编译失败：找不到符号
- 要用数组，先转成
List：Arrays.asList(arr)，但注意：对基本类型数组（如int[]）会把整个数组当一个元素，得改用包装类型数组（Integer[]） -
Arrays.asList()返回的是不可变List，不能增删，但indexOf/lastIndexOf可以安全调用 - 如果真要查原始
int[]，老实用 for 循环或IntStream.range().filter()
indexOf 找不到时返回 -1，不是抛异常
这是很多人误以为“没找到就该报错”的地方。它设计就是返回 -1 表示未命中，和 String.indexOf() 逻辑一致。
使用场景：判断元素是否存在 + 获取首次位置，常合并写成：if (list.indexOf(x) != -1) { ... }
- 别用
== null或try-catch判断是否找到，那是典型误用 - 如果元素是
null，indexOf(null)是合法的，会找第一个null元素（前提是 List 允许存null） - 注意引用比较：对自定义对象，依赖
equals()方法；若没重写，只比内存地址，很可能始终返回-1
lastIndexOf 不是“倒序遍历”，而是从末尾开始线性查找
它的行为不是先 Collections.reverse() 再 indexOf，而是从索引 size()-1 往前逐个调用 equals()，时间复杂度仍是 O(n)，不会更慢也不会更快。
性能影响：单次调用和 indexOf 几乎无差别；但若反复查同一元素的首尾位置，不如一次遍历记录两个索引。
- 对空
List，两个方法都返回-1 - 如果元素只出现一次，
indexOf(x) == lastIndexOf(x)成立 - 不要假设
lastIndexOf比indexOf“更耗资源”——JVM 层面没有特殊优化，代码里也看不出差异
泛型擦除下，indexOf 对子类实例可能意外匹配
比如 List<Number> 里存了 Integer 和 Double，你传个 Long 进去查，只要 Long.equals(Integer) 为 false 就不会错配；但若传的是 new Integer(42)，而列表里是 new Long(42)，它们 equals() 一定为 false，没问题。
真正容易踩的坑是：用错类型参数导致编译通过但语义错误。例如：
List<String> list = Arrays.asList("a", "b");
list.indexOf(98); // 编译通过！因为 98 被自动装箱为 Integer，再被隐式转为 Object，最终调用 String.equals(Integer) → 永远 false
- IDE 通常会警告“comparing incompatible types”，但不启用检查就容易忽略
- 编译器不阻止，是因为
indexOf(Object)接收任意Object，类型安全靠开发者自己保障 - 最稳妥做法：确保传入参数类型与泛型声明一致，或至少是其子类/可比较类型
-1 可能不是因为没找到，而是压根没比对成功。 
