label for属性必须严格匹配textarea的id才能触发聚焦，大小写、连字符、空格等须完全一致；嵌套写法要求textarea为label直接子元素；动态插入时需确保id在DOM中已存在且唯一。
label for 属性必须严格匹配 textarea 的 id
点击 label 触发 textarea 聚焦，前提是 for 值与 textarea 的 id 字符串完全一致——大小写、空格、连字符都不能差。浏览器只做纯字符串比对，不校验元素是否存在或是否可聚焦。
常见错误现象：label 点击无反应，但检查 DOM 发现结构“看起来是对的”。
-
<label for="msg">留言</label><textarea id="MSG"></textarea>→ 失效（大小写不一致） -
<label for="user message">留言</label><textarea id="user message"></textarea>→ 失效（id含空格，HTML 中非法） -
<label for="content">内容</label><textarea name="content"></textarea>→ 失效（缺少id，for无目标）
嵌套写法对 textarea 同样有效，但有结构限制
把 textarea 直接作为 label 的**直接子节点**，可省去 id 和 for，且语义更干净。这种隐式关联是 HTML5 原生支持的，不是 JS 模拟。
但必须满足：
-
textarea是label的第一个或唯一子元素，中间不能插span、div或换行符文本节点（如 -
textarea不能设disabled；readonly可聚焦但不可编辑，属于正常行为 - 若用 CSS 重置了
label的display（如display: block），需确认pointer-events仍为auto，否则热区失效
✅ 正确示例：<label>反馈意见<textarea name="feedback"></textarea></label>
立即学习“前端免费学习笔记（深入）”；
❌ 错误示例：<label>反馈意见<span><textarea name="feedback"></textarea></span></label>（textarea 不是直接子节点）
移动端 textarea 聚焦失败的三个隐蔽原因
iOS Safari 和部分安卓 WebView 对非原生可聚焦元素的焦点策略更严格，即使 label 关联正确，也可能点不动。
-
<meta name="viewport">缺失或user-scalable=no→ 导致点击事件被拦截，加width=device-width, initial-scale=1可解 -
textarea被父容器设置了overflow: hidden且高度不足 → 视觉可见但实际渲染盒被裁剪，热区丢失 -
label或其祖先元素有tabindex="-1"→ 破坏默认可聚焦逻辑，尤其在封装组件时容易误加
验证方法：临时给 label 加 outline: 1px solid red，看是否完整包裹 textarea 可视区域；再用开发者工具检查 computed styles 中 pointer-events 和 focusable 状态。
accesskey 配合 label 实现快捷聚焦，但兼容性有限
accesskey 属性可让键盘用户按组合键（如 Alt+M）快速聚焦关联的 textarea，但它不是焦点获取的主路径，而是辅助通道。
使用时注意：
- 不同系统快捷键前缀不同：Windows/Linux 通常为
Alt+X，macOS 是Ctrl+Option+X，iOS Safari 不支持 - 避免与浏览器默认快捷键冲突（如
accesskey="s"会和「保存」冲突） - 必须配合正确的
for+id关联，否则accesskey无效
示例：<label for="note" accesskey="n">备注</label><textarea id="note" name="note"></textarea> —— 用户按 Alt+N 即可聚焦。
真正容易被忽略的是：当 textarea 动态插入 DOM（比如通过 JS 渲染表单字段）时，id 必须在插入完成、渲染完毕后才稳定存在；若 label 先挂载、textarea 后 append，关联就断开了——这不是 bug，是 DOM 时序问题。
