Web Components 中 input 的 type 属性不继承父组件约束，其行为完全由浏览器原生实现决定；value 始终为字符串，需手动转换；min/max 等属性需显式透传，且依赖 type 兼容性；iOS Safari 对 type 约束支持不稳定，须 JS 补充校验。
Web Components 中 input 元素的 type 属性不继承父组件约束
你在自定义元素里写 ，它就只是个原生 input，不会因为包在 input 的实现决定，和 Web Component 的封装无关。
常见错误现象：以为在自定义组件中设置 type="number" 后，value 属性会自动转成数字——其实不会，input.value 永远是字符串（哪怕用户只输了 42）；想拿数字得手动 parseFloat(input.value) 或用 input.valueAsNumber。
-
type="number"仅影响键盘弹出、基础格式拦截（如 iOS 不让输字母）、以及validity校验逻辑（如rangeUnderflow） -
type="email"或type="url"不会自动解析或标准化值，只做最粗粒度语法检查（比如foo@通不过，foo@bar却可能通过） - 如果你在 Shadow DOM 里用
，min/max/step 约束依然生效，但日期格式（YYYY-MM-DD）必须严格，写成2026/06/02就被忽略
attributeChangedCallback 无法直接映射 type 相关约束
你不能靠监听 type 属性变化来“激活” min/max/pattern——这些属性本身是原生 input 的，不是自定义组件的公开接口。如果你把 min 写在 input，除非你手动做映射。
正确做法是显式同步关键属性：
- 在
observedAttributes里声明['min', 'max', 'step', 'pattern', 'required'] - 在
attributeChangedCallback中判断 name，然后执行this._input.setAttribute(name, newValue) - 特别注意：
min和max对type="text"无效，所以必须确保内部input的type已设为兼容类型（如"number"或"date"），否则设置白搭
自定义组件暴露的属性类型必须与原生语义对齐
用户传 input.value，没问题；但若用户传 value="abc"，而你的组件又宣称支持 type="number"，那这个 value 属性的“类型契约”就崩了——它看起来像数字输入，却接受任意字符串。
更稳妥的做法是：在 set value() 中做守卫：
- 若组件逻辑绑定到
type="number"，则set value(v)应尝试parseFloat(v)，失败时可清空或 fallback 到0，并同步更新input.value - 不要依赖
input.valueAsNumber来反向推导合法值——它对空字符串返回NaN，对非法字符串也返回NaN，无法区分“用户还没输”和“输错了” - 对外暴露的
valuegetter 应始终返回与type语义一致的类型（如 number 类型组件返回number或null，而非字符串）
移动端 iOS Safari 的 type 行为差异必须手动兜底
iOS Safari 对 type="number" 的 min/max 支持极不稳定：输入框能手动敲出 -5 即使 min="0"，且不触发 validity.rangeUnderflow，直到 blur 才校验。这意味着仅靠原生约束，在 iOS 上几乎不可信。
必须加一层 JS 防御：
- 在
blur事件中读取input.valueAsNumber，与parseFloat(input.min)比较，超界则强制重置 - 避免用
input.value ——因为两者都是字符串，"10" 会返回true - 对
type="date"，iOS 可能允许粘贴非法格式（如02/30/2026），此时input.value是空字符串，input.valueAsDate是null，需单独处理
复杂点在于：type 约束不是开关，而是分层漏斗——键盘适配、输入过滤、失焦校验、提交拦截，每层都可能失效。别让它成为你唯一防线。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
