textarea禁用文本选择的唯一可靠方法是添加readonly属性并配合视觉降级，而非依赖user-select等CSS属性；批量操作时应基于复选框状态精准定位选中行内的textarea进行控制。
表格里选中的行，怎么让里面的 textarea 真正禁用文本选择？
直接给 tr 或 table 加 user-select: none 没用，因为该 CSS 属性不继承，且对原生表单控件（包括 textarea）完全无效。你看到的“可拖选文字”，其实是浏览器对 textarea 的默认行为，CSS 无法覆盖。
textarea 在表格中禁选的唯一可靠路径是语义化控制
别试图用 user-select、pointer-events: none 或 contenteditable="false" —— 这些要么无效，要么会破坏聚焦、光标定位或键盘输入。正确做法只有一条：用 HTML 原生语义配合视觉反馈。
- 加
readonly属性：<textarea readonly>只读内容</textarea>，它既阻止编辑，也自然剥夺文本选择焦点 - 配视觉降级：
background: #f5f5f5; cursor: default;，让用户一眼识别不可编辑 - 若需保留值但禁用交互，绝不能用
disabled——否则该字段值不会随表单提交；readonly才是语义正确且可提交的方案 - 不要用
pointer-events: none：它会让textarea失去所有交互能力，包括 Tab 切换、点击聚焦、甚至 Ctrl+A 全选（即使你没想禁这个）
批量操作时，如何动态给多行 textarea 加 readonly？
关键不是“怎么加样式”，而是“怎么精准作用于当前选中行”。常见错误是遍历 tr 后统一找 textarea，结果误伤未选中的行，或漏掉嵌套在 td 深层结构里的控件。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 先明确选中状态来源：用复选框的
checked状态驱动，而不是 DOM 位置或索引（分页/过滤后顺序会变） - 推荐写法：
document.querySelectorAll('input[name="row-select"]:checked').forEach(cb => { const tr = cb.closest("tr"); const ta = tr.querySelector("textarea"); if (ta) ta.readonly = true; }); - 还原时同理：只对已选行内的
textarea清除readonly，避免影响其他行；别用querySelectorAll("textarea").forEach(ta => ta.readonly = false)这种全局操作 - 注意兼容性：
readonly在所有现代浏览器中行为一致，无需前缀，也不受 iOS 特殊限制（不像user-select需要-webkit-touch-callout）
为什么不用 fieldset disabled 批量禁用？
因为 fieldset 的 disabled 对 textarea 有效，但它会连带禁用整个区域的焦点、Tab 导航和表单提交参与权——而你通常只要“禁选文字+禁止编辑”，并不想让它从表单数据中消失。
立即学习“前端免费学习笔记（深入）”；
-
fieldset disabled下的textarea值不会出现在FormData或form.elements中，违反“保留值但禁编辑”的业务前提 - 如果表格里混用了非
fieldset子元素（比如自定义组件、div包裹的伪输入框），disabled完全不起作用，还得额外 JS 补漏 - 嵌套
fieldset时，外层disabled会强制继承，无法局部启用——你没法只让某几行的textarea可编辑
真正麻烦的是：用户右键复制时，仍可能通过上下文菜单触发“复制”动作，哪怕 textarea 是 readonly。这不是 bug，是浏览器设计——readonly 不阻止复制，只阻止编辑和选择焦点。如需彻底禁复制，得监听 copy 事件并 event.preventDefault()，但这是边缘需求，多数场景没必要。
