WebSocket场景下表单提交拦截失效问题求助

嘿，我完全懂你接手老代码遇到这种诡异问题的头疼——明明按常规方法加了拦截，结果表单还是自顾自提交了，甚至比你的处理函数跑的还快，这太闹心了！结合你提到的WebSocket场景，我猜大概率是那个ws-send属性在搞事情，给你几个排查和解决的方向：

1. 优先排查ws-send这个自定义指令/属性 #

你表单上的ws-send看起来是和WebSocket相关的自定义逻辑（比如Vue的自定义指令），很大可能它已经提前绑定了表单的submit事件，而且执行优先级比你的@submit回调更高：

• 比如它可能用了事件捕获模式绑定事件，导致在你的冒泡阶段回调之前就触发了，直接把数据通过WebSocket发出去了；
• 或者它的逻辑里直接调用了表单的submit()方法，这种情况浏览器不会触发常规的submit事件，你的拦截自然无效。

你可以先找一下这个ws-send的实现代码：

• 如果是Vue指令，看看它的bind或mounted钩子是不是加了addEventListener('submit', ..., true)（第三个参数true就是捕获模式）；
• 要是找到了它的事件处理函数，看看能不能让它依赖你的校验结果，或者在它的逻辑里先判断是否需要提交。

2. 试试调整事件绑定的优先级和模式 #

如果不想动ws-send的代码，你可以试试把你的拦截逻辑改成捕获模式绑定，这样能抢在ws-send的前面触发：

• 用Vue语法的话，可以试试@submit.capture.prevent.stop，强制让你的回调在事件捕获阶段就执行，并且阻止默认行为和后续的事件传播；
• 或者直接用原生JS绑定，确保优先级最高：

  mounted() { // 假设是Vue组件的生命周期钩子
    const chatForm = document.querySelector('.pg-chat-input-bar');
    chatForm.addEventListener('submit', (e) => {
      e.preventDefault();
      e.stopImmediatePropagation(); // 直接阻止其他所有同类型的事件监听器执行
      // 在这里执行你的校验和转换逻辑
      this.doYourChecksAndTransforms(e);
    }, true); // 开启捕获模式
  }
  

3. 检查async函数的影响 #

虽然你的preventDefault()是第一行，但因为你的函数是async，会不会有什么框架层面的异步事件处理延迟？可以试试把同步阻止和异步逻辑分开，确保阻止默认行为是同步执行的：

handleSubmit(event) {
  // 先同步阻止默认行为，确保万无一失
  event.preventDefault();
  event.stopImmediatePropagation();
  // 再把异步逻辑包在自执行函数里
  (async () => {
    // 你的校验、转换逻辑
    // 比如 await someCheck();
  })();
}

4. 排查是否有代码直接调用了form.submit() #

如果WebSocket相关的代码是直接调用form.submit()方法提交表单，那浏览器是不会触发submit事件的，你的@submit回调根本拦截不到。

• 你可以在浏览器控制台给这个方法加个断点：打开控制台，输入HTMLFormElement.prototype.submit = function() { debugger; }，然后点击提交按钮，看看是不是有代码直接调用了这个方法。如果是，那你得找到调用的地方，在它之前插入你的校验逻辑。

总的来说，ws-send这个属性是核心疑点，毕竟它是和WebSocket直接相关的，大概率是它的逻辑绕过了你的拦截。先从这个方向查起，应该能找到问题所在。

内容来源于stack exchange