Yii框架不支持开箱即用的大文件分片上传，因UploadedFile依赖PHP原生$_FILES机制，要求文件完整暂存临时目录，受upload_max_filesize等限制，易超时、内存溢出且无断点续传能力。
Yii 框架本身不支持开箱即用的大文件分片上传，必须在应用层手动实现分片逻辑，否则直接用 UploadedFile::getInstance 会触发 PHP 的 upload_max_filesize 和 post_max_size 限制，上传超过几 MB 就失败。
为什么不能直接用 UploadedFile 处理大文件
因为 UploadedFile 依赖 PHP 原生的 $_FILES 机制，而该机制要求整个文件先被完整接收并暂存到临时目录（sys_get_temp_dir()），再由 Yii 封装成对象。这意味着：
- 单次请求必须承载整个文件 —— 超过
upload_max_filesize（默认 2MB）直接报错UPLOAD_ERR_INI_SIZE - 内存和临时磁盘压力大，超时风险高，Nginx/Apache 默认
client_max_body_size或LimitRequestBody也会拦截 - 无断点能力，网络抖动一次就得重传全部
前端分片 + 后端合并的最小可行路径
核心是绕过 $_FILES，让前端按固定大小（如 5MB）切片，每个分片走独立 HTTP 请求，后端只收二进制流，不走表单解析。
关键实操点：
- 前端用
Blob.slice()切片，按顺序发POST /api/upload/chunk?file_id=xxx&index=0&total=12 - 后端接口禁用 CSRF 验证（
enableCsrfValidation = false），用Yii::$app->request->getRawBody()直接读取原始字节流 - 分片存到临时目录（如
@runtime/uploads/chunks/{file_id}/0000），命名带序号便于校验和排序 - 收到最后一个分片后，用
file_put_contents+FILE_APPEND合并，或用cat命令（Linux）批量拼接 - 合并前建议对每个分片做
md5(file_get_contents($chunkPath))校验，防止传输损坏
如何生成和验证文件唯一标识
不能依赖前端传来的文件名或路径，必须服务端计算指纹，否则同名文件覆盖、恶意伪造分片都会出问题。
推荐做法：
- 前端在切片前，用 Web Crypto API 计算整个文件的
MD5（或 SHA-256，更安全），作为file_id发送给后端初始化接口 - 后端收到首个分片时，检查
@runtime/uploads/chunks/{file_id}/是否已存在；若存在，直接返回已上传分片索引列表，实现断点续传 - 合并完成后，对最终文件再算一次 MD5，和前端传入的比对，不一致则删掉并返回错误
- 注意：PHP 的
md5_file()对大文件很慢，可改用分块读取 +hash_update()增量计算
并发上传与服务端资源控制
前端并发发 5 个分片请求，不代表后端要同时处理 5 个写入 —— 文件系统锁、磁盘 I/O、临时目录空间都可能成为瓶颈。
稳妥策略：
- 后端接口加轻量级文件锁：
fopen("{$chunkDir}/.lock", "c")+flock()，避免同一file_id的多个分片写冲突 - 限制单个 IP 每秒最多发起 3 个分片请求（用 Yii 的
RateLimiter或自定义行为） - 临时分片目录定期清理：用
yii\console\controllers\AssetController类似思路，写个定时命令扫描mtime 的过期 <code>chunks/子目录 - 别把分片存在数据库 blob 字段里 —— IO 更差，备份膨胀，查询无意义
真正难的不是切片和合并，而是状态一致性：前端认为“第7片失败”，后端临时目录里却有第7片但没标记完成，下次续传就可能跳过或重复。所有中间状态必须可查、可删、可幂等，否则上线后半夜就会收告警。
