Files.createTempFile默认在当前工作目录而非系统临时目录创建文件，因JDK规范未强制使用java.io.tmpdir；需显式传入Paths.get(System.getProperty("java.io.tmpdir"))作为dir参数，并确保目录存在可写。
Files.createTempFile 为什么默认不放在系统临时目录
Files.createTempFile 默认行为是：在当前工作目录（user.dir）下创建临时文件，不是系统临时目录（如 /tmp 或 C:\Users\...\AppData\Local\Temp）。这是很多人误以为“它该自动用系统临时目录”的根源。
根本原因在于 JDK 规范未强制要求其使用 java.io.tmpdir —— 它只保证“临时性”，不绑定位置。要落到系统临时目录，必须显式指定父目录。
- 正确做法：先用
System.getProperty("java.io.tmpdir")获取路径，再转为Path - 别直接拼字符串（比如
"/tmp/" + prefix），会跨平台失效 - 注意返回值是
Path，不是File；后续操作应继续用 NIO.2 API，避免混用File导致路径解析歧义
如何安全调用 createTempFile 指向系统临时目录
核心就是把系统临时目录作为第一个参数传入 Files.createTempFile 的 dir 参数：
Path tmpDir = Paths.get(System.getProperty("java.io.tmpdir"));
Path tempFile = Files.createTempFile(tmpDir, "myapp-", ".log");
关键点：
-
dir参数必须是已存在的、可写的目录，否则抛IOException（常见错误：没检查tmpDir.toFile().exists()） - 前缀（
"myapp-"）建议带短横线，避免和随机后缀连成一串难读名（如myapp123456789vsmyapp-123456789） - 后缀（
".log"）可为空字符串，但不推荐；空后缀会导致文件无扩展名，某些工具识别异常
为什么有时还是出现重名或 PermissionDenied
看似“不重名”只是概率高，并非绝对唯一；而权限问题多源于目录本身限制：
-
createTempFile内部用SecureRandom生成后缀，碰撞概率极低，但若在极短时间内高频调用（如压测循环），仍可能因熵不足或时钟精度触发重复尝试逻辑 - Windows 下常见
AccessDeniedException：杀毒软件或 OneDrive 正在监控%LOCALAPPDATA%\Temp，拦截了文件创建 - Linux/macOS 下如果
java.io.tmpdir被设为只读挂载点（如容器中/tmp是 tmpfs 但权限为555），也会失败 - 解决思路：捕获
IOException，加简单重试（最多 3 次），每次 sleep 几毫秒，比硬扛更稳妥
替代方案：用 Files.createTempDirectory 配合自定义命名
当需要一组相关临时文件（如解压包、中间产物），比单个文件更可控：
Path tmpDir = Files.createTempDirectory("myapp-work-");
Path dataFile = tmpDir.resolve("input.json");
Files.write(dataFile, "{'ok':true}".getBytes());
优势：
- 目录名由 JVM 保证唯一，内部文件可自由命名，逻辑更清晰
- 便于集中清理：
Files.walk(tmpDir).sorted(Comparator.reverseOrder()).forEach(Files::delete) - 规避单个文件频繁创建/删除带来的 inode 碎片或锁竞争（尤其在 NFS 或某些容器文件系统上）
注意 createTempDirectory 同样需要显式传入父目录，否则也落在当前工作路径。
真正容易被忽略的是：系统临时目录的生命周期不由 JVM 管理，哪怕 JVM 退出，文件也不会自动清理；业务代码必须自己负责删除，或注册 deleteOnExit()（仅对 File 有效，Path 需手动处理）。
