$(document).ready后函数未完全执行，Chrome中WebRTC视频异常求助

这种按住回车就能正常显示的现象确实有点反直觉，但本质是触发了Chrome的某些渲染或事件循环机制，帮你绕过了原本的时机或权限问题。结合你的执行流程，我整理了几个最可能的原因和对应的解决办法：

1. Chrome的自动播放策略限制 #

Chrome对媒体自动播放有严格的规则：默认情况下，只有页面存在用户交互（比如点击、按键）后，才能自动播放带声音的视频。你按住回车属于用户交互操作，刚好满足了这个条件，所以视频能正常播放；而页面加载时直接执行函数，没有用户交互触发，Chrome可能悄悄阻止了video.play()的执行。

解决办法：

• 给视频元素添加静音属性，Chrome允许静音视频自动播放：

  const video = document.createElement('video');
  video.muted = true; // 关键：设置静音
  video.autoplay = true;
  

• 或者，将初始化函数绑定到一个用户交互事件上（比如页面首次点击），确保在用户操作后再执行流的播放：

  let hasInited = false;
  document.addEventListener('click', () => {
    if (!hasInited) {
      yourInitFunction();
      hasInited = true;
    }
  }, { once: true });
  

2. DOM渲染与流绑定的时机不匹配 #

如果你的流程是先获取WebRTC流，再创建div和video元素，Chrome可能在流绑定的时候，video元素还没被插入DOM树，导致浏览器没有触发视频渲染。而按住回车可能触发了页面的重排/重绘，让浏览器重新识别到了video元素的存在。

解决办法：
确保先将video元素插入DOM，再绑定WebRTC流：

// 1. 先创建并插入DOM元素
const videoDiv = document.createElement('div');
const video = document.createElement('video');
videoDiv.appendChild(video);
document.body.appendChild(videoDiv);

// 2. 再绑定流并播放
video.srcObject = yourWebRTCStream;
video.play().catch(err => {
  console.error('播放失败:', err); // 一定要捕获这个错误，排查问题
});

如果还是不行，可以用requestAnimationFrame强制在浏览器下一次重绘前执行流绑定：

requestAnimationFrame(() => {
  video.srcObject = yourWebRTCStream;
  video.play();
});

3. 页面加载时的事件循环阻塞 #

$(document).ready或$(window).load执行时，页面可能还有其他同步任务在阻塞事件循环，导致WebRTC的流回调被延迟处理。按住回车可能打断了阻塞（比如触发了某个事件，让事件循环切换到处理流的回调）。

解决办法：
把初始化函数放到setTimeout里，让它在事件循环的下一轮执行，给浏览器足够时间完成初始渲染：

$(window).load(() => {
  setTimeout(() => {
    yourInitFunction();
  }, 0); // 0毫秒延迟会将任务放到事件循环队列末尾
});

或者使用requestIdleCallback，在浏览器空闲时执行初始化：

$(window).load(() => {
  requestIdleCallback(() => {
    yourInitFunction();
  });
});

最后一步：排查隐藏错误 #

你的错误处理只显示“连接成功”，但可能忽略了video.play()的Promise拒绝错误。打开Chrome开发者工具（F12）的Console标签，查看是否有类似DOMException: play() failed because the user didn't interact with the document first.的错误，这能帮你快速定位问题。

内容的提问来源于stack exchange，提问作者Kevin Dalli