是。fieldset disabled 会使内部原生表单控件的 checkvalidity() 一律返回 true，因其被浏览器视为不参与验证流程，即使有 required 或 pattern 也跳过校验。
fieldset disabled 会让 checkValidity() 返回 true 吗？
不会。只要 fieldset 带 disabled 属性，其内部所有原生表单控件（input、select、textarea 等）在调用 checkValidity() 时**一律返回 true**，哪怕它们本身有 required 或 pattern 校验规则。
这是因为浏览器将禁用控件视为“不参与验证流程”——它既不触发验证，也不计入验证失败统计。你调用 form.checkValidity() 时，这些控件被直接跳过，就像它们根本不存在一样。
- 即使
input有required且为空，input.checkValidity()仍返回true -
form.reportValidity()不会为这些控件弹出错误提示 - 但要注意：
form.elements里依然包含它们，只是验证逻辑绕过了
disabled fieldset 内的 input.value 还能读取吗？
能读，但值不会提交。禁用只影响交互与提交行为，不抹除 DOM 属性或 JS 可访问性。
你可以安全地执行 input.value、select.selectedIndex、textarea.textContent 等操作，拿到当前值；但如果用 new FormData(form) 或 form.submit()，这些字段**完全不会出现在请求体中**。
- 这个行为和单个
input disabled一致，不是 bug，是规范要求 - 如果业务需要“保留值 + 禁止编辑 + 提交”，必须改用
readonly+ CSS 禁用指针 + 移除tabindex，而非disabled - 动态启用时，记得检查是否要重置
value（比如用户之前手动改过 DOM，但没走事件流）
JS 绑定的事件还会触发吗？
会，只要没显式检查禁用状态。禁用只拦截原生交互（focus、click、input、change），不阻止 JavaScript 事件监听器执行。
-
input.addEventListener('input', handler)—— 若用户用 JS 触发input.dispatchEvent(new Event('input'))，handler 仍会运行 -
button.onclick = () => {...}—— 如果 JS 主动调用button.click()，函数照常执行 - 真正可靠的判断方式是：在事件处理器开头加
if (this.closest('fieldset[disabled]')) return;或检查this.form?.closest('fieldset[disabled]') - 别依赖
:disabled伪类做 JS 判断，它对继承禁用的子元素不总是返回true（尤其旧 Safari）；用el.matches(':disabled')更稳妥
为什么 form.checkValidity() 有时返回 false？
说明有**未被禁用的控件**触发了校验失败。常见漏点：
-
legend里的input—— 它完全不受父fieldset disabled影响，若带required且为空，就会让整个表单校验失败 - 自定义组件（如
<my-input></my-input>）没透传disabled，内部原生input实际仍可用，且参与校验 - 某个
input显式写了disabled="false"—— 这不会解除禁用，但可能干扰某些框架的响应式判断，导致校验逻辑误判 - 嵌套
fieldset：外层禁用，内层又写了个<fieldset></fieldset>（无disabled），它的子控件**不会恢复可用**，但若内层fieldset被 JS 动态移除了disabled属性，就可能意外激活
最省事的排查方式：打开控制台，执行 [...form.elements].filter(el => !el.disabled && !el.matches(':disabled')).forEach(el => console.log(el))，找出那些“看似禁用实则活跃”的元素。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
