type="text"与type="password"本质区别在于语义与安全边界：前者明文显示、支持自动填充和字母键盘；后者掩码显示、禁用用户名联想、调起符号键盘，并需配合autocomplete属性明确意图。
type="text" 和 type="password" 的实际区别不只是显示方式
两者都用于单行文本输入，但 type="password" 不仅隐藏字符，还会禁用浏览器自动填充的「用户名」字段联想（除非显式声明 autocomplete="current-password"），而 type="text" 默认允许 autocomplete。在登录表单中混用时，如果把密码框写成 type="text"，即使加了 JS 掩码，也绕不过 DevTools 查看 DOM 的明文 value —— 这不是样式问题，是语义和安全边界问题。
常见错误：用 type="text" + CSS 遮盖实现“伪密码框”，或在注册页把确认密码也设为 type="password" 却没配 autocomplete="new-password"，导致 Chrome 自动填入旧密码。
- 必须用
type="password"处理真实密码，且搭配autocomplete="current-password"或autocomplete="new-password"明确意图 -
type="text"适合用户名、昵称、搜索关键词等无需掩码且需浏览器建议的场景 - 移动端下，
type="password"会默认调起数字/符号键盘，而type="text"调起字母键盘；如需数字键盘，应改用type="number"或inputmode="numeric"
radio 和 checkbox 的 name 属性决定分组逻辑
name 不是可选装饰，而是控制互斥/多选行为的核心开关。同一组 radio 必须共用 name，否则变成多个独立单选框；而 checkbox 的 name 相同，只是方便后端以数组形式接收（如 PHP 的 $_POST['hobby'] 是数组），并不影响勾选自由度。
容易踩的坑：复制粘贴 radio 代码时漏改 name，导致看似一组实则各自为政；或给 checkbox 加了相同 name 却没在 JS 中用 document.querySelectorAll('input[name="hobby"]:checked') 而不是 document.querySelector 取值，结果只拿到第一个。
-
radio必须配name才能实现“二选一”，checked属性仅控制默认选中，不改变分组规则 -
checkbox的name相同，提交时后端收到的是同名字段的多个值（取决于浏览器和编码），前端遍历时必须用 NodeList 而非单个元素 API - label 绑定推荐用
for+id，而非包裹写法，避免嵌套干扰事件冒泡或样式继承
file 类型上传前必须处理 multiple 和 accept
type="file" 默认只允许选一个文件，加 multiple 才支持 Ctrl+Click 或拖拽多选；但光加这个不够 —— accept 决定文件选择器弹窗里显示哪些类型（如 accept="image/*" 过滤出图片，accept=".pdf,.docx" 限定扩展名）。不设 accept，用户可能选到服务器根本不处理的格式，前端校验再严也只是补救。
另一个现实约束：iOS Safari 对 accept="image/*" 会强制打开相机，而 Android Chrome 仍显示文件选择器。如果业务只要拍照，得靠 capture="environment" 强制后置摄像头，但这属性在桌面端无效。
-
multiple是布尔属性，存在即生效，不用写multiple="true" -
accept值是逗号分隔的 MIME 类型或扩展名，注意.jpg和image/jpeg效果不同：前者依赖浏览器解析扩展名，后者更可靠但部分旧浏览器不支持 - 获取文件列表必须用
input.files（FileList 对象），不是value—— 后者只返回文件名（且被浏览器故意模糊化，如C:\fakepath\abc.jpg）
date、email、number 等 HTML5 类型不是万能验证器
这些类型确实能触发原生校验（如输入非数字时 type="number" 框变红），但它们只作用于表单提交时，且兼容性有限：IE 完全不支持 type="date"，Android 4.4 WebView 对 type="email" 的正则校验极松（比如 a@b 也能过）。更关键的是，它们不阻止用户用 JS 修改 value —— input.value = "xxx" 依然能绕过所有内置限制。
真正可靠的校验必须落在 JS 层：监听 input 或 blur 事件，用正则或 checkValidity() + setCustomValidity() 控制提示文案，而不是依赖 type 属性“自动搞定”。
-
type="email"只校验基础格式（含 @ 和域名），不验证邮箱是否真实存在 -
type="number"允许输入空格、e/E、+- 符号，1e2是合法值，但业务可能只要整数 -
type="date"在不支持的浏览器里降级为type="text"，此时 placeholder 提示（如YYYY-MM-DD）就是唯一引导
表单控件的 type 本质是语义声明，不是功能封装。浏览器按标准实现对应 UI 和基础校验，但业务逻辑层该做的判断一点不能少 —— 尤其是跨端兼容和 JS 动态操作时，DOM 状态和用户感知之间常有断层。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
