customElements 不适合原型开发，因其需预注册、Shadow DOM 隔离样式、属性传值繁琐；原型应优先使用语义化原生标签（如 role、data-*、template）实现快速迭代与调试。
直接用 customElements.define() 注册自定义标签做原型，效率远不如纯语义化 HTML 标签快；真要快速搭原型，别碰 Web Components —— 它们适合封装、复用、长期维护，不适合“10 分钟出个可点可拖的 demo”。
为什么 customElements 不适合原型阶段
原型核心诉求是“改得快、看得清、传得走”，而自定义元素天然带三重延迟：
-
customElements.define()必须在 HTML 使用前执行，JS 加载顺序稍错就白屏或报DOMException: "x-foo" is not a valid custom element name - Shadow DOM 默认隔离样式，你写个
<my-card></my-card>，想临时加border: 1px solid red调试？根本不起作用，得进影子树里找 - 所有动态内容（比如用户头像、消息数）都得靠属性传入或 slot 分发，没法像
<div data-user-id="123">那样随手加个data-属性留接口
真正适合原型的“自定义标签”其实是语义化原生标签
所谓“自定义”，在原型期指的不是注册新标签名，而是用已有标签组合出业务含义 —— 这才是浏览器原生支持、零成本、可调试的方案：
- 用
<section role="profile">代替<my-profile>：role 提供语义，CSS 可直接选中section[role="profile"] - 用
<article data-status="draft">表示草稿状态，后续 JS 或后端渲染时按需读取dataset.status - 把按钮逻辑先写死：
<button type="button" onclick="alert('跳转到编辑页')">编辑</button>，比等attributeChangedCallback响应快十倍 - 需要“组件感”？用
<template id="card-template">存结构，document.getElementById('card-template').content.cloneNode(true)手动插入 —— 不注册、不监听、不封装，只复用 HTML 片段
什么时候该切到真正的 customElements
当原型验证通过、功能稳定、开始多人协作或需要跨项目复用时，才值得把高频模块升级为自定义元素。迁移路径很明确：
立即学习“前端免费学习笔记（深入）”；
- 从
<div class="date-picker">...</div>提炼出结构和行为，抽成class DatePicker extends HTMLElement - 把原来写在全局 CSS 里的
.date-picker input搬进 Shadow DOM 的<style>块里 - 用
observedAttributes监听value和min，但注意：首次渲染仍得在connectedCallback里手动读this.getAttribute('value')，因为attributeChangedCallback不触发初始值 - 注册名必须含短横线：
customElements.define('date-picker', DatePicker)，写成datepicker会直接抛错
原型阶段最常被忽略的一点：你写的每个 data- 属性、每个 role、每个 <template>，都是未来升级 customElements 的天然锚点 —— 不是重写，而是渐进增强。
