针对你遇到的多语言Web应用拼写检查切换问题，我结合浏览器规范、实现细节和社区经验来逐一解答你的疑问：

1. 规范层面的原因 #

HTML规范确实定义了lang属性用于提示浏览器元素的内容语言，而spellcheck属性的行为依赖于这个语言值。但规范并没有强制要求浏览器必须实时响应lang属性的动态变更——它只规定了元素的语言应该用于拼写检查，却没有明确说明当语言属性在运行时改变时，拼写检查器必须立即切换词典。这种“实现细节”的留白，导致不同浏览器团队可以根据自己的架构和优先级来处理这个场景，这就是跨浏览器行为不一致的根源。

2. Chrome/Edge的行为是设计还是漏洞？ #

Chrome和Edge基于Chromium内核，它们的这个行为更偏向于未完善的功能缺口，而非有意的设计，也不是漏洞。

Chromium的拼写检查架构是在元素首次初始化（或首次获得焦点）时，就绑定了对应lang的词典，后续修改lang属性不会触发拼写检查器的重新初始化。早期这个设计可能是出于性能考虑——频繁切换词典会带来额外的资源开销，而且Chromium的拼写检查和系统输入法/词典集成较深，系统层面的词典切换逻辑本身就没有做实时响应的优化。

目前Chromium的issue tracker上有不少关于这个问题的反馈，团队也承认这是一个需要改进的点，但由于优先级和架构调整的成本，至今还没有正式修复。

3. 无需自定义拼写检查的变通方案 #

不用完全自己实现拼写检查功能，有几个可靠的原生方案可以解决这个问题：

方案一：替换textarea元素 #

当切换语言时，创建一个新的textarea元素，复制原元素的所有内容、属性和样式，然后替换掉旧元素。因为新元素初始化时会读取当前设置的lang属性，Chromium会加载对应的词典。

修改你的示例代码中的apply函数：

function apply() {
  if (this === pt && pt.checked) en.checked = false;
  if (this === en && en.checked) pt.checked = false;
  const newLang = pt.checked ? "pt-PT" : "en-GB";
  
  // 创建新的textarea
  const newTextarea = document.createElement('textarea');
  // 复制原元素的属性和样式
  newTextarea.id = t.id;
  newTextarea.spellcheck = t.spellcheck;
  newTextarea.style.cssText = t.style.cssText;
  newTextarea.lang = newLang;
  // 复制内容
  newTextarea.value = t.value;
  
  // 替换旧元素
  t.parentNode.replaceChild(newTextarea, t);
  // 更新引用
  t = newTextarea;
  
  // 重新绑定事件（如果需要）
  pt.addEventListener("change", apply);
  en.addEventListener("change", apply);
}

方案二：使用contenteditable元素替代textarea #

部分开发者反馈，contenteditable元素在Chromium中动态修改lang属性时，拼写检查器会响应变更。不过要注意contenteditable和textarea的行为差异（比如回车生成<br>或<p>标签、复制粘贴的格式处理等），需要根据你的业务场景调整。

最后你问到的“为什么Firefox能做到而其他不行”：这是因为不同浏览器的拼写检查实现架构不同。Firefox的拼写检查模块内置了对lang属性变更的监听逻辑，能够实时触发词典切换；而Chromium的架构从设计之初就没有考虑这个动态切换的场景，后续的优化优先级也没有排到最前面，导致了这种功能支持的差异。

内容的提问来源于stack exchange，提问作者Filipe Nóbrega