readonly 属性的 textarea 仍可提交，因其仅阻止用户输入但不剔除于表单序列化；disabled 则彻底排除在提交之外；contenteditable 元素必须设 contenteditable="false" 才真正禁用编辑。
textarea readonly 属性为什么值还能提交
因为 readonly 是 HTML 层面的只读约束，不参与表单序列化逻辑的剔除——它只阻止用户输入，但保留字段在 form.submit() 或 FormData.append() 中的可见性。只要 name 存在、元素未被 disabled，它的 value 就会被提交。
常见错误现象：后端收不到 textarea 值，结果发现前端误用了 disabled；或者用了 readonly 却没设 name，导致提交时字段名丢失。
-
readonly元素仍可focus()、支持select()、触发focus和input事件（只是不更新值） - JS 仍能直接赋值：
el.value = 'new content'，readonly不拦截脚本修改 - 若需视觉灰化，得手动加 CSS：
textarea[readonly] { background: #f5f5f5; cursor: not-allowed; }
textarea disabled 属性为什么后端收不到数据
disabled 的本质是让元素退出表单控件集合——浏览器在构造 FormData 或序列化 form 时，会跳过所有 disabled 元素，无论你 JS 里有没有改过它的 value。
典型误用场景：想“禁用编辑但保留提交”，却只加了 disabled；或 React/Vue 中绑定 :disabled="isLocked" 后忘了同步维护隐藏字段。
立即学习“前端免费学习笔记（深入）”；
-
disabled元素无法获得焦点，el.focus()静默失败，tabindex失效 - 键盘事件（包括
paste、enter）全部被拦截，连input事件都不触发 - 若必须“禁用但提交”，得配一个同名
<input type="hidden">，并在 JS 中保持两者值同步
contenteditable 的 textarea 怎么真正锁住
原生 textarea 支持 readonly 和 disabled，但富文本容器（如 div[contenteditable="true"]）完全不响应这两个属性。靠 pointer-events: none 或 user-select: none 只能防鼠标，无法阻止键盘粘贴、回车换行等编辑行为。
正确做法只有一条：contenteditable="false"。移除该属性或设为 false 才算真正关闭编辑能力。
- 动态切换时，直接操作 DOM：
el.contentEditable = 'false'（注意字符串值，不是布尔） - 不要依赖 CSS 遮罩——它对键盘输入无效，且 screen reader 可能误读为可交互
- 某些编辑器（如 HTMEditor）会替换原始
textarea，此时要操作其外层容器，而非原始元素
React/Vue 中绑定只读状态容易踩的坑
框架语法糖掩盖了底层差异，导致语义错配。Vue 写 :readonly="true" 对 <select></select> 无效；React 必须用 readOnly（驼峰），写成 readonly={true} 会变成字符串属性，浏览器当成真值处理。
更隐蔽的问题：表单验证库（如 Yup）默认校验 readonly 字段，但跳过 disabled 字段——如果你靠 disabled “绕过校验”，实际可能漏掉业务规则。
- Vue 中：
<input :readonly="isViewOnly">✅，但<select :readonly="true"></select>❌（无效） - React 中：
<textarea readOnly={isViewOnly} />✅，<textarea readonly={isViewOnly} />❌（属性名错误） - SSR 场景下，服务端渲染
disabled，客户端 JS 没同步 hidden 字段，就会造成提交数据缺失
contenteditable 元素的只读控制——它根本不吃 readonly，也不吃 disabled，必须显式设 contenteditable="false"。其他都还好调，这个一旦忘了，用户点两下就又可编辑了。 
