path.gettempfilename() 会真实创建0字节文件，易致磁盘堆积，仅适用于立即写入场景；推荐用 guid.newguid() 或 path.getrandomfilename() 手动构造唯一路径并显式清理。
用 Path.GetTempFileName() 最简单但有坑
它确实能立刻返回一个带完整路径的、当前系统里不存在的临时文件名，内部会自动在 Path.GetTempPath() 下创建空文件并加锁，保证调用返回时文件尚未被其他进程占用。
但问题很实际：Path.GetTempFileName() 会在磁盘上真实创建一个 0 字节文件——哪怕你只是想“先占个名字”。如果后续逻辑失败没删掉，或者程序崩溃，这些残留文件就堆积在临时目录里。Windows 的临时目录清理机制并不及时，长期运行的服务容易因此填满磁盘。
实操建议：
- 仅在「马上就要写入内容」且「写入过程可控」的场景下直接用，比如导出一份报表后立即写入再上传
- 不要把它当纯命名工具；若只需名字不需文件，别用它
- 调用后务必配对
File.Delete()（放在finally或using中），否则等于埋雷
手动拼接唯一名：用 Guid.NewGuid() + Path.GetTempPath()
这是更灵活也更安全的做法——绕过自动建文件，自己构造一个极大概率不冲突的路径。
示例：Path.Combine(Path.GetTempPath(), $"{Guid.NewGuid():N}.tmp")。注意 :N 是为了去掉 Guid 中的短横线，避免某些旧系统或工具对路径中连字符敏感。
为什么可靠？Guid.NewGuid() 在 .NET 中基于 RNGCryptoServiceProvider（.NET Core/5+）或改进的随机种子（.NET Framework），碰撞概率低到可忽略（远低于 2^(-122)）。只要不刻意重用同一个 Guid 实例，单机并发生成几千个也不用担心重复。
实操建议：
- 如果需要特定扩展名（如
.xlsx），直接拼在 Guid 后面，别用Path.ChangeExtension()——它可能把 Guid 里的点当成扩展分隔符 - 避免用
DateTime.Now.Ticks单独做后缀：高并发下容易重复，尤其容器环境或虚拟机里时钟精度可能不足 - 不需要提前
File.Exists()检查——Guid 已足够唯一，加检查反而引入竞态窗口
需要目录级隔离？用 Path.Combine(Path.GetTempPath(), Path.GetRandomFileName())
Path.GetRandomFileName() 返回的是 11 字符的随机字符串（含大小写字母和数字），不带路径、不创建文件，专为构造临时路径设计。它比 Guid 短，适合嵌入子目录名。
典型用法：var tempDir = Path.Combine(Path.GetTempPath(), Path.GetRandomFileName()); Directory.CreateDirectory(tempDir);。这样每个任务独占一个临时子目录，天然隔离文件名、权限、清理边界。
注意点：
-
Path.GetRandomFileName()和Path.GetTempFileName()底层共享同一随机源，但前者绝不碰磁盘，更轻量 - 它生成的字符串不含点号或斜杠，适合作为目录名；但作为文件名时建议自己补扩展名，别依赖它输出带后缀的字符串
- 虽然概率极低，但理论上存在哈希碰撞——不过比起 Guid，它更快、更省内存，日常批处理完全够用
清理不是可选项：必须显式处理生命周期
无论用哪种方式生成路径，.NET 不会自动帮你删临时文件或目录。Windows 的“临时文件清理”只扫特定标记或超期文件，不会识别你代码里造出来的任意路径。
最容易被忽略的点是：异步操作、异常分支、AppDomain 卸载、甚至 Ctrl+C 中断，都可能导致清理逻辑跳过。别指望 Finalize 或静态析构器——它们不保证执行时机，甚至可能根本不执行。
实操底线：
- 文件级临时资源：用
using (var fs = File.Create(...)) { ... }，或确保try/finally中调用File.Delete() - 目录级临时资源：用
try/finally配Directory.Delete(tempDir, true)，别等 GC - 若临时数据要跨方法传递，考虑封装成
IDisposable类型，把路径和清理逻辑捆在一起
真正麻烦的永远不是“怎么生成唯一名”，而是“谁在什么时候删它、删不掉怎么办”。路径生成只是起点，生命周期管理才是关键。
