Javascript中如何判断window.open(url)调用是否成功？

你原有的实现无法生效，核心原因是window.open()的返回值规则和你设想的完全不同：

• 仅当浏览器拦截了弹窗时，window.open()返回null
• 弹窗成功弹出时，返回新窗口的window对象，不会返回任何和HTTP请求状态（比如success、404）相关的取值
• 受浏览器同源策略限制，只要弹出的目标地址和你当前站点不同源，你就无法通过JS读取新窗口的任何内容、请求状态信息。

以下是不同场景下的可行解决方案： #

场景1：打开的是同域地址 #

同域下不受同源策略限制，可以直接监听新窗口加载状态，同时主动校验地址的HTTP状态：

const url = '/your-same-origin-path';
const newWindow = window.open(url, 'main');

// 先判断是否被浏览器弹窗拦截
if (!newWindow) {
  alert('弹窗被浏览器拦截，请允许弹窗后重试');
  return;
}

// 监听新窗口加载完成事件
newWindow.addEventListener('load', async () => {
  try {
    // 用HEAD请求校验地址可用性，不会返回完整 body 性能更高
    const checkRes = await fetch(url, { method: 'HEAD' });
    if (checkRes.ok) {
      console.log('页面加载成功，状态码正常');
      // 后续成功逻辑
    } else {
      console.log('页面请求异常，状态码：', checkRes.status);
      newWindow.close(); // 异常场景可直接关闭弹窗
      // 后续异常逻辑
    }
  } catch (e) {
    console.log('地址校验失败', e);
  }
});

场景2：打开的是跨域地址 #

跨域下受浏览器安全策略限制，纯前端无法直接获取目标地址的HTTP状态，只能用两种可选方案实现需求：

• 方案A：通过后端代理校验地址可用性（可以拿到精确HTTP状态码）

async function openUrlAfterCheck(targetUrl) {
  try {
    // 后端接口需要实现的逻辑：请求目标地址，返回对应的HTTP状态和可用性，解决跨域问题
    const checkRes = await fetch('/api/check-url-status', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ url: targetUrl })
    });
    const { status, available } = await checkRes.json();
    if (available) {
      const newWindow = window.open(targetUrl, 'main');
      if (!newWindow) alert('弹窗被浏览器拦截');
      // 后续成功逻辑
    } else {
      alert(`目标地址不可用，状态码：${status}`);
      // 后续异常逻辑
    }
  } catch (e) {
    alert('地址校验失败');
  }
}

// 调用示例
openUrlAfterCheck('https://www.google.com');

• 方案B：仅判断弹窗是否成功弹出，不校验HTTP状态

const targetUrl = 'https://www.google.com';
const newWindow = window.open(targetUrl, 'main');

if (!newWindow) {
  alert('弹窗被浏览器拦截');
} else {
  // 可监听弹窗关闭事件做后续处理
  const closeTimer = setInterval(() => {
    if (newWindow.closed) {
      clearInterval(closeTimer);
      console.log('弹窗已被用户关闭');
    }
  }, 1000);
}

注意：纯前端没有任何办法绕开同源策略获取跨域地址的HTTP状态，只要你需要判断404这类异常状态，必须借助后端代理实现。

内容的提问来源于stack exchange，提问作者Vardan Betikyan