判断Web Component是否真正跨框架可用，需验证三要素：是否用composed: true发送事件、是否通过attachShadow({mode: 'open'})封装样式DOM、是否仅依赖原生属性而非框架props；常见失效表现为事件丢失、响应失灵、样式错位。
<details> 本身已是语义化、可访问、开箱即用的原生组件，直接套 Web Components 封装时最容易踩坑——不是“不能做”，而是多数场景下纯属多此一举；真要封装，核心目标应是：增强行为（如联动状态、表单集成）、统一样式隔离、或注入动态内容，而不是重造 <details> 的折叠逻辑。
为什么别在 constructor 里操作 <details> 的 open 属性
浏览器对 <details> 的 open 属性有原生响应机制，但该机制只在元素挂载后生效。如果你在自定义元素的 constructor 中写 this.querySelector('details').open = true，此时 DOM 尚未解析完成，querySelector 返回 null，或即使查到也因元素未 connected 而无效。
-
connectedCallback才是安全时机：确保<details>已渲染且可交互 - 不要手动调用
element.open = ...来模拟点击；优先用element.toggleAttribute('open')或触发click() - 若需初始状态由属性控制（如
<my-warning open>），应在attributeChangedCallback中监听'open'并同步到内部<details>
用 <slot> 分发内容时必须显式声明 name 才能精准投递
<details> 结构固定为 <summary> + 其余子内容。若你封装成 <my-details>，又希望用户能分别传入 summary 文本和 body 内容，仅靠默认 <slot> 会全部塞进 <details> 底层，破坏语义结构。
- 必须在模板中写两个具名
<slot name="summary">和<slot>（默认 slot） - 对应 HTML 使用：
<my-details><span slot="summary">标题</span><p>正文</p></my-details></li> <li>不声明 <code>name
的子节点会被丢弃——<my-details><h3>乱入</h3></my-details>中的<h3>不会渲染
attributeChangedCallback 监听 open 失效的三个硬性条件
你想让 <my-details open> 自动展开，但发现 attributeChangedCallback 根本不触发？问题大概率出在以下任一环节：
立即学习“前端免费学习笔记（深入）”；
- 没在类中声明
static get observedAttributes() { return ['open']; }—— 缺了这句，浏览器完全不通知 - HTML 写的是
<my-details OPEN>或<my-details Open>—— 属性名必须全小写，'open'≠'OPEN' - JS 侧执行了
el.open = true—— 这属于 property 赋值，不会触发 attribute 变更回调；要用el.setAttribute('open', '')或el.toggleAttribute('open')
表单场景下让 <my-details> 参与提交的关键动作
如果组件内含 <input type="checkbox"> 且希望它随父 <form> 一起提交，光渲染出来没用——浏览器根本不认它是表单控件。
- 类定义必须加
formAssociated: true选项，否则this.attachInternals()报错 -
constructor中调用this.internals = this.attachInternals() -
connectedCallback中监听内部<input>的input或change事件，并调用this.internals.setFormValue(this.input.value) - 内部
<input>必须透传name属性（this.input.name = this.getAttribute('name') || ''），否则form.elements查不到
真正难的从来不是怎么写，而是搞清哪些行为浏览器已代劳、哪些必须手动桥接——<details> 的折叠/键盘导航/焦点管理全是原生保底，Web Components 的价值在于补足它没管的部分，比如跨组件状态同步、主题变量注入、或 SSR 时的 hydrate 行为。别为了封装而封装。
