本教程详细阐述了如何在网页中实现多个文件输入框（`input type="file"`）的独立图片预览功能。通过识别并解决常见错误，如重复id导致的元素选择不当，我们将演示如何利用dom遍历和事件委托，为每个上传区域动态绑定预览逻辑，确保用户上传的每张图片都能在其对应的位置正确显示。
引言：多文件上传与预览的挑战
在现代Web应用中，用户经常需要上传多张图片，例如在商品发布、个人资料编辑或内容创作等场景。为了提供良好的用户体验，通常需要在用户选择图片后立即在页面上显示预览图，并更新相关的上传状态。然而，当页面中存在多个文件输入框（input type="file"）时，如何确保每个输入框都能独立地更新其对应的预览区域，是开发者常遇到的挑战。常见的错误往往导致所有预览都集中显示在第一个区域，或状态文本更新错乱。
核心问题分析：ID重复与元素定位不准确
导致多文件输入框预览功能失效的核心原因主要有两个：ID的重复使用和元素定位策略的不当。
-
ID的唯一性原则： HTML规范明确规定 id 属性在整个文档中必须是唯一的。在原始代码中，所有预览 <img> 元素都被赋予了相同的 id="chosen_image"。
<img id="chosen_image">
当JavaScript代码执行 document.getElementById('chosen_image') 时，它总是返回文档中第一个匹配该ID的元素。这意味着无论用户点击了哪个上传按钮，选择了哪个文件输入框，预览逻辑最终都会尝试更新页面上的第一个 <img> 元素，从而造成其他区域的预览功能失效。
-
相对元素定位的局限性： 原始代码中尝试使用 e.target.nextElementSibling 来更新上传状态文本。
e.target.nextElementSibling.textContent = e.target.nextElementSibling.textContent.replace(/False/, input.files[0].name)
这种方法依赖于非常特定的HTML结构，即目标 label 元素必须是 input[type="file"] 元素的直接下一个兄弟节点。一旦HTML结构发生变化（例如，在 input 和 label 之间添加了其他元素，或者 label 不再是直接兄弟），这种定位方式就会失效，导致状态文本无法正确更新。
解决方案一：基于类名和索引的关联（初步改进）
一种初步的改进方法是将预览图片从 id 改为 class，然后通过索引来关联 input 元素和对应的 img 元素。
HTML 结构调整： 将 <img id="chosen_image"> 改为 <img class="chosen_image">。
<!-- 示例 HTML 结构（部分） -->
<div class="section_header">
<figure class="uploaded_image_container">
<img class="chosen_image" alt="图片预览">
</figure>
<!-- ... 其他元素 ... -->
<input type="file" accept="image/png, image/jpg, image/svg" id='img_20' style="display:none">
<label>Upload complete: False</label>
</div>
<!-- 更多相同的结构 -->JavaScript 代码：
const previewImages = document.getElementsByClassName('chosen_image'); // 获取所有预览图片元素
const fileInputs = document.querySelectorAll('input[type=file]'); // 获取所有文件输入框
// 遍历所有文件输入框并绑定事件
for (let i = 0; i < fileInputs.length; i++) {
const input = fileInputs[i];
input.onchange = (e) => {
if (e.target.files.length) {
const reader = new FileReader();
reader.readAsDataURL(e.target.files[0]); // 读取当前文件输入框选择的文件
reader.onload = () => {
// 使用索引 i 更新对应的预览图片
if (previewImages[i]) {
previewImages[i].setAttribute("src", reader.result);
}
// 这里的 e.target.nextElementSibling 依然依赖于特定结构， 
