tempnam()是php中唯一安全生成临时文件路径的函数，仅返回不存在且权限受限的路径，需配合fopen()等函数创建文件，首参数须为真实可写目录，第二参数为前缀，不可拼接字符串构造路径。
用 tempnam() 创建安全的临时文件
PHP 没有“自动管理生命周期”的临时文件概念，所有临时文件都得手动创建、写入、读取、删除。tempnam() 是唯一被设计用来安全生成临时文件路径的函数，它会确保返回的路径不存在（避免竞态条件），且权限受限（默认 0600）。
关键点：
-
tempnam()只生成路径，不创建文件实体；需配合fopen()或file_put_contents()才真正落盘 - 第一个参数必须是**真实存在的、可写的目录路径**，不能是相对路径如
"./tmp"（否则可能失败或回退到系统默认 tmp 目录） - 第二个参数是前缀，不是完整文件名；实际生成类似
/tmp/phpA1B2c3，末尾是随机字符串 - 不要拼接字符串构造临时路径（如
"/tmp/myapp_".uniqid().".log"），这存在符号链接攻击和覆盖风险
示例：
if ($tmpPath = tempnam('/var/tmp', 'myapp_')) {
file_put_contents($tmpPath, "data\n");
// 后续处理...
}
临时文件常见误用场景与风险
很多开发者把临时文件当“缓存”或“中转站”用，但没意识到 PHP 进程退出后文件不会自动消失——尤其在 CLI 脚本、长连接 Swoole/Workerman、或 Apache 的 mpm_prefork 模式下，临时文件可能堆积数天甚至数月。
立即学习“PHP免费学习笔记（深入）”；
典型误用：
- 在循环里反复调用
tempnam()+file_put_contents()，但忘记unlink() - 用
sys_get_temp_dir()获取路径后自行拼接文件名，绕过tempnam()的安全性校验 - 将临时文件路径传给外部命令（如
exec("convert $tmpPath output.jpg")），若未验证$tmpPath是否由tempnam()生成，可能被注入恶意路径 - 在 Web 请求中生成大临时文件（如上传文件中转），但未限制大小或超时，导致磁盘占满
临时文件清理策略：什么时候删？怎么删？
没有银弹。清理时机取决于使用场景：
-
Web 请求内完成的临时文件：务必在响应发送前
unlink()，推荐用register_shutdown_function()包裹，防止异常中断导致遗漏 -
CLI 脚本中的临时文件：用
pcntl_signal(SIGINT, fn() => unlink($tmpPath))捕获 Ctrl+C；同时脚本末尾加unlink($tmpPath)作为兜底 -
需要跨请求暂存的场景：别用临时文件，改用 Redis、SQLite 或带 TTL 的数据库表；
sys_get_temp_dir()下的文件不属于“临时”语义范畴 -
批量生成多个临时文件：用
tmpfile()替代 —— 它返回资源句柄，进程结束自动释放，无需手动unlink()，但无法获取文件路径（不能传给外部命令）
注意：tmpfile() 创建的是匿名临时文件，适合纯内存中转，不适合需要路径的场景（如图像处理库要求传入 .png 路径）。
Linux 系统级 tmp 目录清理机制不可依赖
很多人以为 /tmp 下的文件会被系统自动清理，实际上：
- systemd 系统依赖
systemd-tmpfiles配置，但默认只清理/tmp下 10 天未访问的文件（Linger时间可配置），/var/tmp更久（30 天） - 非 systemd 系统（如旧版 CentOS）可能完全不清理，或依赖 cron 脚本，而该脚本可能被禁用
-
tempnam()默认用sys_get_temp_dir()，其返回值受upload_tmp_dir、sys_temp_dir、环境变量TMPDIR影响，不一定落在/tmp
所以，任何业务逻辑产生的临时文件，清理责任必须落在 PHP 代码自身，不能指望系统。
