用ES6 Proxy获取DOM元素是否为最佳实践？兼谈直接ID访问DOM

嘿，很高兴你尝试用Proxy重构旧的ES5代码，这两个问题其实挺有代表性的，我来给你逐一解答：

一、用Proxy获取DOM元素是不是良好实践？ #

你的Proxy实现确实挺巧妙的，能让代码简洁不少，但得结合场景来看它是不是“良好实践”，咱来拆解下优缺点：

优点： #

• 代码更简洁可读：不用反复写document.getElementById(id)，直接通过解构赋值就能拿到所有需要的DOM元素，写起来爽，读起来也清晰。
• 逻辑可复用/易扩展：如果后续需要修改获取元素的逻辑（比如换成querySelector、添加缓存逻辑，或者给元素加默认值），只需要修改Proxy的get方法就行，不用改所有调用的地方，灵活性拉满。
• 懒加载特性：只有当你真正访问某个变量时，Proxy才会去调用getElementById，如果有些元素在代码里只是定义了但没用到，就不会做无用的DOM查询。

缺点： #

• 隐式逻辑增加理解成本：如果其他开发者没看到Proxy的定义，可能会困惑这些变量是从哪来的，尤其是在大型项目或者多人协作场景下，这种“魔法”行为可能会增加维护成本。
• 调试复杂度提升：如果某个元素返回null，你得先排查是元素本身不存在，还是Proxy的拦截逻辑出了问题，比直接调用document.getElementById多了一层间接性。
• 无缓存带来的重复查询：你的当前实现每次访问变量都会重新调用getElementById，如果频繁访问同一个元素，会重复查询DOM（虽然DOM查询性能现在已经很好，但极端场景下还是有开销）。可以给Proxy加个缓存优化下：

  const domCache = {};
  const { addType, addDescription } = new Proxy({}, {
    get(_, id) {
      if (!domCache[id]) {
        domCache[id] = document.getElementById(id);
      }
      return domCache[id];
    }
  });
  

总结： #

如果是小型项目、个人项目，或者团队内部已经达成共识，这种方式完全没问题，能提升开发效率；但如果是大型项目、开源项目，或者需要和不熟悉这个模式的开发者协作，更推荐显式获取DOM元素（比如封装一个getEl(id)函数），或者给Proxy加上清晰的注释，让逻辑更透明。

二、为什么注释掉Proxy后，还能直接通过ID访问DOM元素？ #

这是浏览器的一个隐式全局绑定特性：当页面中的元素带有id属性时，浏览器会自动在window对象上创建一个同名属性，指向该DOM元素。比如你页面里有<select id="addType">，那么window.addType就会指向这个元素，而因为全局作用域的变量本质上是window的属性，所以你直接写addType就能访问到它。

不过这个特性有几个坑，得注意：

• 非标准特性：这是浏览器的扩展行为，不是ECMAScript标准的一部分，在Node.js等非浏览器环境里完全不生效。
• 命名冲突风险：如果你自己定义了同名的全局变量（比如var addType = "test"），会直接覆盖浏览器自动创建的DOM元素引用，导致后续无法通过addType访问元素，这种bug很难排查。
• 动态元素的不确定性：动态创建的元素也会被绑定到window，但元素被移除后，有些浏览器不会自动删除对应的window属性，可能导致内存泄漏（现代浏览器大多已经修复，但还是不依赖为好）。

所以虽然这个特性看起来方便，但不推荐依赖它，显式获取DOM元素的代码更可靠、更清晰，也不会有潜在的命名冲突问题。

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