esbuild 调换 target 顺序后，旧浏览器需要的转换消失

目标列表里明明有旧 Chrome，构建产物仍保留 ??；只交换两个目标的位置，输出又开始转换。若工具汇总了多个来源的浏览器目标，应检查同一种引擎是否被传入了不止一个版本。

esbuild 0.28.1 会让同一引擎后出现的版本覆盖前者。正式 0.28.2 已改成在重复目标中取最低版本，避免目标顺序改变兼容要求。

同时列出旧版和新版，旧版要求不能被覆盖

下面两个列表在受影响版本中结果不同：

chrome47,chrome147
chrome147,chrome47

对源码 a ?? b，第一种会按后面的 Chrome 147 判断，可能原样保留空值合并；第二种按 Chrome 47 判断，才会生成相应旧语法。这里 a、b 代表应用已有的表达式，不是缺少变量声明的完整程序。

多个目标本来用于约束输出同时满足所有环境。把新版追加到旧版后面，不应悄悄撤销对旧版的支持。先保留最终传给 esbuild 的目标数组，而不只看 Browserslist 或上层工具的初始配置；重复值可能是在合并阶段才产生。

更新打包器，或先按引擎归并最低版本

可采用兼容的 esbuild 0.28.2，保留原浏览器支持范围重新构建。项目通过框架调用 esbuild 时，核对失败步骤实际使用的版本，不能以根目录另装了新版作为依据。

暂不能更新时，在产生目标列表的配置层消除同引擎的重复项，并保留其中最低的受支持版本。版本比较应理解数字分段，不能用字符串字典序把 chrome100 与 chrome99 排错；更适合沿用工具已有的浏览器版本处理能力，而不是临时写一条字符串排序。

不同引擎仍要分别保留，例如 Safari 的要求不能因 Chrome 目标已归并而消失。显式 ES 语言目标也不是某个浏览器版本的同义词。不要为了让构建成功，直接丢弃产品仍承诺支持的旧环境。

看产物，也看目标环境的实际行为

保留至少一处旧环境需要降级的语法，确认重复目标调换顺序后输出要求一致，再检查原本支持的浏览器。语法能够解析与 API 已有实现是不同条件；esbuild 的目标转换不会自动补齐所有运行时 API。

如果去重后仍报“不支持某种转换”，应继续判断打包器是否具备该转换能力。那属于转换范围问题，不能再靠调整重复 target 的排列解决。