rename()在高并发下丢文件主因是缺乏原子性锁机制，导致竞态条件：多进程同时通过file_exists()判断目标不存在后执行rename，后执行者覆盖前执行者；跨文件系统时退化为复制+删除，中断即丢数据；Windows下还受未释放文件句柄影响。
rename() 为什么在高并发下会丢文件
不是 rename() 本身不安全，而是它不自带锁——两个请求同时判断 file_exists($target) 为 false，接着都执行 rename($temp, $target)，后一个必然覆盖前一个。Linux 下这属于竞态条件，Windows 还可能因文件句柄残留直接报 Access is denied。
实操建议：
- 永远不要只靠
file_exists()做存在性判断，尤其在写入路径前 - 用
fopen($lock_file, 'c')配合flock($fp, LOCK_EX)实现进程级互斥，锁文件路径必须固定且可写（比如和目标文件同目录的.rename.lock） - 锁内完成全部操作：校验 → 写临时文件 →
rename()→ 清理临时文件 - 别把锁文件放
/tmp或 NFS 共享目录，flock()在 NFS 上不可靠
跨文件系统 rename() 失败怎么救
rename() 在不同挂载点间移动时会退化成复制+删除，失去原子性。此时若中断，原文件已删、新文件没写完，数据就丢了。
判断是否跨文件系统：
立即学习“PHP免费学习笔记（深入）”；
- 用
realpath(dirname($temp))和realpath(dirname($target))比较是否相同 - 或调用
stat($path)['dev']对比设备号
跨系统时必须换方案：
- 改用
copy($temp, $target)+unlink($temp)，但得自己加锁防中间状态被读 - 写入前先
touch($target . '.writing')，完成后unlink($target . '.writing')，读取端跳过带.writing后缀的文件 - 更稳妥的做法是：成功后重命名
$target→$target . '.ok'，读取端只认.ok结尾的文件
Windows 下 rename() 报 Access is denied 的真实原因
不是权限问题，而是 Windows 文件句柄未释放。哪怕只是被 file_get_contents() 读过一次，PHP 内部缓存没清，或者杀毒软件正在扫描，都会让 rename() 失败。
排查和绕过方式：
- 检查有没有漏掉
fclose()—— 特别是用fopen()打开后没关的句柄 - 避免在
rename()前调用file_get_contents()、include()、getimagesize()等会隐式打开文件的函数 - 临时禁用 Windows Defender 实时防护测试是否干扰
- 实在不行，用
copy()+unlink()组合替代，但记得加锁并处理失败回滚
大文件替换时 md5_file() 拖慢响应怎么办
对 100MB 文件跑 md5_file() 可能卡住几秒，用户感知明显。哈希校验不是必须每次都做全量，关键看业务容忍度。
分层校验策略：
- 先比
filesize()+filemtime()，90% 场景能快速排除 - 如果大小和时间戳都一致，再用
hash_file('xxh128', $path)（PHP ≥ 7.4），比 MD5 快 3–5 倍 - 若文件极少变动，可缓存哈希值到 Redis，键为
hash:{$realpath}，TTL 设 1 小时 - 上传场景下，直接校验上传时传来的
$_FILES['x']['tmp_name']哈希，而非落地后再算
rename() 调用本身，而是你没意识到：锁文件路径是否可靠、临时目录是否可能满、跨系统时有没有 fallback、以及 Windows 下那个看不见的文件句柄。这些点漏掉任何一个，线上就会出 silent failure。 
