每个 upload 实例必须绑定唯一 ID 元素，因 Layui upload.render() 依赖 DOM id 进行实例绑定和事件委托；共用同一 id 会导致后实例覆盖前实例，点击任意按钮均触发最后一个实例，故须为每个上传区域分配独立 ID（如 #upload-1、#upload-2），严禁重复 id 或使用 class 初始化。
每个 upload 实例必须绑定唯一 ID 元素
layui 的 upload.render() 依赖 dom 元素的 id 做实例绑定和事件委托，若多个实例共用同一个 id（比如都写 elem: '#upload-btn'），后 render 的会覆盖前一个，导致点击任意按钮都只触发最后一个实例。
正确做法是为每个上传区域分配独立 ID，并确保 HTML 中真实存在该元素：
- HTML 中不能出现重复
id，这是 DOM 规范硬性要求 - 每个
upload.render()调用必须指向不同id，例如elem: '#upload-1'、elem: '#upload-2' - 避免用 class 选择器（如
.upload-btn）代替id，Layui upload 不支持 class 初始化
配置对象不能共享引用，否则参数互相污染
如果把配置对象声明一次再多次传入 upload.render()，比如：
const baseConfig = { elem: '#upload-1', url: '/api/upload' };
upload.render(baseConfig);
upload.render({...baseConfig, elem: '#upload-2' }); // ❌ 危险：baseConfig 被修改影响前一个实例
这种写法在 done、choose 回调中容易因闭包捕获错误的 this 或变量而错乱。必须为每个实例创建全新对象：
- 用字面量直接写配置，或用
Object.assign({}, baseConfig)浅拷贝 - 回调函数内所有逻辑（如预览容器、成功后 DOM 操作）必须基于当前实例的 ID 精确定位，例如
$('#preview-1')不能写成$('.preview') - 特别注意
bindAction、choose中读取的this.files是实例私有，不可跨实例访问
表格内嵌 upload 时，禁止在 templet 中反复 render
在 table.cols 的 templet 里写 upload.render() 是最典型的 ID 冲突温床——每渲染一行就执行一次 render，不仅 ID 重复（因为 templet 返回的是相同字符串），还会不断叠加事件监听器，最终内存爆炸。
安全做法是彻底分离结构与逻辑：
- 在表格外定义固定节点，如
<div id="upload-trigger-1"></div>和<div id="upload-trigger-2"></div> - 每个
upload.render()绑定到唯一 trigger 节点，上传成功后通过data-id或行索引关联回对应表格行 - 绝对不要在
templet字符串里拼接<script>upload.render(...)</script>
老版本 Layui（如 2.5.7）没有 destroy，需手动清理残留
即使你用了不同 ID，若页面动态销毁/重建上传区域（比如 tab 切换、弹窗打开关闭），旧实例的事件监听器和文件缓存仍驻留内存，下次 render 后可能响应两次——表现就是“点一次上传，发两个请求”。
对无 destroy() 的版本，必须手动清理：
- 记录每次
upload.render()的返回值，例如window.uploadIns1 = upload.render({...}) - 在区域销毁前，调用
layui.$('.layui-upload-list').off('click', '.layui-icon-close')解绑删除事件 - 清空自己维护的文件列表数组（如
window.fileList1 = []），否则choose回调里obj.pushFile()会持续累加 - 重置 input 值：
layui.$(uploadIns1.elem).find('input').val('')，防止浏览器复用上次选择
ID 冲突只是表象，真正难缠的是实例状态未隔离——哪怕 ID 不同，共享配置、复用 DOM 节点、忽略销毁逻辑，都会让多个 upload 彼此撕咬。动手前先想清楚：这个实例的生命周期归谁管？它的 DOM、事件、数据是否真的干净独立？
