Java 7 的 FileSystem 抽象使 ZIP 文件可挂载为虚拟文件系统，通过 ZipFileSystemProvider 自动创建 ZipFileSystem 实例，支持只读/写入（重建ZIP）、遍历、随机读取条目，并允许路径动态拼接实现插件化资源管理。
Java 7 引入的 FileSystem 抽象，让 ZIP 文件不再只是“要解压才能读”的二进制流，而是可以直接挂载为一个虚拟文件系统——就像访问 /home/user/docs 那样访问 archive.zip!/config/app.properties。核心在于 ZipFileSystem 的实现与 FileSystems.newFileSystem() 的协同机制。
ZipFileSystem 是如何被创建出来的
它不是手动 new 出来的类，而是由 Java 内置的 FileSystemProvider（具体是 ZipFileSystemProvider）根据 URI 协议和路径后缀自动触发加载：
- 传入一个
Path指向 .zip 或 .jar 文件，并指定URIscheme 为jar:file:或file:+!/分隔符 - 调用
FileSystems.newFileSystem(uri, env)，JVM 查找匹配的 provider（zipfs）并委托其创建实例 - 该实例内部维护 ZIP 中央目录结构缓存、入口索引、字节流复用逻辑，支持随机读取任意条目而不解压整个包
像操作普通目录一样遍历和读写 ZIP 内容
一旦获得 FileSystem 实例，所有 java.nio.file.* API 都可直接使用：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
fs.getPath("/script.js")返回一个Path，实际指向 ZIP 内的 entry，而非磁盘路径 -
Files.exists(path)、Files.isRegularFile(path)、Files.isDirectory(path)均能正确判断 ZIP 条目类型 -
Files.walk(path)可递归列出 ZIP 内所有嵌套路径；Files.list(path)列出同级条目（类似ls） -
Files.readAllBytes(path)或Files.newInputStream(path)直接读取 entry 数据，无需先解压到临时文件
写入 ZIP 需要注意的限制和技巧
ZipFileSystem 默认只支持只读；若需写入（如添加、删除或更新条目），必须显式启用：
立即学习“Java免费学习笔记（深入）”；
- 创建时传入环境参数：
Map<String, Object> env = Map.of("create", "true") - 但注意：ZIP 格式不支持原地修改，所以“写入”本质是重建 ZIP 流——每次
close()时会将全部变更序列化回目标文件 - 新增条目需确保父目录存在（
Files.createDirectories()），否则抛IOException - 不能删除非空目录（ZIP 规范中目录只是路径前缀，无真实 inode），只能删空后逐级删路径
变量注入？其实是路径拼接 + 动态挂载
所谓“处理压缩包变量”，并非 ZIP 本身支持变量替换，而是指在代码中把 ZIP 路径、内部 entry 名、甚至挂载点作为运行时参数灵活组合：
- 例如：
String zipPath = config.get("plugin.archive"); Path zipFile = Paths.get(zipPath); FileSystem fs = FileSystems.newFileSystem(zipFile, Map.of()); - 再比如用
String template = "/templates/%s.html"; Path p = fs.getPath(String.format(template, locale)); - 这种模式天然适配插件系统、多语言资源包、模块化配置等场景，逻辑清晰且不依赖外部解压工具
