event.target.closest(selector)从点击元素自身开始向上查找首个匹配容器，可精准定位业务上下文；需注意shadow dom边界和非元素节点自动跳过；配合matches可先做轻量过滤提升性能。
直接用 event.target.closest(selector) 就能从点击位置出发，沿冒泡路径向上找到第一个匹配的业务容器，无需手动遍历父节点。
它从自身开始查，不是从父节点开始
closest 会先检查 event.target 自己是否匹配选择器。比如点击一个带 .btn-delete 类的按钮，而该按钮本身也有 .card 类，那么 event.target.closest('.card') 返回的就是这个按钮自身，不是它的外层 div。这点常被误读，导致定位错层。
若想确保拿到的是“包裹结构”而非触发元素本身，可加一层判断：
- 先调用
const target = event.target.closest('[data-action]'); - 再用
target?.closest('.card')向上找语义容器
在事件委托中精准锁定上下文
把事件监听绑定在稳定容器上（如 #order-list），而不是 document，再用 closest 分两步提取信息：
-
const btn = e.target.closest('[data-action]');—— 定位操作触发点 -
const row = btn?.closest('tr');—— 提取数据行上下文 -
const id = row?.dataset.id;—— 获取业务标识
这样既解耦了 UI 结构变化（按钮里套图标、文字换位置都不影响），又避免了对 e.target 类型做冗长判断。
避开常见失效场景
closest 查不到？大概率卡在这两个地方：
-
Shadow DOM 边界：它不会跨 shadow root 向上查找。如果目标容器在影子根内，需改用
host.closest('.container')或监听composed: true的事件，再配合e.composedPath() -
非元素节点干扰：文本、注释节点会被自动跳过——这是优势，不是 bug。但若误把选择器写成
'span'却点击了 span 内的文字节点，closest 仍能正确返回 span 元素
配合 matches 做前置过滤更高效
不需要每次都调 closest。高频场景下可先快速筛掉无关目标：
if (!e.target.matches('[data-action], .card-header')) return;- 再执行
const card = e.target.closest('.card');
matches 只做布尔判断，开销远低于 closest 的树遍历，适合做第一道轻量过滤。
