disabled属性使字段既不可编辑也不参与表单提交;readonly仅禁输入但仍提交。所有disabled表单控件均被FormData等自动忽略,服务端不可依赖其“缺失”做安全校验。

disabled 属性会让字段既禁用又不出现在表单提交数据中
直接给 加 disabled 属性,浏览器就会跳过它——既不可编辑,也不会被序列化进 FormData、URLSearchParams 或原生表单提交的键值对里。这是 HTML 原生行为,无需额外 JS 干预。
常见错误是混淆 disabled 和 readonly:readonly 只禁输入,但字段仍参与表单提交;而 disabled 才真正“消失”于提交数据中。
-
→ 提交时完全不包含user_id -
→ 提交时仍含user_id=123 - 所有
disabled元素(、、)都遵循同一规则
disabled 字段在 JavaScript 中不会被 FormData.append() 自动收集
即使你手动创建 FormData 并传入表单元素,disabled 的 依然被忽略。这是规范强制行为,不是 bug。
例如:
const form = document.querySelector('form');
const fd = new FormData(form); // 自动过滤掉所有 disabled 字段
如果你曾试图用 form.querySelectorAll('input') 遍历后手动 append,却漏掉了 :not([disabled]) 过滤,就可能意外带上本该排除的值——务必检查选择器逻辑。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML,微信编辑器可直接渲染,无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 用
form.elements或form.querySelectorAll('input:not([disabled])')确保只处理可用字段 -
fd.getAll('field_name')返回空数组,说明该字段确实未被收录(可用于调试) - 注意:动态增删
disabled属性后,需重新构造FormData,它不响应 DOM 变更
服务端不能依赖 disabled 字段“不存在”来校验安全性
前端禁用只是体验层控制,攻击者可轻易移除 disabled 属性或直接发请求。如果某个字段本就不该由用户提交(如 admin_flag),服务端必须做两件事:
- 明确不从请求体中读取该字段(比如 Express 中不调用
req.body.admin_flag) - 若逻辑上需要默认值或上下文推导,应由服务端注入,而非信任客户端是否“没发”
- 尤其警惕隐藏字段 + disabled 组合:
—— 它照样能被篡改并提交
替代方案:用 hidden input + JS 控制可见性,而非 disabled
当你要“视觉上禁用但保留数据”,比如展示只读 ID 同时确保它进提交数据,disabled 就不合适。此时应:
- 保留原字段为
readonly+tabindex="-1"+ CSS 禁用样式(如pointer-events: none; opacity: 0.6;) - 另加一个同名
存真实值,并确保它没被disabled - 避免在同一个
name下混用disabled和非disabled字段,否则提交行为不确定(多数浏览器以第一个为准,但不可靠)
真正要排除字段,就干净利落地用 disabled;想保留但不让改,就得换思路,别硬拗它的语义。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!










