super关键字在迭代器助手中调用父类方法无语法限制，真正受限的是泛型通配符? super T与Iterator只读语义冲突导致的编译错误。
子类 extends 父类后，在迭代器助手（如自定义 Iterator 实现、Stream 操作辅助类或泛型工具方法）中调用 super 本身没有语法限制，真正受限的不是 super 调用，而是**类型边界 + 泛型通配符 + 迭代器只读/写入语义冲突**导致的编译错误。常见表现是：想在 Iterator<? super T> 或 List<? super T> 上调用父类方法却报错，或无法安全遍历/添加元素。
明确 super 在迭代器上下文中的两种角色
先区分清楚：
– super 作为关键字：用于子类中调用父类构造器或方法，和泛型无关，只要语法位置正确（如构造器首行、非静态方法内），就可正常使用；
– ? super T 中的 super：是泛型通配符下界，和继承链无关，只约束集合能接受什么类型的数据。
所谓“调用 super 的边界限制”，实际是混淆了这两个概念。迭代器助手出问题，90% 是因为误用了泛型通配符，而非 super() 本身不可调用。
迭代器助手里泛型通配符的典型误用
比如你写了一个泛型工具类，希望它既能处理 Integer，也能处理其父类 Number 或 Object：
- 错误写法：
public static void addNumbers(Iterator<? super Integer> iter)—— 这个签名毫无意义，Iterator是只读接口，不能往里add；? super Integer对Iterator来说既不能安全读（返回Object），也不能写（Iterator没有add方法） - 正确方向：如果目标是“向容器写入
Integer”，应使用Collection<? super Integer>配合add()；如果目标是“从容器读取并处理”，应使用Iterator<? extends Number>或直接Iterator<Number> - 常见陷阱：把
List<? super T>当作“可以存 T 及其子类”的容器——其实它只能安全存T，但读出来只能当Object；而Iterator<? super T>几乎无实用价值，JDK 自身也未提供此类用法
子类中安全复用父类迭代逻辑的推荐方式
如果你的迭代器助手是子类实现（比如继承 AbstractList 或重写 iterator()），要复用父类行为，关键是：
- 在子类
iterator()方法中，直接return super.iterator();—— 这完全合法，不涉及泛型边界 - 若需增强迭代逻辑（如跳过 null、过滤偶数），可包装父类迭代器：
return new FilteringIterator(super.iterator())，并在包装类中调用super.hasNext()/super.next() - 避免在泛型方法参数里强行塞
? super T到Iterator：改用具体上界，如<E extends Number> double sum(Iterator<E> iter)，这样既能读取E类型，又可复用父类方法
调试时快速定位是否真为 super 限制
遇到编译错误，先做三件事：
- 删掉所有泛型通配符（如
? extends、? super），换成具体类型（如Iterator<Number>），看是否还报错——如果不报了，说明问题出在通配符，不是super关键字 - 检查错误信息是否含 “capture#xxx of ? super T” 或 “cannot resolve symbol super” —— 前者是通配符捕获失败，后者才是语法错误（通常因
super()没放构造器第一行） - 确认你调用的是
super.method()还是试图对Iterator<? super T>调用next()并强转——后者失败是因为返回类型是Object，和super无关
