单纯用System.currentTimeMillis()配合Random无法绝对保证唯一性，因毫秒级时间戳在快速调用或时钟回拨时易重复，需叠加随机数和进程/线程标识；推荐组合时间戳+6位随机数+PID，或直接使用Files.createTempFile、UUID等更可靠方案。
单纯用 System.currentTimeMillis() 配合 Random 无法**绝对保证唯一性**，但可以显著降低冲突概率，适用于大多数临时文件场景（如单机、非高并发批量创建）。关键在于合理组合时间戳与随机熵，并避免常见陷阱。
为什么不能只靠 currentTimeMillis()
毫秒级时间戳在快速连续调用时极易重复（比如循环中新建多个文件），尤其在 JVM 优化或系统时钟回拨时更不可靠。必须叠加额外的随机因子。
推荐组合方式：时间戳 + 随机数 + 进程/线程标识
以下是一个实用、简洁、线程安全的生成逻辑：
private static final Random RANDOM = new Random();
private static final long PID = ProcessHandle.current().pid(); // Java 9+
public static String generateTempFileName() {
long now = System.currentTimeMillis();
int rand = RANDOM.nextInt(1000000); // 6位随机数
return String.format("temp_%d_%d_%d", now, rand, PID);
}
- 时间戳（now）提供宏观顺序性
-
随机数（rand）解决同一毫秒内的碰撞，用
nextInt(1000000)避免前导零问题 -
PID隔离不同 JVM 实例（若跨进程运行）；若仅单个 JVM，可用
Thread.currentThread().getId()替代
更健壮的替代方案（推荐生产环境）
如果对唯一性要求更高（如分布式、高频写入），直接使用标准 API 更可靠：
-
Files.createTempFile("prefix", ".ext")：由 JVM 底层保障唯一性，自动处理目录、权限、重试 -
UUID.randomUUID().toString()：无序但全局几乎不重复，适合文件名不含时间语义的场景 - 组合：
System.currentTimeMillis() + "_" + UUID.randomUUID().toString().substring(0, 8)
注意事项
- 不要用
Math.random()—— 它不是线程安全的，且底层也用Random，不如直接复用静态Random实例 - 避免把随机数转成字符串后拼接空格或特殊符号（如
"temp " + rand），易引发路径解析错误 - 临时文件名只是第一步，务必配合
deleteOnExit()或try-with-resources + Files.delete()及时清理
