在心理辅导室的线上预约系统中，当一名处于焦虑状态的学生好不容易填完了一大堆症状描述，点击“确认预约”按钮时，如果此时学校机房的网络稍微卡顿了 2 秒钟，这名学生极有可能会因为没有立刻看到反应，而疯狂地连续点击按钮 10 次。
如果没有在前端进行任何防护，这 10 次点击会瞬间化作 10 个相同的 HTTP POST 请求，像机关枪一样打向后端服务器。
如果后端的接口没有做好严格的幂等性（Idempotency）校验，数据库里就会瞬间生成 10 条完全一模一样的心理咨询预约记录。这不仅会把心理老师当场看懵，还会极其严重地浪费数据库资源。
为了在最前线拦截这种因为网络延迟或用户急躁导致的“暴力连点”，前端工程师必须祭出两把经典的护城河武器：防抖（Debounce）与节流（Throttle）。
暴力连点的克星：防抖（Debounce）
防抖的核心极客哲学是：无论你点得有多疯狂，我只认你最后一次停手时的那一下。
假设我们设定防抖的时间窗口是 1000 毫秒。
当学生第一次点击“预约”按钮时，前端代码并不会立刻发请求，而是开启一个 1000 毫秒的倒计时炸弹。
如果在这 1000 毫秒内，学生又极其暴躁地点了第二次，代码会极其冷酷地将之前的倒计时炸弹拆除，然后重新开启一个新的 1000 毫秒倒计时。
只有当学生彻底放弃连点，手离开鼠标，倒计时安稳地走完了这 1000 毫秒，那唯一的、真正的 HTTP 请求才会被发射向后端。
“`javascript
// 极其优雅的防抖高阶函数
function debounce(func, delay) {
let timer = null;
return function (…args) {
if (timer) clearTimeout(timer); // 发现连点，无情拆除旧炸弹
timer = setTimeout(() => {
func.apply(this, args); // 等待风平浪静后，执行真正的提交
}, delay);
}
}
“`
实时保存的缰绳：节流（Throttle）
防抖非常适合“只认最后一次”的提交场景。但心理测试平台中还有一种极其特殊的场景：答卷的实时自动保存。
当学生在做一个极其漫长的沙盘拖拽测试时，系统需要在后台偷偷把他的每一步操作同步到服务器。
如果他 1 分钟内拖拽了 300 次，我们不能用防抖（因为防抖会导致他一直拖就不保存，直到停手才保存，万一中间断电就完了）。我们也不能每一次拖拽都发请求，那样会把后端服务器直接 DDOS 打挂。
此时必须使用节流（Throttle）。
节流的极客哲学是：无论你操作得有多快，我强行把频率拉低到“每隔 X 秒执行一次”。
设定节流时间为 5000 毫秒。
当学生疯狂拖拽时，代码在第 1 毫秒极其果断地触发第一次保存请求，然后立刻将自己锁死（上锁）。在接下来的 4999 毫秒内，无论学生怎么拖拽，所有的保存请求都会被无情地丢弃。直到第 5000 毫秒锁解开，才允许触发第二次保存。
“`javascript
// 极其克制的节流高阶函数
function throttle(func, limit) {
let inThrottle;
return function (…args) {
if (!inThrottle) {
func.apply(this, args); // 第一次立即执行
inThrottle = true; // 瞬间锁死
setTimeout(() => inThrottle = false, limit); // X秒后解锁
}
}
}
“`
终极形态：UI 层面的降维物理锁定
虽然防抖和节流极其优雅地保护了后端，但在交互体验上，如果学生点完按钮后，页面看起来依然没有任何变化（只是在后台防抖），他依然会极其焦虑。
正如橙星云大前端团队在交付核心业务时所制定的交互红线：防抖与节流只是底层逻辑，最完美的防线必须在 UI 层面实现“物理锁定”。
当学生点击“确认预约”的第 1 毫秒，按钮必须瞬间变成灰色不可点击状态（disabled: true），并且按钮文字极其醒目地变成一个旋转的 Loading... 图标。
这不仅从物理上彻底剥夺了学生连点的可能，更是在心理学上给予了他一个极其稳定的情绪安抚：“系统已经收到你的请求了，正在拼命处理，别急。”
总结
在 B 端高频交互的残酷战场上，不设防的前端表单就是后端灾难的源泉。
通过极其冷酷的防抖与节流算法，结合 UI 层面的物理锁定，前端工程师在网络的最外围筑起了一道坚不可摧的防线。在这场与网络延迟和人性急躁的博弈中，技术团队用最极客的代码，捍卫了整个系统底层数据的绝对纯洁与宁静。