AI审查代码乱改target：事件委托为何崩？

别被整齐的变量名骗了

最近用 AI 工具审查前端代码，碰到一个挺有意思的情况：只要看到处理change或click的函数，AI 就爱把里头所有event.target改成event.currentTarget都换掉。它想的八成是currentTarget更靠谱——它指向的是你挂监听器的那一个元素，不像target会随事件冒泡换来换去。

乍一看这建议挺像回事，代码好像更“健壮”了。可真改完一跑，有的地方没事，有的地方直接崩，或者逻辑全乱。尤其碰上事件委托（Event Delegation）或者处理复选框状态，这种“一刀切”的改法就是灾难。

说到底，AI 常常只盯着函数签名和变量名，不管事件到底绑在哪儿，也不管这个“事件”是原生 DOM 事件还是业务层包过的普通对象。不分情况地统一读写入口，换来的只是形式上整齐的错误代码。

target 和 currentTarget 到底在回答什么问题

想弄清该读哪个，得先看这两个属性各自在说什么。

currentTarget回答的是：“谁监听了这个事件？”它永远指向你调用addEventListener的那个元素。事件从哪个子元素冒上来都一样，currentTarget都不变。

target回答的是：“谁触发了这个事件？”它指向用户实际点击、输入或交互的那个最深层元素。

举个最简单的例子。假如你直接把监听器绑在一个<input>输入框上：

inputElement.addEventListener('change', (e) => {
  console.log(e.target === e.currentTarget); // true
});

这时候，target和currentTarget如果两者指向同一个对象，读哪个都一样，拿到的都是那个输入框。这种情况下AI建不建议改都无所谓，真改了反倒可能让同事觉得你多此一举。可一旦换成事件委托，情况就不同了，比如在父容器上监听所有子项里的按钮点击：

<ul>这时若听信AI的建议，把改成<li>

listElement.addEventListener('click', (e) => {
  // e.currentTarget 是 <ul>
  // e.target 可能是 <button> 或 <span>
  if (e.target.matches('button')) {
    handleButtonClick(e.target);
  }
});

e.target改成e.currentTarget那你永远只能拿到那个列表容器，根本不知道用户具体点的是哪个按钮。说到底，这就是“脱离上下文谈规范”。<ul>

因此审查规则的头一步不该是“统一改成某个属性”，而是先判断监听器绑在哪：绑在具体控件上，读没区别；绑在父容器上做委托，就必须读才找得到真实来源。target或currentTargettarget

复选框的陷阱：别把value当布尔值

选对对象之外，属性也得选对。AI翻车往往就翻在这里。

不少AI模型一看到就下意识以为要取。放在文本输入框里这没错，换成复选框（Checkbox）就错得离谱。onChangevalue

// 错误示范
const isChecked = Boolean(event.target.value); 
// 正确做法
const isChecked = event.target.checked;

HTMLInputElement的value属性用在checkbox上，默认值一般是"on"，也可能是你自己定义的字符串。勾选状态变了，它也不会因此变成true或false。勾没勾上，要看的是checked属性。

假如AI审查工具只因为函数名叫handleToggle或onChange，就顺手补全成.value，代码编译是能过，可业务逻辑全错了。更麻烦的是，有的AI还会自作聪明加上类型断言，例如event.target as HTMLInputElement。TypeScript确实不吭声了，但DOM的语义一点没变。要是target压根不是Input元素（比如事件冒泡冒上来的），运行时这个断言就会报错，或者拿到undefined。

所以审这类代码，有两件事必须确认：

1. 目标元素到底是不是Input？（可能得靠instanceof或者检查标签名）
2. 我们要取的是value还是checked？

仅凭函数名推不出这两点，得看上下文。上下文要是缺了，审查工具该标“信息不足”，而不是乱猜。

业务消息不是DOM事件

前面聊的都是原生DOM事件。可到了现代前端开发里，尤其是用上React、Vue或自研组件库之后，回调里传进来的往往压根不是Event对象，可能就是个普通JavaScript对象，也可能是框架合成过的事件。

这种时候AI要是还抱着event.target.value这套逻辑不放，方向就整个跑歪了。

拿一个自定义业务组件来说，它抛出来的消息大概长这样：

{
  kind: 'toggle',
  checked: true
}

或者：

{
  kind: 'pick',
  id: 'item-123'
}

这类对象里并没有target，没有currentTarget，甚至没有preventDefault这些方法，它们只是单纯的数据载荷（Payload）。

假如有个回调函数叫onSelectionChange它接收的参数叫message或data那AI审查时就不该想着从里面抠DOM属性，该做的是核对这个对象的结构符不符合业务契约。

下面这个例子处理的就是这类合成消息，跟DOM环境完全不沾边：

export function readSelection(message) {
  // 第一步：防御性编程，确保传入的是对象
  if (!message || typeof message !== 'object') return null;
  // 第二步：根据业务约定的kind字段分流
  if (message.kind === 'toggle' && typeof message.checked === 'boolean') {
    return { kind: 'toggle', value: message.checked };
  }
  if (message.kind === 'pick' && typeof message.id === 'string') {
    return { kind: 'pick', value: message.id };
  }
  // 其他情况视为无效或未知消息
  return null;
}

这段代码放到Node.js环境里照样能跑，因为它不调用任何浏览器API。这里的null它表示的是“这条消息解析不了”，并非“用户什么都没选”。要是业务本来就允许ID是空字符串，这套判断还得再改。

碰到这种代码，AI审查该盯的是下面几件事：

1. 输入类型有没有校验？
2. 约定的那些都覆盖到了吗？kind类型？
3. 返回值跟下游函数的预期对得上吗？

这时候AI要是冒出来一句“请把message.checked改成message.target.checked”，那不光没帮上忙，还说明它对业务语境一无所知。

审查规则要学会说“我不知道”

眼下这些AI代码助手，最要命的就是过于自信。它似乎认定每个问题都有标准答案，每段代码都能优化成某种“最佳实践”。

可事件处理这件事上，压根不存在万能的最佳实践。有些场景该读target，有些该读currentTarget，还有些地方根本没有Event对象。

所以一条好的AI审查规则，得具备“承认无知”的本事。一旦检测到下面这几种情况，它就该停下自动修复，改为向开发者提问或者标记警告：

1. 缺少绑定上下文：眼前只有一个孤立的事件处理函数，不知道它绑在Input上还是绑在Document上。这时候该读哪个属性，判断不了。
2. 类型不明确参数类型是any或Event，函数体里却直接去访问特定元素的属性（比如.files或.checked），也没做类型守卫（Type Guard）。
3. 混合语境函数名看着像DOM事件处理（比如onClick），参数结构却像业务消息。这就得靠人来确认，它到底是原生事件还是框架合成事件。

我们喂给AI的训练数据或提示词（Prompt），不能只放“正确代码”，还得塞进大量“反例”。比如：

• 正例直接绑在Input上，读e.target.value。
• 反例委托在父容器上，读e.target.value（这才是正确写法）。要是改成e.currentTarget.value则错误。
• 正例，复选框一变，代码就去读e.target.checked。
• 反例，复选框一变，代码就去读e.target.value，再转成布尔值，那就错了。
• 正例业务回调拿到的是纯对象，可以直接解构：{ id }。
• 反例可要是业务回调里还想去访问event.target，就会出错——event 根本不存在。

这些边界情况只有喂给模型，它才学得会谨慎。不然它就是个套模板的复读机，产出的代码看着漂亮，一跑就崩。

结语

技术审查要盯的是数据有没有从对的口子进业务逻辑，而不是把变量命名风格、访问路径强行统一。target和currentTarget两者各有用处，原生事件和业务消息压根是两个维度的事。

下回AI让你改事件处理代码，先多问它一句：这个监听器绑在哪儿，它清楚吗？这个参数是不是DOM事件，它分得清吗？答不上来，那最好的建议或许就是别听它的，自己翻上下文看。