is属性在复杂前端业务组件复用中几乎不可靠，它仅是原生HTML解析阶段的硬编码机制，不响应属性变更、不支持SSR降级、无法动态插值，且调试静默失败；真正可行的是class+data-注册、自定义元素属性监听、函数式组件桥接三种显式可控方案。
直接说结论：is 属性在复杂前端业务组件复用中几乎不可靠，它不是“复用方案”，而是极窄场景下的原生能力透出机制；真要复用，得绕开它，用更可控、可调试、可降级的方式。
为什么is不能当业务组件复用手段
is 的设计目标从来不是“让按钮变智能”，而是“让 <button> 保留表单语义的同时加载自定义行为”。它被浏览器硬编码在 HTML 解析阶段，一旦解析完成就不可更改，也不响应属性变更——这意味着你没法用它做状态切换、A/B 测试、灰度发布或运行时配置。
- 写
<button is="async-button" data-mode="retry">，但data-mode改了，is不会触发重实例化，你的类里也收不到通知 - 服务端渲染时
is="loading-button"，客户端 JS 加载失败？那它就是个普通按钮，没有任何 fallback 行为定义 - 想在 Vue/React 里动态插值
is值？不行。框架会把is当作普通 attribute 渲染，但浏览器只在首次解析时认它 - 团队协作中，有人写了
<div is="card">—— 浏览器静默忽略，控制台无报错，排查成本远高于写错 class 名
真正能落地的三个替代路径
核心原则：放弃“升级原生标签”的幻想，改用显式、可组合、可拦截的封装层。
-
基于
class+data-的轻量注册机制：用class="js-button"标记可增强区域，再由统一入口扫描并初始化对应逻辑（如data-button-type="confirm"→ 调ConfirmButton.init(el)）。好处是 SSR 友好、支持多次调用、可加 loading 状态 class 控制 UI，且不依赖 Custom Elements 生命周期 -
自定义元素（autonomous）+ 属性监听：写
<smart-button mode="async">，在attributeChangedCallback里响应mode、disabled等变化。它不复用原生按钮的表单能力，但你能完全掌控所有状态流转和 DOM 更新时机，适合复杂表单流 -
函数式组件桥接（React/Vue 场景）：把业务逻辑抽成纯函数（如
createButtonProps(config)），在模板里直接展开：<button {...createButtonProps(props)}>。避免任何“隐式升级”，所有行为都来自明确的 props 驱动
is 唯一值得保留的使用场景
仅限于：你明确需要原生 <button> 的全部内置行为（form 关联、disabled 同步、键盘导航、可访问性语义），且该组件生命周期极简单（构造即完成，无后续状态更新），同时部署环境能确保 customElements.define() 在 HTML 解析前执行。
立即学习“前端免费学习笔记（深入）”；
- 典型例子：CMS 输出页中一个带主题色的提交按钮，不参与 JS 交互流程，只靠
disabled和form自动提交 - 必须检查三项：
<button is="theme-button">中的button在规范白名单里；customElements.define("theme-button", ThemeButton, { extends: "button" })的extends不能漏；ThemeButton类首行是super() - 别把它和
data-混用：不要写<button is="theme-button" data-theme="dark">再在类里读this.dataset.theme—— 构造时dataset还没映射，得用this.getAttribute("data-theme")
最常被忽略的一点：当你在调试控制台看到 el.constructor.name === "HTMLButtonElement"，哪怕 HTML 里写了 is="my-btn"，也说明 extends 没配对、注册晚了、或者类没继承正确——而浏览器不会告诉你哪里错了，只会安静地退化。
