Webman不支持秒传，需自行实现哈希计算、映射存储与接口跳过逻辑；秒传依赖前端完整计算文件哈希、后端持久化哈希路径映射、上传接口依据Header查哈希并跳过写入。
秒传依赖的三个硬性前提
秒传不是“前端传个 hash 后端就返回成功”，它需要三件事同时成立：
- 前端必须在上传前完整计算整个文件的
md5（或sha256），不能只算前几 KB；大文件建议用 Web Workers 分块计算，避免卡死页面 - 后端必须持久化存储文件哈希与实际存储路径（OSS key / 本地路径 / MinIO object name）的映射关系，且该表要支持高并发读（Redis 最常用，MySQL 次之）
- 上传接口必须在接收到
X-File-MD5Header 后，先查哈希是否存在，存在则直接返回 success + 已存 URL，跳过所有写入流程
为什么 formFile() 无法支撑秒传
formFile() 只返回临时文件路径，你还没来得及算哈希，PHP 就可能在下次请求时清理掉那个 /tmp/phpXXXXXX 文件。更糟的是：
- 多 Worker 场景下，
getRealPath()指向本机临时目录，其他 Worker 根本访问不到 - 没做任何哈希缓存，每次都要重新读文件 → 大文件直接 OOM 或超时
- 没对接元数据存储，查不到“这个 MD5 之前传过没”，秒传就无从谈起
秒传接口怎么写才不踩坑
别把秒传逻辑塞进上传主流程里。推荐拆成两个独立端点：
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- GET
/api/verify?md5=abc123...：纯查 Redis / DB，毫秒级响应，不碰文件系统 - POST
/api/upload：接收 multipart，但开头就检查$request->header('x-file-md5')，命中则直接return $c->json(['code'=>0, 'url'=>'https://...'])
注意：$_POST 和 $_FILES 在 multipart 请求里不可信，Header 才是唯一安全传递哈希的方式。如果前端用 fetch 发送 application/json，那必须改用 php://input 手动解析 —— 但这样你就没法用 formFile()，得自己处理二进制流。
MinIO/OSS 场景下的哈希校验陷阱
哪怕你存了 MD5，也不能直接信任客户端传来的值。OSS/MinIO 的 putObject 默认不校验服务端哈希，上传过程出错你也发现不了。正确做法是：
- 上传完成后，调用
headObject获取服务端返回的ETag（S3 兼容服务中，它就是 MD5 hex） - 比对客户端 MD5 和 ETag，不一致就删掉对象并报错
- 若用
uploadFile（分片上传），ETag 是拼接各分片 MD5 后再 MD5 的结果，和单文件 MD5 不同 —— 秒传必须统一走单文件上传路径，或自己实现分片级哈希合并
真正难的不是算一次 MD5，而是让哈希在前后端、上传路径、存储服务之间全程一致且可验证。漏掉任意一环，秒传就变成“伪秒传”，用户上传失败还毫无感知。
