ThinkPHP上传同名文件会直接覆盖，因其move()方法底层调用PHP原生move_uploaded_file()，不校验冲突；应结合ymd日期、雪花ID（截取后12位）与文件扩展名生成唯一文件名，并配合subType=>'date'自动分目录存储。
ThinkPHP 上传同名文件为什么会直接覆盖
默认情况下，think\File 的 move() 方法如果目标路径已存在同名文件，会直接覆盖——它底层调用的是 PHP 原生的 move_uploaded_file()，而这个函数本身不检查冲突，也不重命名。
常见错误现象：file_put_contents() 或手动 rename() 后发现旧文件没了；调试时看到上传成功但历史文件“消失”了。
- 不是 ThinkPHP 故意设计成这样，是它把控制权交给了开发者
- 框架的
validate(['size', 'ext'])等校验不涉及文件名冲突逻辑 -
move()的第二个参数若传入固定字符串（如'uploads/avatar.jpg'），就必然覆盖
用雪花算法 ID + 时间戳自定义文件名
核心思路：在保存前生成唯一、有序、可读性尚可的文件名，避免依赖客户端原始名。雪花 ID 适合分布式场景，但注意 ThinkPHP 默认没内置，得自己封装或引入轻量库。
推荐组合方式：date('ymd') . '_' . snowflake_id() . '.' . $file->extension()，既保留日期便于归档，又靠 ID 保证唯一。
立即学习“PHP免费学习笔记（深入）”；
- 别直接用
snowflake_id()当文件名——太长（19 位数字），Windows 对路径长度敏感，建议截取后 12 位或转为短 Base62 - 时间戳部分用
ymd而非YmdHis，避免单目录下文件过多影响性能（尤其 Linux ext4 对单目录 > 10k 文件有明显减速） -
$file->extension()必须调用，不能硬编码后缀，否则用户上传.php可能绕过扩展名校验
$newName = date('ymd') . '_' . substr(snowflake_id(), -12) . '.' . $file->extension();
$file->move(ROOT_PATH . 'public' . DS . 'uploads', $newName);
ThinkPHP 6.x 中 upload() 配置项如何配合防覆盖
光改名字还不够，上传流程中几个关键配置点会影响最终行为，尤其和 move() 的路径构造有关。
-
rootPath决定基础目录，务必以DS结尾，否则拼接时可能出错（如ROOT_PATH.'public/uploads'缺少斜杠会导致路径错位） -
saveName回调函数里可以介入重命名，但注意：它只影响保存时的文件名，不改变move()的目标路径逻辑，仍需手动拼全路径 -
subType设为date会自动按天建子目录（如uploads/2024/05/20/），这是比纯 ID 更实用的隔离手段，和自定义命名可叠加使用 - 别设
replace为 true——这是个误导性配置，它控制的是临时文件是否覆盖，不是最终保存文件
为什么不用 UUID 而选雪花 ID + 时间戳组合
UUID 看似简单，但在上传场景下有几个实际坑：
- UUID v4 完全随机，大量文件写入时容易引发磁盘随机 IO，尤其机械硬盘或低配云盘，上传并发稍高就卡住
- UUID 字符串含横线（如
550e8400-e29b-41d4-a716-446655440000），某些老旧 CDN 或 Nginx 配置会因正则误判为恶意路径 - 雪花 ID 天然有序 + 时间前缀，配合
ymd目录结构，日志排查、备份清理、数据库关联都更直观 - 如果项目已用 Snowflake 做订单号/用户 ID，复用同一套生成逻辑，能减少维护成本和时钟漂移风险
真正容易被忽略的是：雪花 ID 生成器必须初始化一次全局实例，不能每次上传都 new 一个——否则不同实例的机器 ID 或序列号可能冲突，导致 ID 重复。
