应使用标准<template id="validation-tpl">定义验证逻辑骨架，通过cloneNode(true)复用纯净DOM片段，验证函数只返回{valid, message}数据对象，渲染与逻辑解耦。
用 <template> 定义验证逻辑骨架，不渲染、不执行
直接把验证规则和错误提示结构写进 <template id="validation-tpl"> 里，它不会出现在页面 DOM 中，也不会触发脚本或样式加载。这是安全复用的前提 —— 避免重复解析、避免副作用。
常见错误是把验证逻辑硬编码在组件类里，导致每次实例化都要重新构造 DOM 片段；或者误用 <script type="text/template">，浏览器不识别该类型，content 取不到。
- 必须用标准
<template>标签，且带id属性（方便后续getElementById获取） - 内部可包含占位元素，比如
<span class="error" data-field="email"></span>，后续靠data-属性定位绑定 - 不要在里面写
<script>或<style>—— 它们不会执行，也不该由模板承担样式或行为职责
用 cloneNode(true) 拷贝模板，再注入动态验证状态
调用 document.getElementById('validation-tpl').content.cloneNode(true) 得到一个纯净的 DocumentFragment，它不含事件监听器、无全局作用域污染，适合反复挂载。
容易踩的坑：用 innerHTML 直接拼字符串插入验证信息，会丢失原有节点引用，导致后续无法精准更新某字段错误；或用 appendChild 原始节点，造成节点被移走、重复使用时报错 Failed to execute 'appendChild' on 'Node': The node you are trying to append is already in the DOM。
立即学习“前端免费学习笔记（深入）”；
- 每次验证失败时，只更新对应
data-field的textContent，不重建整个片段 - 成功时清空错误提示，但保留 DOM 结构，避免反复克隆开销
- 若需支持多语言，建议把错误文案存在
Map或Object中，按field + ruleType键查，而非塞进模板 HTML 里
配合 checkValidity() 和 setCustomValidity() 接入原生验证流
封装组件不是绕过浏览器原生验证，而是增强它。所有 <input> 仍应保留 required、pattern 等属性，让 form.checkValidity() 能统一判断，同时用 setCustomValidity() 注入自定义错误，保持原生提示样式和交互一致性。
典型误区是完全抛弃原生验证，自己从头实现“是否为空”“是否匹配正则”，结果导致 :valid/:invalid 伪类失效、无障碍支持退化、移动端键盘类型切换异常。
- 监听
input或blur事件，在回调中调用el.checkValidity()判断单个字段 - 验证失败时调用
el.setCustomValidity('邮箱格式错误')，成功时调用el.setCustomValidity('') - 表单提交前统一调用
form.reportValidity()触发所有字段校验并显示提示
验证逻辑与 DOM 渲染解耦，靠数据驱动更新
组件内部不应直接操作 shadowRoot 或父容器里的错误提示节点 —— 那会让组件强依赖挂载位置。正确做法是把验证状态抽象为纯数据对象，例如 { email: { valid: false, message: '请输入有效邮箱' } }，再由一个独立的渲染函数决定怎么展示。
很多封装失败的案例，是把“显示错误”逻辑和“执行验证”逻辑混在同一方法里，导致无法复用于不同 UI 框架（比如 Element Plus 的 el-form-item 和原生 div 布局需要不同插入方式）。
- 验证函数只返回
{ valid: boolean, message: string | null }，不碰 DOM - 提供
renderErrors(errors)方法，接收上述对象，由使用者决定插入位置（如afterend、insertAdjacentElement或 slot 分发） - 若用 Custom Elements，可在
attributeChangedCallback中响应data-validate属性变更，触发重验，而非监听 input 事件
