后端收不到字段八成是误用disabled而非readonly；disabled使字段值不提交，readonly则正常提交且支持聚焦复制；select等不支持readonly的元素需用替代方案。
后端收不到字段？八成是把 readonly 写成了 disabled。这不是样式问题，是表单数据是否进请求体的根本分水岭。
提交时值会不会发到后端
这是最致命的判断依据，直接决定用哪个属性。
-
disabled的控件：无论你用form.serialize()、new FormData(form)还是原生submit，它的name和value都不会出现在请求里——浏览器直接过滤掉，JS 改了value也白搭 -
readonly的控件：值照常提交，request.getParameter("id")或等价方式能拿到，适合预填 ID、订单号、计算结果等“只读但必传”场景 - 常见错误现象：
<input name="user_id" value="1001" disabled>提交后后端日志查无此字段；测试通过但上线报“缺少必传参数”，基本就是这原因
哪些元素支持 readonly
readonly 不是万能锁，它只对特定元素生效，硬加在不支持的标签上等于没写。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 有效：
<input type="text">、<input type="password">、<input type="email">、<textarea></textarea> - 无效（浏览器直接忽略）：
<select readonly></select>、<input type="checkbox" readonly>、<button readonly></button>、<input type="radio" readonly> - 替代方案：
<select></select>只读需求，改用<input readonly>文本模拟；checkbox/radio需“视觉只读但保留状态”，用disabled+ 同名<input type="hidden">补值
聚焦、复制、可访问性差异
用户能不能点进去、选中、复制，不是体验优化项，而是功能刚需。
-
readonly元素仍可focus()、Tab 切入、双击选中、Ctrl+A、Ctrl+C——展示 API Key、手机号、金额时必须用它 -
disabled元素：无法获得焦点（.focus()静默失败）、:focus伪类不触发、鼠标点击无响应、屏幕阅读器播报 “已禁用” 并跳过 - CSS 注意：
input[readonly]默认不灰化，建议手动加background-color: #f5f5f5; cursor: not-allowed;做视觉提示；而input:disabled浏览器自带置灰，但泛写可能破坏移动端 WebView 匹配
JS 动态控制的坑点
用脚本开关状态时，两个属性的行为不一致，容易埋下静默 bug。
- 设
disabled：安全写法是el.disabled = true或el.disabled = false - 设
readonly：老版 Safari 对el.readOnly = false响应迟钝，稳妥做法是el.removeAttribute('readonly') - 别同时写
readonly和disabled：disabled优先级更高，readonly形同虚设，不是“双重保险”，而是逻辑混淆 - 批量控制首选
<fieldset disabled></fieldset>：包裹一组控件，比逐个设disabled更健壮，语义更清晰，子控件显式写disabled="false"也无效
真正难调试的，是那些“看起来提交了、实际被浏览器过滤掉”的字段——它们往往藏在条件分支里，只在某个流程路径下被 JS 动态加上 disabled，而测试时恰好没走那条路。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
