为何多数开发者仍在事件回调中传递event参数？

你提到的不声明event参数也能访问的情况，本质是依赖了全局的event对象——这是早年IE浏览器的遗留特性，现在部分现代浏览器为了兼容老代码也支持，但它存在诸多问题，这也是多数开发者选择显式传递参数的原因：

• 兼容性与标准性问题
  全局event并非ECMAScript或DOM标准定义的特性，仅部分浏览器（如Chrome、Firefox非严格模式下）支持。如果代码需要在更广泛环境运行（比如旧版浏览器、严格模式下），依赖全局event会直接报错。而显式接收参数是标准的DOM事件处理方式，所有符合规范的环境都兼容。

• 作用域与异步场景失效
  全局event绑定在当前执行上下文，遇到嵌套函数、异步操作（比如setTimeout、Promise回调）时，全局event可能已被覆盖或不存在。比如：

  btn.addEventListener("click", myfn.bind());
  function myfn() {
    setTimeout(() => {
      console.log(event.target); // 此处event可能不是点击事件对象，甚至报错
    }, 1000);
  }
  

  显式传递参数则能通过闭包保留正确的事件对象：

  btn.addEventListener("click", myfn.bind());
  function myfn(event) {
    setTimeout(() => {
      console.log(event.target); // 正常获取点击目标
    }, 1000);
  }
  

• 代码可读性与可维护性
  显式声明event参数，能让其他开发者一眼明白这是事件处理函数、依赖事件对象。如果依赖全局event，他人看到event.target时会困惑这个变量的来源，在复杂项目中这种隐式依赖会大幅提升理解成本，也更容易引发bug。

• 严格模式下无法使用
  在严格模式（"use strict"）中，全局event会被禁用，直接访问会抛出ReferenceError。而显式传递参数不受严格模式影响，是更安全的写法。

• 函数复用性更高
  显式接收event参数的函数不依赖全局环境，可轻松在不同事件绑定中复用，甚至作为普通函数调用时手动传入模拟的事件对象。而依赖全局event的函数耦合性极高，只能在特定事件触发上下文里运行。

内容的提问来源于stack exchange，提问作者Max Pattern