File.canRead()和canWrite()仅检查用户身份权限，不保证实际I/O成功；应通过Files.write→read→delete闭环实测，并结合dmesg、findmnt等系统工具定位挂载、SELinux、文件锁等runtime问题。
升级 OpenJDK 后，File.canRead() 和 File.canWrite() 仍返回 true，不代表文件读写一定成功——这是最常见的误判点。验证重点不是“权限检查函数是否通过”，而是用真实 I/O 操作触发底层系统调用，暴露挂载状态、SELinux 策略、文件锁、只读文件系统等 runtime 层面的问题。
用最小原子操作实测读写能力
别依赖 canRead()/canWrite() 的布尔返回值。它们只查 ACL 位或用户身份，不触及实际设备或挂载选项。
- 写测试：用
Files.write()写入一个带时间戳的临时文件，再立即Files.readAllBytes()读回比对，最后Files.delete()清理 - 读测试：找一个已知存在且非空的配置文件（如
$JAVA_HOME/conf/logging.properties），用Files.readString()读取并检查长度 > 0 - 必须在同一个 JVM 进程里完成写→读→删闭环，避免因进程重启导致的权限上下文变化
注意 JDK 版本对文件系统 API 的行为变更
JDK 11+ 对 Files 工具类做了静默增强，但某些旧代码路径会暴露兼容性问题：
-
Files.write(path, data, StandardOpenOption.CREATE, StandardOpenOption.TRUNCATE_EXISTING)在 JDK 8 下可能忽略TRUNCATE_EXISTING，而 JDK 17+ 严格遵循；若你依赖截断逻辑，需显式加StandardOpenOption.WRITE -
Files.isWritable()在 JDK 17 中对 NFS 挂载点返回更保守结果，而 JDK 8 可能误报true；实测时优先用Files.write(...)而非该方法 - 如果代码中用了
new FileOutputStream(file, true)追加写，确认目标文件父目录有写权限——JDK 升级不会改语义，但新版本 JVM 更早暴露java.io.IOException: Permission denied（而非等到 close()）
绕过 JVM 缓存，直击内核层失败信号
有些错误只在真实 syscall 层抛出，比如只读挂载、noexec 选项、容器中 tmpfs 权限限制。Java 层异常信息往往模糊，需结合系统日志定位：
- 运行测试脚本时，同步执行
dmesg -T | tail -n 20，查看是否有VFS: Mounted filesystem read-only或SELinux is preventing类提示 - 在容器环境（Docker/Podman）中，
ls -ld /path/to/dir显示权限为drwxr-xr-x不代表可写——检查挂载参数：findmnt -T /path/to/dir | grep -o 'ro\|rw' - 若测试中出现
java.nio.file.FileSystemException: ... Device or resource busy，不是 JDK 问题，是文件被其他进程（如 logrotate、IDE 文件监听器）独占锁定
最易被忽略的是：JDK 升级后，java.io.tmpdir 默认值可能随 java.home 变化而指向新路径，而该路径所在分区可能空间不足或挂载为 noatime,nobarrier，导致 Files.write() 报 No space left on device 却不提示具体磁盘。务必在测试前先 df -h $(java -XshowSettings:properties -version 2>&1 | grep 'java.io.tmpdir' | awk '{print $3}')。
