直接用 uniqid() 不够安全，因其仅基于微秒时间戳且无随机熵，高并发时易重复；必须结合 mt_rand()、文件名、time() 等增强唯一性，并校验扩展名与 MIME 类型。
为什么直接用 uniqid() 不够安全
单独调用 uniqid() 生成的字符串只基于当前微秒时间戳，同一毫秒内多次调用可能重复；而且它不带随机熵，默认是可预测的。在高并发上传或测试环境反复刷新时，容易撞名——尤其是当多个用户几乎同时上传同名文件（如 avatar.jpg）时，后传的会覆盖前传的。
实操建议：
- 永远不要只用
uniqid()，必须加随机因子，比如uniqid('', true)（第二个参数开启熵） - 若需更强唯一性，把原始文件名、时间、随机数一起参与哈希，而不是仅哈希时间戳
- 避免用
microtime(true)直接拼接，浮点数转字符串可能截断精度
推荐组合：md5(uniqid(mt_rand(), true) . $_FILES['file']['name'] . time())
这个表达式兼顾不可预测性、输入差异性和低冲突概率。其中 mt_rand() 提供高质量随机数，$_FILES['file']['name'] 引入客户端原始文件信息（哪怕只是扩展名），time() 补充时间维度。
常见错误现象：
立即学习“PHP免费学习笔记（深入）”；
- 只哈希
$_FILES['file']['name']→ 所有同名文件（如全是a.png）会得到同一个 hash，完全失去唯一性 - 漏掉
mt_rand()或用rand()→ 在某些 PHP 版本下熵不足，批量生成时可能连续重复 - 用
file_get_contents($_FILES['file']['tmp_name'])做哈希 → 大文件会吃内存，且没必要
实际保存时还要处理扩展名与路径安全
哈希值本身不含扩展名，但用户需要能正常下载并被浏览器识别类型。不能直接信任 $_FILES['file']['name'] 的后缀，得用 finfo_file() 或 pathinfo($_FILES['file']['name'], PATHINFO_EXTENSION) 配合 MIME 白名单校验。
实操建议：
- 用
pathinfo()提取上传名的扩展名，再小写标准化：strtolower(pathinfo($_FILES['file']['name'], PATHINFO_EXTENSION)) - 手动映射 MIME 类型到允许扩展名（如
image/jpeg → 'jpg'），拒绝.php、.htaccess等危险后缀 - 最终文件名格式建议为：
<code>md5(...). '.' . $safe_ext，例如7f8c4e2a9b1d5f6c3e8a0b2c1d4e6f8a.jpg - 存储路径别暴露在 URL 中，用独立上传目录（如
/var/www/uploads/），并在 Web 根目录外或加.htaccess禁执行
并发量大时，要不要加数据库唯一索引兜底？
理论上 MD5 + 随机盐碰撞概率极低（远低于硬件故障率），但如果你的业务要求「绝对不可覆盖」，比如医疗影像或法律存证，那就在数据库里对文件哈希字段加 UNIQUE 索引，并在 INSERT 失败时重试生成新名。
注意点：
- 重试次数建议限制为 3–5 次，避免死循环
- 不要用
SELECT ... WHERE filename = ?判断是否存在——这中间仍有竞态窗口；必须依赖数据库唯一约束报错（SQLSTATE[23000]: Integrity constraint violation） - 如果用了对象存储（如 OSS/S3），MD5 可直接作为 key，其服务端已保证 key 全局唯一，无需额外查库
