textarea加readonly属性是最直接有效的方式，用户无法输入但可聚焦选中复制，且值会随表单提交；disabled则导致字段不提交，JS操作需用readOnly驼峰属性，CSS用:read-only伪类增强体验并辅以无障碍支持。
textarea 加 readonly 属性是最直接有效的方式
HTML 中的 <textarea></textarea> 原生支持 readonly 布尔属性，加了就生效，不需赋值。用户无法输入、粘贴或拖拽修改内容，但能聚焦、选中、复制文本，且它的 name 和 value 会随表单一起提交到后端。
✅ 正确写法：<textarea readonly>系统生成说明</textarea>
❌ 错误写法：<textarea readonly></textarea>（冗余）、<textarea readonly></textarea>（反而生效）
注意：readonly 对 <input type="checkbox"> 或 <input type="radio"> 无效，但 <textarea></textarea> 完全适用。
为什么不用 disabled？它会让字段“消失”在提交数据里
如果给 <textarea></textarea> 加 disabled，视觉上会变灰、不可聚焦、不能复制，但最关键的是：它的值不会出现在 FormData、form.serialize() 或原生表单提交中——后端根本收不到这个字段。
常见踩坑场景：
立即学习“前端免费学习笔记（深入）”；
- 订单详情页回显“客户备注”，运营要求必须随订单一起存库 → 必须用
readonly - 审批流中显示“上一环节意见”，只是展示，无需提交 →
disabled可接受 - 用了
disabled却发现接口报错“missing field”，翻半天才发现字段没传
动态控制只读状态得用 JavaScript 的 readOnly 属性
JS 操作时，必须用驼峰命名的 readOnly（不是小写的 readonly），这是 DOM 属性名，和 HTML 属性名大小写不一致：
✅ 正确：textareaEl.readOnly = true、textareaEl.readOnly = false
❌ 错误：textareaEl.readonly = true（部分浏览器不认）、textareaEl.setAttribute('readonly', 'true')（兼容性差，且移除时需 removeAttribute 才可靠）
检查状态也应统一用：if (textareaEl.readOnly)，而不是 hasAttribute('readonly')，后者可能因 JS 修改滞后而返回错误结果。
:read-only 伪类是样式区分的关键，但别只靠颜色
浏览器对 readonly 元素默认无视觉反馈，用户点进去才发现不能输，体验断层。用 CSS :read-only 伪类精准命中：
textarea:read-only { background-color: #f5f5f5; border-color: #ccc; cursor: not-allowed; }
重点提醒：
- 别只改背景色——色觉障碍用户看不到区别，
cursor: not-allowed或cursor: default是刚需 - 移动端 Safari 对
:read-only支持良好（2026 年已全覆盖），但旧版 Android WebView 可能不支持，可 fallback 到 class 切换 - 加上
aria-readonly="true"，让屏幕阅读器明确感知只读语义
真正容易被忽略的是：readonly 不防 JS 修改，也不代表后端可信任——它只是前端交互限制。值是否合法、是否允许被覆盖，必须由后端做最终校验和白名单控制。
