直接给元素加 pointer-events: none 常常无效，是因为它不自动屏蔽子元素表单控件的焦点和键盘事件，需显式重置子控件 pointer-events 并同步设置 disabled 属性，同时处理视觉反馈与状态同步。
为什么直接给 加 pointer-events: none 常常没效果
不是 CSS 写错了，而是 DOM 结构和继承逻辑被忽略了。pointer-events: none 会阻止所有指针事件（点击、悬停、右键、focus），但它**不自动传播到子元素的表单控件**——比如 <td> 里嵌着一个 <code><input>，你只在 td 上设 pointer-events: none，input 仍可能响应焦点或键盘输入；反过来，如果设在 tr 上，又容易误杀整行交互。
- 浏览器对
pointer-events 的继承是“单向屏蔽”：父级设 none → 子级默认继承，除非显式设 auto
- 但
input、textarea 等原生控件有独立事件路径，它们的 focus/blur 不完全依赖父级 pointer-events
- 移动端 Safari（≤15.3）对嵌套
pointer-events: auto 的恢复支持不稳定，尤其在快速滚动后
禁用整行交互时，tr 还是 td？选哪个更稳妥
优先作用于 tr，但必须配合子元素重置策略。因为表格行是语义上最自然的“禁用单元”，且避免逐个操作 td 的维护成本。
- 给
tr 加类（如 .row-disabled），CSS 中写 tr.row-disabled { pointer-events: none; }
- 同时显式恢复内部表单控件的 pointer-events：
tr.row-disabled input, tr.row-disabled select { pointer-events: auto; } —— 否则它们无法触发 focus，但注意：这仅恢复“可点击”，不代表它们能正常交互
- 真正要禁用表单控件，还得同步加
disabled 属性：$(tr).find('input, select').prop('disabled', true)，否则用户仍可通过 Tab 键聚焦并输入
- 别忘了视觉反馈：
opacity: 0.6 或 cursor: not-allowed，否则用户看不出已被禁用
基于首列内容动态禁用某几列，怎么写才不漏掉边界情况
核心是判断 + 类名标记 + 精确样式作用域。常见翻车点在于空格、大小写、换行符，以及伪元素干扰文本提取。
- 用
.trim() 和 === 比较：if ($(this).find('td:first-child').text().trim() === 'Test')，避免因 HTML 换行或空格导致匹配失败
- 禁用目标列时，不要只改
td:nth-child(2)，而应加类到整行再用后代选择器：tr.row-disabled td:nth-child(2), tr.row-disabled td:nth-child(3)，确保结构变化不影响逻辑
- 若目标列含按钮或链接，需额外处理：
a 标签默认可 focus，要加 tabindex="-1" 并设 pointer-events: none，否则键盘用户仍能按回车跳转
- 避免在禁用区域写内联
onclick —— 它会被 pointer-events: none 直接忽略，纯属冗余
inert 能替代 pointer-events: none 吗？什么情况下必须用它
能，而且更彻底，但不能无脑替换。它禁用的是整个子树的交互、焦点、屏幕阅读器访问，不是“视觉+鼠标”层面的折中方案。
- 当需要禁用包含
input、button、div 混合结构的整块区域，且要求键盘 Tab 不进入、读屏器跳过时，inert 是唯一可靠选择
- 写法必须是布尔属性：
<tr inert> 或 JS 中 <code>el.inert = true，el.setAttribute('inert', 'true') 无效
- 兼容性兜底必须做：旧浏览器不支持
inert，得 fallback 到 pointer-events: none + 手动移除 tabindex + 遍历禁用所有 input 的 disabled
- 注意：
inert 本身不改样式，禁用后务必配 CSS：[inert] { opacity: 0.6; cursor: not-allowed; }
真正复杂的地方不在写法，而在状态同步 —— 比如禁用某行后，用户又通过键盘修改了首列文本，JS 必须重新判断并更新 inert 或 class，否则视觉和行为就脱节了。
pointer-events: none 常常没效果
不是 CSS 写错了，而是 DOM 结构和继承逻辑被忽略了。pointer-events: none 会阻止所有指针事件（点击、悬停、右键、focus），但它**不自动传播到子元素的表单控件**——比如 <td> 里嵌着一个 <code><input>，你只在 td 上设 pointer-events: none，input 仍可能响应焦点或键盘输入；反过来，如果设在 tr 上，又容易误杀整行交互。
- 浏览器对
pointer-events的继承是“单向屏蔽”：父级设none→ 子级默认继承，除非显式设auto - 但
input、textarea等原生控件有独立事件路径，它们的 focus/blur 不完全依赖父级 pointer-events - 移动端 Safari（≤15.3）对嵌套
pointer-events: auto的恢复支持不稳定，尤其在快速滚动后
禁用整行交互时，tr 还是 td？选哪个更稳妥
优先作用于 tr，但必须配合子元素重置策略。因为表格行是语义上最自然的“禁用单元”，且避免逐个操作 td 的维护成本。
- 给
tr加类（如.row-disabled），CSS 中写tr.row-disabled { pointer-events: none; } - 同时显式恢复内部表单控件的 pointer-events：
tr.row-disabled input, tr.row-disabled select { pointer-events: auto; }—— 否则它们无法触发 focus，但注意：这仅恢复“可点击”，不代表它们能正常交互 - 真正要禁用表单控件，还得同步加
disabled属性：$(tr).find('input, select').prop('disabled', true)，否则用户仍可通过 Tab 键聚焦并输入 - 别忘了视觉反馈：
opacity: 0.6或cursor: not-allowed，否则用户看不出已被禁用
基于首列内容动态禁用某几列，怎么写才不漏掉边界情况
核心是判断 + 类名标记 + 精确样式作用域。常见翻车点在于空格、大小写、换行符，以及伪元素干扰文本提取。
- 用
.trim()和===比较：if ($(this).find('td:first-child').text().trim() === 'Test')，避免因 HTML 换行或空格导致匹配失败 - 禁用目标列时，不要只改
td:nth-child(2)，而应加类到整行再用后代选择器：tr.row-disabled td:nth-child(2), tr.row-disabled td:nth-child(3)，确保结构变化不影响逻辑 - 若目标列含按钮或链接，需额外处理：
a标签默认可 focus，要加tabindex="-1"并设pointer-events: none，否则键盘用户仍能按回车跳转 - 避免在禁用区域写内联
onclick—— 它会被pointer-events: none直接忽略，纯属冗余
inert 能替代 pointer-events: none 吗？什么情况下必须用它
能，而且更彻底，但不能无脑替换。它禁用的是整个子树的交互、焦点、屏幕阅读器访问，不是“视觉+鼠标”层面的折中方案。
- 当需要禁用包含
input、button、div混合结构的整块区域，且要求键盘 Tab 不进入、读屏器跳过时，inert是唯一可靠选择 - 写法必须是布尔属性：
<tr inert> 或 JS 中 <code>el.inert = true，el.setAttribute('inert', 'true')无效 - 兼容性兜底必须做：旧浏览器不支持
inert，得 fallback 到pointer-events: none+ 手动移除tabindex+ 遍历禁用所有input的disabled - 注意：
inert本身不改样式，禁用后务必配 CSS：[inert] { opacity: 0.6; cursor: not-allowed; }
真正复杂的地方不在写法，而在状态同步 —— 比如禁用某行后，用户又通过键盘修改了首列文本，JS 必须重新判断并更新 inert 或 class，否则视觉和行为就脱节了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
