Web Component属性设置竞态问题：属性升级方案优化及Chrome疑似Bug排查

这确实是Web Components开发中非常头疼的一个场景——当自定义元素还没完全构建就绪时就设置属性，很容易出现属性覆盖setter的问题，尤其在框架驱动的组件加载、绑定场景里特别常见。

你提到的Google开发者文档里的属性升级方案，核心逻辑是清理实例自身的属性再重新赋值触发setter，但只能约70%生效，这其实是因为connectedCallback的执行时机不一定完全等于元素setter/getter就绪的时机。而用setTimeout延迟赋值虽然能解决问题，但确实不够优雅，还可能引入不必要的时序依赖。

更可靠的优雅解决方案：利用customElements.whenDefined() #

我们可以借助customElements.whenDefined()方法，它会返回一个Promise，当目标自定义元素的定义完全注册完成后才会resolve。结合这个特性，我们可以在构造函数里先收集所有提前设置的属性，等元素定义就绪后再统一处理属性升级：

constructor() {
  super();
  // 用来暂存定义完成前设置的属性
  this._pendingProperties = {};

  // 收集当前元素上已存在的所有属性
  const attributes = this.attributes;
  for (let i = 0; i < attributes.length; i++) {
    const attr = attributes[i];
    this._pendingProperties[attr.name] = attr.value;
  }

  // 等待元素定义完全就绪
  customElements.whenDefined(this.localName).then(() => {
    this._upgradePendingProperties();
  });
}

_upgradePendingProperties() {
  for (const prop in this._pendingProperties) {
    if (this.hasOwnProperty(prop)) {
      const value = this._pendingProperties[prop];
      delete this._pendingProperties[prop];
      // 此时setter已完全就绪，赋值会正确触发setter逻辑
      this[prop] = value;
    }
  }
}

这个方案的优势在于：

• 完全基于Web Components标准API，没有hack性质的延时
• 确保在元素的类定义、所有setter/getter都就绪后再处理属性，从根源上避免覆盖问题
• 适用于异步加载组件定义的场景，这也是框架中最常见的情况

关于是否是Chrome浏览器Bug的疑问 #

这并不属于Chrome的Bug，而是Web Components生命周期的固有特性：
当浏览器解析到自定义元素标签时，会先创建一个基础的HTMLElement实例（此时元素还未关联到你的自定义类），如果此时设置属性，这些属性会作为实例自身的自有属性存在。当后续自定义类定义完成后，实例会被升级到自定义类，但实例自身的自有属性优先级高于原型链上的setter，所以会出现覆盖的情况。

Google文档里的connectedCallback方案之所以不能100%生效，是因为connectedCallback的执行时机是元素插入DOM时，而此时元素的类升级可能还在微任务队列中处理，导致setter还未完全就绪。而setTimeout把赋值放到宏任务队列，等所有微任务（包括类升级）完成后再执行，所以能生效，但这种方式不够严谨。

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