为何URL无查询字符串时location.search返回空字符串而非'?'

这个设计不是针对查询字符串字段的特殊规则，是Location对象拆分URL组件时的统一设计逻辑，核心原因有三个：

• 首先是保持同API下各属性的行为一致性
  Location对象所有带前置分隔符的组件属性，都遵循「组件真实存在时返回「分隔符+组件内容」，组件不存在时直接返回空字符串」的规则，并非search独有：
  • location.hash存在锚点时返回#锚点内容，无锚点时返回空串，不会单独返回无意义的#
  • 当URL使用协议默认端口时（比如HTTPS的443端口、HTTP的80端口），location.port同样返回空串，不会直接返回默认端口值
• 其次是简化URL处理逻辑，减少冗余判断和拼接错误
  如果无查询串时返回单独的?，开发者每次处理查询参数都要多做一层判断：比如追加新参数时，得先区分拿到的search是空、单个?还是带内容的?a=1，稍有不慎就会拼出?&b=2这种格式错误的URL；解析参数时也得额外判断值是不是仅为?，再决定要不要启动解析流程。
  而返回空串的设计就没有这个问题：拿到空串可以直接判定为无查询参数，追加参数时直接拼接?加参数键值对即可，不需要额外处理无意义的单独分隔符，代码逻辑更简洁，出错概率更低。
• 最后是兼容历史实现的选择
  这个行为最早在网景浏览器、早期IE版本中就已经实现，后续W3C制定DOM标准、WHATWG制定URL标准时，都选择兼容已经被开发者广泛使用的现有实现，没有修改这个既定行为，避免破坏存量网页的正常运行。

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