分片上传需手动实现，layui upload.render 不支持原生 chunksize 参数；须在 choose 回调中用 file.slice() 切片，配合 ajax/fetch 发送，自行管理切片大小、序号、进度及失败重试。
分片上传必须手动实现，upload.render 不提供原生 chunksize 参数
layui 的 upload 组件本身没有内置分片逻辑，所谓 chunksize 并非官方支持的配置项——你在网上看到的 chunksize: 5*1024*1024 是误传或自定义扩展写法，直接写进 upload.render 的 options 中不会生效。
真正可行的路径是：利用 choose 回调 + 原生 File.prototype.slice() 切片，再通过 $.ajax 或 fetch 手动发请求。Layui 只负责触发选择、提供基础上传入口，分片控制权完全在你手上。
-
choose回调里拿到file对象后立即计算总片数、生成唯一fileId（推荐用文件名+大小+修改时间做简单哈希） - 不要依赖
upload.start()或upload.upload()启动分片；它们只适用于单次完整上传 - 服务端必须配套实现分片接收、暂存、合并逻辑，否则前端切了也没用
关键参数得自己算：切片大小、起始偏移、当前片序号
分片不是靠配置开关，而是靠你在 choose 里写的 JavaScript 控制。核心变量就三个：chunkSize、start、currentChunk，它们决定每次发哪一段二进制数据。
示例中常见错误是硬写 chunkSize = 2 * 1024 * 1024 却不校验浏览器是否支持 slice()（IE10+ 才有），或忽略大文件 lastModified 精度问题导致 fileId 冲突。
-
chunkSize建议设为2 * 1024 * 1024（2MB）到5 * 1024 * 1024（5MB）之间，太大易超时，太小增加 HTTP 开销 -
start = currentChunk * chunkSize，end = Math.min(start + chunkSize, file.size)，必须用Math.min防止最后一片越界 - 每次上传的
FormData至少要带：file（切片 Blob）、chunk（当前序号，从 0 开始）、chunks（总片数）、fileId（服务端用它聚合）
accept 和 size 仍需设置，但只是前端第一道过滤
accept: 'file' 或 accept: 'video' 加上 exts: 'mp4|avi' 能限制用户可选文件类型，size: 51200（单位 KB）能拦截明显过大的单个文件（比如 50MB 以上 ZIP），但这对分片上传只是辅助——它拦不住用户选一个 2GB 视频然后前端默默切片上传。
-
size值建议略高于你实际允许的最大单文件体积，比如后端只接 4GB 文件，前端可设size: 4096000（约 4GB），避免误拦 - 真正防爆的手段是服务端校验：
chunks总数上限、fileId对应的临时文件夹存活时间、单片大小是否一致 - 别信
acceptMime能完全防伪造，它只影响文件选择框弹出时的筛选，用户改后缀或拖拽绕过很容易
进度反馈和失败重试得自己补，upload 的 progress 回调不适用分片场景
Layui 的 progress 回调只对单次完整上传有效，一旦你弃用 url 配置走手动 ajax，这个回调就收不到任何进度。所有分片的上传进度、失败重试、断点续传，都得自己维护状态。
- 用
Map或对象缓存每个fileId对应的已上传片序号数组，避免重复上传同一片 - 每片上传成功后更新 UI 进度条：
Math.round((uploadedChunks / totalChunks) * 100) - 网络失败时，记录失败片序号，等用户点击“重试”再单独发起该片请求，不要全量重传
分片上传的复杂点不在切片本身，而在于前后端状态同步：前端要确保每片不丢、不重、不错序，服务端要能按 fileId 归集、校验完整性、安全合并。漏掉任意一环，用户上传到 99% 失败，就只能从头再来。
