自定义容器应构造时接收Comparator参数，为null时安全检查元素是否实现Comparable并调用compareTo；排序统一走私有compare(T a,T b)方法；类型推断优先显式传入Class；动态插入用二分查找+arraycopy优于全量排序；toArray需按规范处理数组长度与类型。
Java 里怎么让自定义容器支持 Comparable 和 Comparator 两种排序？
必须在容器内部预留排序策略的接入点，不能硬编码比较逻辑。否则泛型类型一换，compareTo() 就可能抛 ClassCastException。
实操建议：
- 容器构造时接受
Comparator<t></t>参数，为null时才尝试调用元素自身的compareTo() - 判断是否可比较，别用
instanceof Comparable—— 因为泛型擦除后是Comparable>，实际检查应为t instanceof Comparable && t.getClass() != Object.class - 排序入口统一走一个私有方法
compare(T a, T b)，内部按上述规则分发，避免多处重复逻辑
泛型擦除后，怎么在运行时获取真实元素类型并做安全转换？
不能靠 getClass().getGenericSuperclass() 硬猜，尤其当你的容器被继承或嵌套使用时，返回的可能是 Object 或父类声明类型。
实操建议：
- 如果容器用于构建过程（如 builder 模式），把类型信息通过
Class<t></t>显式传入，比如new SortedList<string>(String.class)</string> - 若必须推断，只在直接 new 的场景下用反射取构造器泛型参数，且加
try-catch防NullPointerException - 所有涉及强转的地方（如从
Object[]数组取元素）必须用(T) obj+@SuppressWarnings("unchecked")，但要确保上层逻辑已验证类型一致性，否则运行时崩得无声无息
插入排序 vs. 每次 Collections.sort()：哪个更适合动态容器？
频繁增删时，每次都全量重排会把时间复杂度拉到 O(n²)，而插入排序维持有序性只需 O(n) 单次操作，更可控。
实操建议：
- 用二分查找定位插入位置（
Arrays.binarySearch()），再用System.arraycopy()移动后续元素，比先 add 再 sort 快且内存友好 - 注意
binarySearch()返回负值时的计算公式：插入点 =-(index) - 1，写错会导致越界或漏位 - 如果允许重复元素，
binarySearch()不保证返回首个/末尾匹配项，要用Arrays.asList(arr).indexOf()辅助校验，或者改用TreeSet底层思路（但那就不是“从零实现”了）
为什么 toArray(T[]) 方法一定要检查数组长度并新建实例？
因为 JDK 规范强制要求：如果传入数组够大，就复用；不够大，必须返回新数组。不照做，和 ArrayList 交互时会触发 ArrayStoreException。
实操建议：
- 别直接
return (T[]) elements—— 这是裸数组，类型不匹配；也别new T[size]—— 泛型无法实例化 - 正确写法：
if (a.length size) a[size] = null; return a; } - 特别注意：当
a是new String[0]这种零长数组时，a.getClass()是String[].class，能正确推导泛型，这是唯一安全的类型来源
泛型容器最麻烦的从来不是排序逻辑本身，而是类型擦除后那些看似“应该能推出来”的地方——比如数组创建、异常捕获范围、甚至 toString() 里遍历元素时的隐式转型。这些地方不出错则已，一出就是运行时静默失败。
