### Version of antd-mobile 5.43.0。组件级复现使用当前 master 的固定源码：`eee5477f8d6221ced8298e3547eb03e0a037a615`。 ### Operating system and its version Others。已验证环境是 Node.js 24.19.0、React 18.3.1、React Test Renderer 18.3.1。 ### Browser and its version 尚未进行浏览器或移动设备验证。下面的结果来自真实 ImageUploader 组件及其状态逻辑的 React Test Renderer 测试。 ### Sandbox to reproduce 尚未发布在线 sandbox。下面的普通 React 示例可放入官方 Codesandbox/StackBlitz 环境，固定 `antd-mobile@5.43.0` 后手动验证；该示例目前仅做过语法编译，未在浏览器中运行。 ```tsx import React, { useEffect, useRef, useState } from 'react' import { Dialog, ImageUploader } from 'antd-mobile' import type { ImageUploadItem } from 'antd-mobile' // Manual reproduction example. Compiled for syntax only; not browser-tested. function initialImage(label: string, color: string): ImageUploadItem { const svg = `` return { key: label, url: `data:image/svg+xml,${encodeURIComponent(svg)}` } } export default function ImageUploaderRaceDemo() { const [value, setValue] = useState(() => [ initialImage('A', '#1677ff'), initialImage('B', '#00b578'), ]) const [changes, setChanges] = useState([]) const [uploadDone, setUploadDone] = useState(false) const urls = useRef([]) useEffect(() => () => urls.current.forEach(url => URL.revokeObjectURL(url)), []) return (

选择一张图片 C 后，马上删除 A。保持确认框打开 8 秒，再确认。

上传 C：{uploadDone ? '已完成' : '等待选择或上传中'}

{ setValue(next) setChanges(prev => [...prev, JSON.stringify(next.map(item => item.key))]) }} upload={async file => { const url = URL.createObjectURL(file) urls.current.push(url) await new Promise(resolve => setTimeout(resolve, 8000)) setUploadDone(true) return { key: 'C', url } }} onDelete={item => Dialog.confirm({ content: `删除 ${item.key}？请等 C 上传完成后再确认。` }) } />

当前列表：{JSON.stringify(value.map(item => item.key))}

onChange 记录：

{changes.join('\n')}

) } ``` ### What happened? `onDelete` 支持返回 Promise。等待删除确认期间，如果上传或其他删除改变了图片列表，确认会把列表覆盖为旧数据。常见流程： 1. 已有 A、B，开始上传 C。 2. 点击删除 A，让 `onDelete` 的确认 Promise 保持 pending。 3. C 上传成功，`onChange` 正常收到 `[A, B, C]`。 4. 确认删除 A。预期：列表为 `[B, C]`，只删除已确认的 A。实际组件测试结果：列表变成 `[B]`，C 的上传结果从列表中丢失。另一种情况：A 的删除确认等待期间先删除 B，随后确认 A，结果会恢复已删除的 B。这里即使每张图片提供不同的 `key` 也会发生。固定源码中的删除回调等待 `onDelete` 后，仍使用开始删除时的 `value` 和 `index`： https://github.com/ant-design/ant-design-mobile/blob/eee5477f8d6221ced8298e3547eb03e0a037a615/src/components/image-uploader/image-uploader.tsx#L272-L275 上传完成则已经使用函数式更新： https://github.com/ant-design/ant-design-mobile/blob/eee5477f8d6221ced8298e3547eb03e0a037a615/src/components/image-uploader/image-uploader.tsx#L234 ### Relevant log output 组件级测试结果： ``` PASS sequential immediate deletes: expected=[] actual=[] PASS rejected async delete preserves appended item: expected=[A,B,C] actual=[A,B,C] FAIL confirmed async delete preserves appended item: expected=[B,C] actual=[B] FAIL delayed delete does not resurrect another deleted item: expected=[C] actual=[B,C] FAIL delayed deletion after earlier item is removed: expected=[C] actual=[A,C] FAIL upload completion survives pending deletion: expected=[B,C] actual=[B] PASS duplicate URL deletes only selected occurrence: expected=[second] actual=[second] ``` 测试使用未修改的组件源码、真实 React hooks 和生产依赖；上传场景调用渲染出的 input 的实际 `onChange` 处理函数，`upload` 和 `onDelete` 使用可控 Promise。文件选择事件由测试提供，没有访问真实文件选择器或上传服务器。CSS 未参与验证，也没有把组件测试当作设备测试。 ### 关于修复语义的一个问题修复需要保留 [#4494](https://github.com/ant-design/ant-design-mobile/pull/4494) 的同 URL 多项行为，也不能只改成按旧 index 操作当前数组，否则并发删除或重排后可能删错图片。当前 key 可选；受控父组件可能在等待期间克隆、替换或删除条目。无 key 的克隆对象有时无法区分是原图片还是另一张同 URL 图片。维护者更倾向于仅在能确认原条目仍存在时删除、遇到身份不明确时不改变列表，还是希望按一个明确的稳定身份规则继续删除？希望先确认这个边界，避免修复引入误删。本报告和组件级复现由 AI 辅助准备，验证范围如上；尚未实现修复。

dvd233 analysis page

dvd233