最常用且易错的方式是直接读取 value 属性，需注意 DOM 未加载、误用 innerText、忽略 disabled 状态、元素不存在等问题；推荐 form.elements 批量获取并校验 name 和 type。
直接读取 value 属性是最常用也最容易出错的方式
绝大多数时候，你只需要写 document.getElementById('xxx').value 就能拿到用户当前输入的字符串。但这个“简单”背后藏着几个高频翻车点：
- 脚本执行太早：DOM 还没加载完就查元素，
document.getElementById('xxx')返回null，再链式调用.value就报Cannot read property 'value' of null - 用了
innerText或textContent：这两个对<input>完全无效，它们只读标签内的文本节点，而输入框的值存在value属性里 - 忘了检查
disabled状态：被禁用的控件虽然有value，但它的值不会参与表单提交，且有些 UI 逻辑会跳过它——得提前判断el.disabled === false - 没确认元素是否存在：尤其在动态渲染或条件展示的表单里，
getElementById可能返回null，建议加一层存在性校验，比如if (el) { ... }
form.elements 是批量获取表单值最稳的原生方案
当你面对登录页、搜索栏这类字段多的表单，一个个 getElementById 不仅啰嗦，还容易漏掉新字段。form.elements 天然按 HTML 顺序返回所有可提交控件（<input>、<select>、<textarea>），而且自动跳过 disabled 的项。
- 必须确保每个控件都有
name属性，否则它不会出现在form.elements里——只靠id没用 -
form.elements返回的是HTMLFormControlsCollection，支持for...of和索引访问，比如form.elements[0]或form.elements['email'] - 注意
type="hidden"也会被包含进来，如果业务不需要，得手动过滤：if (el.name && !el.disabled && el.type !== 'hidden') - 对
checkbox和radio，不能直接读value，得先判断el.checked是否为true，否则拿到的是默认值而非用户选择
监听 input、change、blur 要看你要什么时机
不是所有场景都需要实时响应，选错事件会导致性能浪费或体验断层：
-
input：每敲一个字、删一个字、粘贴一次都触发，适合实时校验、搜索建议。但注意中文输入法下，未完成的拼音组合也会触发，可能需要防抖 -
change：只在控件失去焦点（blur）且值确实发生改变时才触发，适合最终确认类操作，比如修改密码后提示“已更新” -
blur：单纯失焦就触发，不管值变没变。适合做字段级离开校验，比如邮箱格式检查，但别用来取最终值——用户可能改完又切走，还没来得及输完 - 别在
submit事件里只依赖这些监听结果：用户可能全程没动过键盘（比如粘贴+回车），所以最终提交前仍要重新读一遍value
用 querySelector 定位时，name 和 type 组合比纯 id 更可靠
当页面结构复杂、ID 不唯一或由框架动态生成时，querySelector 提供了更灵活的定位能力，但容易忽略类型差异：
立即学习“前端免费学习笔记（深入）”；
- 读
input[type="checkbox"]或input[type="radio"]的值，必须先判断el.checked，再取el.value；否则拿到的永远是 HTML 里写的默认value，不是用户是否勾选 -
textarea和select同样用.value，但select的多选需配合el.selectedOptions遍历，不能只靠value（单选时它返回第一个选中项的value，多选时行为不一致） - 用
document.querySelector('input[name="phone"]')比getElementById更适应组件化开发，但要注意它只返回第一个匹配项，多个同名控件得用querySelectorAll+ 循环 - 如果 selector 匹配不到元素，
querySelector返回null，不抛错，容易静默失败——务必加空值判断
input 事件、多语言环境下 value 的编码表现、或者表单嵌套在 Shadow DOM 里时的跨边界访问——这些细节不踩一遍坑，很难意识到基础 API 背后有多少隐含契约。 
