readonly和disabled语义、行为、适用范围完全不同：disabled彻底禁用交互且不提交值，readonly仅禁止编辑但允许聚焦、复制和提交。
readonly 和 disabled 不是“差不多”，而是语义、行为、适用范围全都不一样；选错会导致值没提交、交互没拦截、可访问性出问题，甚至被用户绕过。
disabled 会让表单元素彻底退出交互流程
加了 disabled 的 <input>、<select></select>、<button></button> 等，会同时发生三件事：不能聚焦（Tab 键跳过）、不响应任何鼠标/键盘事件、提交时 完全不包含该字段的值（FormData、form.serialize()、原生 submit 都跳过）。
-
<input type="text" value="123" disabled>→ 提交后后端收不到name=123 -
<select disabled><option value="a">A</option></select>→ 用户点不开，选不了，也传不出值 -
<input type="checkbox" disabled checked>→ 勾选状态仍可读（el.checked返回true），但用户无法点击切换，提交时也不包含该字段 - 用 JS 动态控制必须写
el.disabled = true或el.disabled = false，别用setAttribute('disabled', '')—— 后者在旧版 IE 下可能不重绘状态
readonly 只锁编辑，不锁其他一切
readonly 仅对 <input type="text">、<input type="password">、<input type="email"> 等文本类输入框，以及 <textarea></textarea> 有效；它允许聚焦、允许复制、允许选中、允许提交值，只是不让用户改内容。
-
<input type="text" value="ID-789" readonly>→ 用户能 Tab 进去、Ctrl+A 全选、Ctrl+C 复制、提交时照样带上ID-789 -
<select readonly></select>或<input type="checkbox" readonly>→ 完全无效，浏览器直接忽略该属性 - 视觉上通常没变化（不会自动变灰），得靠 CSS 额外加
opacity: 0.6或background: #eee才像“禁用” - 如果字段本应不可改但又必须提交（比如预填的用户 ID），就该用
readonly；若连查看和复制都不允许，就得换disabled或配合display: none
fieldset 上设 disabled 是批量禁用的正确姿势
想一次性禁用一组控件（比如“企业信息”区块），别一个个加 disabled，直接用 <fieldset disabled></fieldset> 包裹：
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
立即学习“前端免费学习笔记（深入）”；
<fieldset disabled> <input name="company" value="ABC"> <select name="industry"><option>IT</option></select> <textarea name="desc">...</textarea> </fieldset>
- 内部所有支持
disabled的子控件（input、select、textarea、button）都会被递归禁用 - 子控件即使显式写了
disabled="false"也没用——fieldset的禁用优先级更高 -
<legend></legend>文本不受影响，仍可读、可聚焦，这对屏幕阅读器是友好设计，不是 bug - 注意：
<form></form>标签本身不支持disabled，fieldset是最接近“禁用整个表单”的原生方案
JS 动态控制时最容易忽略的三个细节
用 JS 开关禁用状态很常见，但以下三点一漏就出问题：
- 禁用当前聚焦元素后，焦点不会自动移走，键盘操作可能卡住 —— 建议紧接着调
nextFocusableEl.focus() - 禁用带
required的字段时，HTML5 表单验证会跳过它，但如果之前已触发过checkValidity()，错误提示可能残留；建议禁用后顺手调一次el.reportValidity()清理 UI 状态 - 在 Vue/React 中，只改 DOM 的
.disabled属性，不更新响应式数据或 state，下次 re-render 会把你的禁用状态覆盖掉 —— 必须同步更新绑定的数据源
真正要防止用户提交脏数据，前端禁用只是体验层辅助；后端必须做字段权限校验和值合法性判断，这点不能妥协。
