disabled的值不会发到后端，readonly的值会；readonly仅对text、password、email、textarea有效，select等不支持，禁用但需提交时应配合hidden字段。
readonly 和 disabled 提交时值会不会发到后端？
不会发 → 用 disabled；会发 → 用 readonly。这是最直接的判断依据，也是后端收不到字段时第一排查点。
常见错误现象：form.serialize() 或 new FormData(form) 里没有某个字段，但前端明明写了 value；检查发现该 input 被加了 disabled，而非 readonly。
使用场景：
- 用户 ID、订单号、预填邮箱等「展示+必须提交」→ 用
readonly - 协议未勾选时禁用提交按钮、条件未满足时锁死下拉框 → 用
disabled - 临时屏蔽整个区块（如“企业信息”组）→ 用
<fieldset disabled></fieldset>，比逐个加disabled更可靠
哪些控件支持 readonly？哪些不支持？
readonly 只对 <input type="text">、<input type="password">、<input type="email">、<textarea></textarea> 有效；其他一概忽略。
常见错误做法：
-
<select readonly></select>→ 浏览器完全无视，下拉仍可点开 -
<input type="checkbox" readonly>→ 无效，勾选状态无法锁定 -
<button readonly></button>→ 不起作用，按钮依然可点击
替代方案：
-
select只读需求：改用<input type="text" readonly>模拟，或 JS 禁用所有<option disabled></option> -
checkbox/radio需视觉只读但保留值：用disabled+ 隐藏域<input type="hidden" name="xxx" value="yyy">
JS 动态控制时 el.readOnly = false 为什么有时不生效？
因为 readonly 是布尔属性，但某些旧版 Safari 对 el.readOnly = false 响应迟钝；而 disabled 在所有主流浏览器中行为一致。
实操建议：
- 启用/禁用
disabled：直接写el.disabled = true或el.disabled = false - 启用
readonly：稳妥写法是el.removeAttribute('readonly')，而非赋值false - 避免同时写
readonly和disabled：后者优先级更高，前者被覆盖，容易掩盖逻辑问题
性能影响小，但可访问性影响大：disabled 元素会被屏幕阅读器跳过，readonly 仍可聚焦、可播报、可复制——这对视障用户是关键差异。
React/Vue 中绑定 readOnly 或 disabled 容易踩什么坑？
框架层面对属性名和类型更敏感，稍不注意就失效。
常见错误：
- React 中写
readonly={true}→ 错，必须用驼峰readOnly={true}；否则属性名不对，浏览器不识别 - Vue 中写
:readonly="true"→ 对input有效，但:readonly="true"绑定到select上毫无作用 - 受控组件中，
disabled后仍通过valueprop 更新，但用户无法编辑 → 表面正常，实际提交时字段消失
真正容易被忽略的是：表单验证库（如 Yup、Zod）默认校验 readonly 字段，但跳过 disabled 字段。如果你靠 disabled “隐藏”一个必填字段，验证可能意外通过。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
