表单元素的 value 属性仅初始化时生效，JS 修改后需手动同步校验状态；placeholder 不能替代 label，须配合 aria-label 准确描述；type="number" 校验松散且移动端支持不稳定；disabled submit 按钮会阻止 submit 事件触发。
表单元素的 value 属性为什么没生效
value 属性只在初始化时起作用，后续 JS 修改 input.value 或 textarea.value 不会自动触发浏览器的“已填写”状态判断，比如 :valid 伪类、checkValidity() 结果、甚至某些框架（如 React）的受控逻辑都可能因此失效。
- 原生表单中，
value是初始值；运行时修改必须配合input/change事件手动同步校验状态 - 使用
document.getElementById("x").value = "new"后，form.checkValidity()仍可能返回false（如果之前校验失败过且未重置） - React 中直接改 DOM 的
value会导致受控组件警告：A component is changing an uncontrolled input to be controlled
placeholder 和 aria-label 混用导致可访问性问题
placeholder 不是标签替代品，屏幕阅读器通常不读它，也不能被键盘焦点定位；和 aria-label 同时存在时，部分读屏软件会忽略 placeholder，但若 aria-label 写得不准确，用户反而更难理解输入意图。
- 必填字段必须配
<label for="id"></label>，placeholder只作辅助提示（比如格式示例："YYYY-MM-DD"） -
aria-label适合无视觉label的场景（如搜索框图标按钮），但内容要完整，不能只写“搜索”，建议写成aria-label="站内搜索，支持关键词和作者名" - Chrome 117+ 开始对空
placeholder+ 缺失label的组合触发 Lighthouse 可访问性警告：Form elements do not have associated labels
type="number" 在移动端触发表单键盘却不校验小数点
type="number" 确实能唤起数字键盘，但它对 step、min、max 的校验是松散的——用户粘贴 "12.34.56" 或输入 "-." 都不会立刻报错，直到调用 reportValidity() 才触发。
- 移动端 Safari 对
type="number"支持不稳定，iOS 16 下可能 fallback 到文本键盘，尤其当inputmode="decimal"未显式设置时 - 想允许小数，必须设
step="0.01"（不能省略或写"any"，后者不被所有浏览器识别） - 后端永远要二次校验：前端
valueAsNumber可能返回NaN，而字符串值仍可能是非法格式
submit 按钮 disabled 后无法触发 submit 事件
给 button[type="submit"] 加 disabled 会阻止整个表单提交流程，包括 submit 事件监听器——不是“事件被拦截”，而是根本不会触发。
立即学习“前端免费学习笔记（深入）”；
- 需要防重复提交时，不要直接
btn.disabled = true，而是用event.preventDefault()+ 显式调用form.submit()，再禁用按钮 -
disabled元素的值不会包含在FormData中，哪怕它本该提交；若需保留字段，改用hidden输入或服务端幂等处理 - CSS 中
pointer-events: none不等于disabled，它不阻止表单提交，也不影响FormData，但破坏可访问性，别这么用
表单最麻烦的从来不是怎么写，而是「哪些状态变化该由 JS 主动同步」——比如 value、validity、touched、dirty，这些没有统一标准，不同框架处理逻辑差异很大，手写时很容易漏掉某一个环节。
