Files类本身不直接使用PECS泛型，但基于它构建的高层批处理工具需遵循PECS：读取场景用List<? extends T>安全消费数据，写入场景用Collection<? super T>安全生产数据。
java.nio.file.Files 类本身没有直接暴露使用 ? extends T 或 ? super T 的泛型方法，它整体设计偏向于面向字节、路径和字符串的底层 I/O 操作，方法签名大多采用具体类型（如 Path、byte[]、List<String>）或原始类型，不依赖 PECS 原则。
但这不意味着 PECS 与文件批处理无关。关键在于：当你基于 Files 构建更高层的泛型工具时，PECS 才真正发挥作用——尤其是封装“读取多文件内容 → 聚合成统一结构”或“将统一数据写入多种目标格式”这类逻辑时。
下面分两类典型场景说明 PECS 如何自然融入基于 Files 的批处理设计：
读取多个文件 → 统一解析为某种业务对象（Producer 场景）
比如你有一组日志文件（*.log），想批量读取并解析成 LogEntry 对象：
立即学习“Java免费学习笔记（深入）”；
// 假设 LogEntry 是基类，不同格式日志有子类：JsonLogEntry、PlainTextLogEntry
public class LogEntry { /* ... */ }
public class JsonLogEntry extends LogEntry { /* ... */ }
public class PlainTextLogEntry extends LogEntry { /* ... */ }你写一个通用解析器，能接收任意子类列表（如 List<JsonLogEntry> 或 List<PlainTextLogEntry>），只读取、不修改：
✅ 正确用法（Producer）：
- 方法参数声明为
List<? extends LogEntry> - 可安全遍历、调用
entry.getTimestamp()等LogEntry定义的方法 - 不能往里 add 新元素（编译拒绝），避免混入不兼容类型
例如：
public static void printEntries(List<? extends LogEntry> entries) {
for (LogEntry e : entries) {
System.out.println(e); // 安全：e 至少是 LogEntry
}
// entries.add(new JsonLogEntry()); // ❌ 编译错误
}配合 Files 使用时，你可能先用 Files.readAllLines(path) 读出字符串，再交给解析器；而解析器的输入集合就适用 ? extends LogEntry。
批量写入多种目标格式（Consumer 场景）
假设你要把一批 Metric 数据导出到不同存储：纯文本文件、JSON 文件、甚至内存缓存（List<Metric> 或 ConcurrentLinkedQueue<Metric>）。
✅ 正确用法（Consumer）：
- 写入方法参数用
Collection<? super Metric> - 可安全调用
dest.add(metric)，因为所有合法目标都承诺能容纳Metric - 但读取时只能得到
Object，不强求具体类型（你本来也不打算从这里读）
例如：
public static void exportMetrics(List<Metric> metrics, Collection<? super Metric> dest) {
for (Metric m : metrics) {
dest.add(m); // ✅ 安全：dest 至少能装下 Metric
}
}
<p>// 调用自由：
List<Metric> fileBuffer = new ArrayList<>();
exportMetrics(data, fileBuffer); // List<Metric> → ? super Metric</p><p>List<Object> rawStore = new ArrayList<>();
exportMetrics(data, rawStore); // List<Object> → ? super Metric（Object 是 Metric 的父类）</p><p>// 甚至可以传入 Queue<Serializable>（如果 Metric 实现了 Serializable）
此时 Files.write(...) 可能负责最终落盘（如把 fileBuffer 写成 JSON 字符串），而 PECS 保证了中间聚合过程的类型安全与灵活性。
标准库中的影子：`Files.lines()` 和流式处理
Files.lines(Path) 返回 Stream<String> —— 虽然没显式写通配符，但它本质是 Producer：只产出 String，不接收输入。若你后续用 map 转成业务对象并收集，收集目标常是 List<? extends DomainObj>，逻辑一致。
另外，像 Collections.copy(dest, src) 这种成对使用 ? super T 和 ? extends T 的模式，在自定义文件处理器中也很常见：比如从多个 `Path` 并行读取 → 合并到一个 `List super Record>` 中。
不复杂但容易忽略
