应先检查 list != null && !list.isEmpty() 再用 get(size()-1)，或改用 ArrayDeque.getLast() 等更安全高效的方式，避免空指针、越界及性能问题。
用 list.get(list.size() - 1) 获取最后一个元素，但要先判空
直接用 size() 减 1 取索引是最常见做法，但它在空 List 上会抛 IndexOutOfBoundsException。不是所有调用方都记得加判断，尤其当 List 来自外部 API 或可选配置时。
- 必须检查
list != null && !list.isEmpty()，只判空不判 null 也会 NPE -
ArrayList的get()是 O(1)，但LinkedList是 O(n) —— 它得从头遍历到倒数第一，实际性能可能比你预期差很多 - 如果只是读取、不修改，这个方式足够轻量；但如果后续还要频繁访问首尾，就该考虑换数据结构了
改用 Deque 的 getLast() 更语义清晰，但要注意实现类差异
Deque 接口明确支持“末尾操作”，getLast() 比 get(size()-1) 更直白。但不是所有 Deque 实现都高效支持随机末尾访问。
-
ArrayDeque的getLast()是 O(1)，推荐作为默认选择 -
LinkedList虽然也实现了Deque，但它的getLast()是 O(1)（内部维护了 tail 指针），这点比用get(size()-1)强得多 -
PriorityQueue不是Deque实现，不能用；别看到“队列”就以为能调getLast() - 如果原有代码用的是
List，强转成Deque会编译失败 —— 得重构上游类型或做适配
遇到 UnsupportedOperationException 时，大概率是不可变 List
像 Collections.unmodifiableList()、Arrays.asList() 返回的列表，或者 Guava 的 ImmutableList，它们的 get() 没问题，但如果你误用了 removeLast() 或试图往 Deque 里写，就会触发这个异常。
-
Arrays.asList(...).get(0)没问题，但(Deque) Arrays.asList(...).getLast()编译不过，运行时更不会成功 - 不可变集合通常没有
Deque接口，强行转型会报ClassCastException - 如果不确定来源，优先走安全路径：判空 +
get(size()-1)，而不是假设它支持Deque
要不要为“取最后一个”专门引入新依赖？一般不用
Apache Commons Collections 有 CollectionUtils.get(collection, -1)，Guava 也有类似工具方法，但它们只是语法糖，底层还是判空+索引计算。
立即学习“Java免费学习笔记（深入）”；
- 加一个依赖只为一行逻辑，增加维护成本，不值得
- 如果项目已用 Guava，
Iterables.getLast(iterable)可以处理Iterable，比手写更稳；但对List还是不如原生get()直观 - 真正该警惕的是：为什么频繁需要最后一个元素？是不是数据建模时把“最新项”当成了隐式状态？这种隐含逻辑比取值本身更难调试
边界情况永远比想象中多——比如 size() 返回 long 的自定义 List 实现（极少见但存在），或者并发修改导致 size 和实际元素数不一致。别只盯着“怎么取”，先想清楚“为什么必须取最后一个”。
