可行但需规避陷阱：禁用split(",")，须用OpenCSV等安全解析；过滤须无状态；必须try-with-resources关闭流；禁用collect(toList)防OOM；并行需谨慎。
直接用 Files.lines() 流式读取超大 CSV 文件是可行的，但需规避常见陷阱：不能直接用 split(",") 解析（引号内逗号、换行、转义会出错），也不能把整行或整文件加载进内存做聚合。核心思路是——**逐行流式解析 + 状态无关的轻量过滤 + 及时终止或分批处理**。
用 OpenCSV 或 Apache Commons CSV 做安全解析，别手写 split
Files.lines() 返回的是原始字符串流，CSV 格式远比逗号分隔复杂。手动 line.split(",") 在遇到 "Smith, John",25,"New York" 时会错误切分为 4 段。
- 推荐用 OpenCSV 的
CsvToBeanBuilder或CSVReader，它支持 RFC 4180，自动处理引号、换行、转义 - 若坚持纯 JDK，至少用
BufferedReader+ 自定义简易解析器（仅适用于无引号/无换行的“准 CSV”） - 关键：解析必须在
map()中完成，且返回轻量对象（如record或自定义SimpleCsvRow），避免创建冗余集合
过滤逻辑必须无状态、不依赖全局变量
Stream 是惰性求值的，但所有中间操作（filter, map）必须是无副作用、线程安全的函数式操作。例如：
- ✅ 正确：
filter(row -> "active".equals(row.get("status")) && row.getInt("age") > 18) - ❌ 错误：
filter(row -> counter++ （有状态）、<code>filter(row -> cache.put(row.getId(), row))（副作用） - 若需去重或 Top-K，改用
distinct()或limit(n)；需要排序后取前 N，用sorted(...).limit(n)（注意 sorted 会触发部分缓冲，但比全加载好）
控制内存的关键：及时关闭资源 + 使用 try-with-resources + 避免 collect(Collectors.toList())
Files.lines() 返回的 Stream 底层持有 FileChannel 或 BufferedReader，不显式关闭会导致文件句柄泄漏，尤其在循环或服务中。
- 必须用 try-with-resources 包裹：
try (Stream<string> lines = Files.lines(path, StandardCharsets.UTF_8)) { ... }</string> - 绝对避免
lines.collect(Collectors.toList())—— 这会让整个文件进堆内存。改用forEach输出、count()统计、或findAny()/findFirst()提前终止 - 若需写结果到新文件，用
forEach配合BufferedWriter，每行处理完立即 flush，不缓存
进阶：按块处理 + 并行需谨慎
对上百 GB 文件，并行 Stream（lines.parallel()）不一定更快，因为 I/O 是瓶颈，且 CSV 行边界无法随机跳转。
- 更稳妥做法：用
Files.lines().skip(n).limit(m)分页（适合已知行数的场景） - 真正高效的大文件处理常结合外部工具（如
awk,csvsql）或列式存储（Parquet + Spark），Java Stream 更适合 GB 级、规则清晰的过滤任务 - 若必须并行，先用
BufferedReader::lines替代Files.lines()，再包装为可分割的Spliterator（较复杂，一般不推荐）
本质上，Files.lines() + Stream 不是万能方案，而是“够用、简洁、可控”的选择。重点不在炫技，而在守住内存底线、保证 CSV 正确性、让流真正懒执行。
