直接用customelements.define在多个应用注册会冲突，因页面仅有一个全局customelementregistry，重复define同名元素抛domexception；需先check customelements.get()再注册，并配formassociated: true与attachinternals()实现表单互通。
跨应用组件库不是靠“打包发布”就能跑通的，核心卡点在于样式隔离、事件穿透、表单集成和生命周期一致性——这些必须在自定义元素层做硬约束，而不是靠构建工具或运行时补丁。
为什么直接用 customElements.define 在多个应用里注册会冲突
同一个自定义标签名（如 my-input）被不同应用重复调用 customElements.define 时，第二次会抛 DOMException: Failed to execute 'define' on 'CustomElementRegistry': the name "my-input" has already been used with this registry。这不是 bug，是规范强制行为。
- 每个页面只有一个
customElements全局注册表，无法按应用分 namespace - 微前端场景下，子应用独立加载 JS，很可能各自执行 define，导致报错或静默覆盖
- React/Vue 等框架的组件懒加载 + 按需注册，和自定义元素的全局注册模型天然不匹配
解决方案不是“加 try/catch”，而是提前检查并跳过：
if (!customElements.get('my-input')) {
customElements.define('my-input', MyInput, { formAssociated: true });
}
formAssociated: true 是跨应用表单互通的前提，但必须配对使用 attachInternals()
很多团队封装了 <my-select></my-select> 却发现提交时 FormData 里没有值——根本原因不是没监听 change，而是漏了 formAssociated: true 这个注册选项，导致 this.attachInternals() 直接报错或返回 undefined。
-
formAssociated: true必须显式传入customElements.define()的第三个参数，不能靠属性或构造函数推断 -
this.attachInternals()只能在constructor中调用一次，且必须在 super() 之后 - 如果组件内部用了 Shadow DOM，
setFormValue()的触发时机必须绑定到内部<input>的input或change事件，不能只靠外部 props 更新
Shadow DOM 样式隔离 ≠ 自动适配所有主题，:host 和 part 才是关键
光用 attachShadow({ mode: 'open' }) 只能防止样式泄漏，但没法让组件响应外部主题切换（比如 dark mode class 切换）。用户改了 ，你的 <my-button></my-button> 依然白底黑字。
- 必须用
:host(.dark) > button这类选择器主动监听宿主类变化 - 对外暴露可定制部分要用
part="label"+::part(label)，而不是靠 CSS 变量兜底（变量无法穿透 Shadow DOM 边界） - 不要在 Shadow DOM 内写
@media (prefers-color-scheme: dark)，它不响应系统级主题切换，只响应初始加载状态
跨应用通信不能依赖全局事件，CustomEvent + composed: true 是唯一可靠路径
子应用发的 dispatchEvent(new CustomEvent('submit-success')) 默认不会冒泡出 Shadow DOM，父应用监听不到。
- 必须设
composed: true，否则事件止步于 Shadow DOM 边界 - 避免用
document.dispatchEvent，它绕过组件边界，容易引发命名冲突和调试困难 - 事件 payload 里别传 function 或 DOM 节点，跨应用环境可能序列化失败或权限拒绝
真正难的不是写一个能跑的组件，而是让它的表单值、样式响应、事件流在不同框架、不同构建配置、不同加载时机下保持一致——这些细节一旦漏掉，跨应用复用就变成维护噩梦。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
