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