支付按钮点完页面就"瘫痪"？揭秘一行 CSS 引发的"全屏冰冻"惨案

上周，我们的监控和客服反馈收到了一个诡异的用户体验问题。

现象描述： 用户在收银台选择 VISA 支付，点击"确定支付"的一瞬间，页面仿佛被施了定身术。虽然 loading 还在转，但用户想点返回、想查看订单详情，甚至想滚动页面再确认一下金额，统统没反应。整个浏览器窗口就像一张静态图片，彻底"瘫痪"了。

初步排查： 这不是浏览器崩溃，也不是 JS 线程阻塞。代码里仅仅是为了防止用户手抖连续点击扣款，加了一个防抖逻辑。

也就是这行看似"人畜无害"的原始代码：

// PaySDK.js - 为了防止重复提交
document.body.classList.add('noclick');

对应的 CSS 简单粗暴：

.noclick {
  pointer-events: none;
}

为了防止用户点按钮，我们锁住了 body。这听起来逻辑没毛病：只要"身子"动不了，"手脚"自然也动不了。但我们低估了 CSS 中 pointer-events: none 的威力。

1. 继承的陷阱

pointer-events 是一个具备继承性的属性。 当你给 document.body 加上这个属性时，这就好比给整栋大楼拉了电闸。不仅仅是 body 本身，它内部所有的子元素（按钮、链接、滚动条、输入框）默认都会继承这个设定。

2. DOM 事件流的阻断

从浏览器的事件系统来看，body 是所有页面元素的"祖先"。

捕获阶段：事件从顶层向下传导，body 说"我不接收事件"，路断了。

冒泡阶段：即便你绕过了捕获，事件冒泡回到 body 时也会被无视。

结论：我们为了锁住一个 100x40 像素的按钮，却对整个视口（Viewport）实施了"核打击"。用户被剥夺了与页面交互的所有权利，这种体验极其糟糕，甚至会让用户误以为网页死机了。

问题的根源在于作用域失控。我们需要将锁定的范围，从"整个世界"缩小到"肇事者本身"。

优化方案：精准锁定目标

我们不能再依赖全局的 body 类名，而是需要告诉 SDK：具体是哪个按钮触发了支付？

第一步：给按钮发"身份证"

在业务层，给支付按钮添加唯一标识：

// 业务代码
<button 
  id="ticket-pay-confirm-button" 
  onClick={this.finish}
>
  确定支付
</button>

第二步：透传"嫌疑人"信息

调用支付 SDK 时，将这个 ID 传进去：

// 业务层调用 PaySDK
Paying({
    // 只有需要锁定特定按钮时才传 ID，否则保持默认
    lockButtonId: shouldLockButtonOnly ? 'ticket-pay-confirm-button' : '', 
    // ... 其他参数
});

第三步：SDK 内部的精准执法

在 SDK 内部，我们做一个智能判断。如果有特定目标，就只锁目标；如果没有，为了兼容旧代码，再回退到锁 body。

// PaySDK.js 优化版
const lockTarget = getLockTarget(option); 

function getLockTarget(option) {
    // 1. 优先尝试获取指定的按钮元素
    if (option.lockButtonId) {
        const btn = document.getElementById(option.lockButtonId);
        if (btn) return btn;
    }
    // 2. 兜底方案：如果没有传ID或找不到元素，依然锁 body（保证向后兼容）
    return document.body;
}

// 施加魔法
addNoClickClass(lockTarget);

优化后的效果： 用户点击"支付"后，只有那个按钮变灰且不可点击。用户依然可以滚动页面查看条款，或者点击右上角的"关闭"退出收银台。页面的生命力回来了。

这次 Bug 的修复不仅仅是改了几行代码，更是一次关于交互哲学的思考。

1. 权限的边界

在计算机安全领域有一个"最小权限原则"（Principle of Least Privilege）。在前端交互中也是如此：永远只锁定你需要锁定的最小范围 DOM。 不要因为图省事（直接操作 body），而牺牲了用户控制浏览器的自由。

好的用户体验，往往隐藏在这些不起眼的细节里。别让你的防御性代码，变成了阻挡用户的墙。