能否自定义getById函数替代document.getElementById？有哪些影响？

首先修正你示例代码的错误 #

你给出的示例代码存在逻辑bug，函数参数ID没有被实际传入原生方法，写死了字符串'Id'，会导致无论传入什么参数，都只会查询id为Id的元素，正确的基础封装写法如下：

function getById(id) {
  // 此处可扩展你需要的统一逻辑，比如参数校验、异常提示等
  return document.getElementById(id)
}
// 调用示例
const ele = getById('your-target-id')

正常封装后的潜在不良影响 #

• 极小的性能损耗：多了一层函数调用，但对于上千次量级的调用来说，现代JS引擎的优化可以让这个损耗完全可忽略，不会对页面性能产生感知级别的影响
• 团队协作成本：如果没有提前统一约定，其他不了解封装逻辑的开发者需要额外查询函数定义，增加理解成本
• 命名冲突风险：如果直接在全局作用域定义getById，后续引入第三方库或者其他同事写的代码如果也定义了同名函数，会出现覆盖冲突，导致逻辑异常
• 特性一致性风险：如果后续你在封装中额外加了逻辑，没有对齐原生document.getElementById的入参、返回值规则，会出现和原生调用表现不一致的问题，排查问题时容易被忽略；如果使用TypeScript，还需要额外补全类型定义，否则会丢失原生的类型提示能力

封装的优势（你可以根据项目需求权衡） #

• 简化调用写法，上千次调用场景下可以减少大量重复代码输入
• 支持扩展统一逻辑：比如可以统一加参数合法性校验、查询失败打警告日志、老旧浏览器兼容处理等，只需要修改封装函数一处，所有调用位置都会生效
• 方便后续迭代：如果后续需要调整底层查询逻辑，比如要优先从缓存的DOM节点池中查询，不需要修改上千个调用位置，只要调整封装函数即可

优化建议 #

• 不要把工具函数直接挂载到全局作用域，建议统一收敛到公共的DOM工具模块中，比如导出一个工具对象：

  export const DomUtils = {
    getById(id) {
      return document.getElementById(id)
    },
    // 其他你要封装的DOM操作方法
  }
  

  调用时使用DomUtils.getById('xxx')即可完全避免命名冲突
• 团队项目中提前做好公共工具函数的文档说明，对齐使用规范
• 封装时尽量对齐原生方法的入参、返回值规则，避免出现逻辑不一致的问题

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