touch-action: manipulation 在桌面端无效，因该属性专为触摸设备手势识别设计，桌面浏览器忽略它且不触发任何行为，既不影响事件派发也不优化交互。
它在桌面端不是“无效”，而是根本不会被解析或触发任何行为——因为规范里就没定义它对鼠标/键盘操作的意义。
touch-action: manipulation 的语义只存在于触摸输入上下文
这个属性是 W3C 为「触摸设备上的手势识别阶段」专门设计的，目标是让浏览器提前决定：这个区域要不要等双击、允不允许缩放、是否接管滚动。桌面端没有「触摸手势识别」这一步，touch-action 属性会被浏览器忽略（Chrome/Firefox/Safari 均如此），既不报错，也不产生副作用。
常见误解是看到桌面 Chrome 开发者工具里能写上 touch-action: manipulation 就以为生效了——其实只是 CSS 解析器没报错，但计算样式中 getComputedStyle(el).touchAction 返回的仍是 auto，且完全不影响 click 或 mousedown 的派发时机。
为什么桌面端不需要它
桌面浏览器本来就没有 300ms 点击延迟问题，也不存在「双击缩放等待」逻辑。鼠标点击是瞬时事件，click 在 mouseup 后立刻触发；键盘 Enter 或 Space 也无等待机制。所以：touch-action 对桌面端既无作用对象，也无优化目标。
- 它不控制
hover、focus、click的触发顺序或延迟 - 它不影响
pointerdown/mousedown的派发，也不改变事件冒泡路径 - 即使你在桌面端给
button加了该声明，也不会增强可访问性或交互反馈
别在桌面场景下测试或依赖它
很多开发者用 Chrome 桌面版的「Device Toolbar」模拟移动端，误以为此时 touch-action: manipulation 起效了——但这是假象。DevTools 的模拟仅切换 UA 和视口，不启用真实的触摸事件栈，也不激活手势识别器。真正在桌面触控屏（如 Surface）上，若系统未启用「触摸模式」，该属性依然不参与任何决策。
真正起效的唯一路径是：真实移动设备 + 支持该值的浏览器（Chrome ≥ 36、Safari ≥ 13.1、Firefox ≥ 64）+ 元素处于可点击上下文（非 iframe、未被 touchstart 监听器打断）。
最容易被忽略的一点：这个属性从来就不是为「跨端一致性」设计的，它是移动端触摸栈里一个极窄的优化开关。想让桌面和移动端共用同一套交互逻辑？得靠 pointerdown + preventDefault() 配合检测，而不是指望 touch-action 在两个世界里都工作。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
