在 choose 回调中，需通过 data-index 或闭包将 layui 自增 index 与文件对象绑定到预览 DOM；删除时必须同步执行 delete files[index] 清缓存、移除对应 DOM，并区分待上传与已上传图片的删除逻辑。
choose 回调里怎么绑定预览图的点击删除事件
关键不是“点击图片就删”，而是得在 choose 回调中拿到文件队列引用，并让每个预览图能精准对应到它在队列里的索引。layui 的 obj.pushfile() 返回的是一个带自增 key 的对象，不是数组，直接用 index 做下标会错位。
正确做法是：在 obj.preview 内部，把当前 index 和文件对象一起存进 DOM 元素的 data- 属性，或者用闭包绑定；同时维护一个全局或作用域内的文件映射对象（比如 let fileMap = {}），用 index 作 key 存原始 file 对象。
-
obj.preview的index是 layui 自增的唯一序号，每次选择都会重置，不能跨次复用 - 不要用
$('img').eq(i).remove()这类靠顺序的操作，多选时 DOM 插入顺序和文件入队顺序可能不一致 - 删除前必须调用
delete files[index]，否则下次上传仍会提交该文件
为什么点击删除后再次上传会重复提交已删图片
这是最常踩的坑：只删了 DOM，没清文件队列。Layui 的 upload.render 在 auto: false 模式下，choose 阶段只是把文件塞进内部缓存，bindAction 触发时才真正读取这个缓存 —— 而这个缓存不会因 DOM 删除自动更新。
所以必须手动清理。示例中常见的错误写法是：$(img).remove(); 就完事了。正确流程是：
- 从 DOM 上取
data-index或通过事件委托拿到触发元素对应的index - 执行
delete files[index]（注意：files是obj.pushFile()返回的对象） - 再移除对应
<img>或整个容器节点 - 如果用了
multiple: true，还要检查是否所有文件都删完了，必要时重置 UI 状态
删除按钮放哪？用 img click 还是单独 button
直接给 <img> 绑 click 容易误触，尤其在移动端；但放单独按钮又得额外写 CSS 定位、hover 显示逻辑。实际项目中更稳妥的做法是：用 <div class="preview-item"> 包裹 <img> 和删除按钮，按钮绝对定位在右上角，靠 mouseenter/mouseleave 控制显隐。
这样既避免误点，又能统一管理生命周期。注意两点：
- 删除按钮的
id或data-index必须和对应图片一致，推荐用data-index="{{index}}" - 事件监听要用事件委托，比如
$(document).on('click', '[data-action="del-img"]', handler)，否则动态插入的按钮无法响应 - 别用
layer.confirm嵌套太深，回调里删 DOM 和文件要同步，否则用户点“确定”后界面没反应
done 回调里上传成功后的图片怎么支持删除
服务端返回的已上传图片（比如 res.href）和本地预览图是两回事。前者删的是服务器资源，需额外发请求；后者删的是浏览器内存里的 File 对象。两者都要处理，但逻辑分离。
典型结构是：预览区分为“待上传”和“已上传”两个容器，各自维护独立的数据源。已上传图片的删除按钮应携带服务端返回的唯一标识（如 res.id 或 res.filename），点击后调用 $.post('/delete', {id: xxx})，成功后再从 DOM 和本地数组中移除。
容易忽略的细节：
- 删除已上传图后，要同步更新你用来提交表单的图片 ID 数组（比如
imgIds = imgIds.filter(id => id !== clickedId)） - 如果页面有“重新上传替换”需求，删完已上传图后，得把对应位置留空或允许再次点击上传按钮
- 不要把待上传队列和已上传列表混在一个数组里管理，后期排序、校验、提交都会混乱
