HTML Form 可以把 POST 响应加载进 iframe

在接入支付验证、身份认证或第三方授权页面时，我们经常会遇到这样的流程：

1. 后端返回一个第三方接口地址。
2. 这个地址必须通过 POST 请求访问。
3. 接口返回 HTML，或者重定向到真正的验证页面。
4. 验证页面需要嵌入当前网站，而不是打开新标签页。
5. 验证完成后，当前页面继续执行后续业务。

第一次遇到这个需求，很容易想到：

复制const response = await fetch(url, {
  method: "POST",
});

iframe.src = response.url;

但涉及第三方支付时，这种方式通常会遇到 CORS、Cookie、重定向和跨域页面读取限制。

实际上，HTML 原生就提供了一个非常适合这种场景的能力：

使用 <form target="..."> 把 POST 请求的响应加载到指定的 <iframe> 中。

#核心原理

form 的 target 不仅可以是 _blank、_self，还可以指向一个具名的浏览上下文。

而具有 name 属性的 iframe，就是一个具名浏览上下文。

复制<iframe name="verification-frame"></iframe>

<form
  action="https://payment.example.com/start-verification"
  method="POST"
  target="verification-frame"
>
  <button type="submit">开始验证</button>
</form>

这里最关键的是：

复制<form target="verification-frame">
<iframe name="verification-frame">

两者名称相同。

用户提交表单后，浏览器会：

1. 向 form.action 发起 POST 请求。
2. 将表单字段放入请求体。
3. 处理服务端返回的 HTML。
4. 自动跟随后续 HTTP 重定向。
5. 把最终页面渲染到对应的 iframe 中。

整个过程中，父页面不会跳转，也不会打开新标签页。

#自动提交隐藏表单

支付验证通常不需要用户再次点击“提交”，因此可以创建隐藏表单并自动提交。

复制<iframe
  name="verification-frame"
  title="Secure verification"
  style="width: 100%; height: 600px; border: 0"
></iframe>

<form
  id="verification-form"
  action="https://payment.example.com/start-verification"
  method="POST"
  target="verification-frame"
  hidden
>
  <input type="hidden" name="challengeRequest" value="SANITIZED_VALUE" />
</form>

<script>
  document.getElementById("verification-form").submit();
</script>

注意，应该调用原生的：

复制form.submit();

这会直接提交表单，不触发按钮点击。

#React 实现

在 React 中可以分别为表单和 iframe 创建引用。

复制import { useEffect, useId, useRef } from "react";

interface VerificationFrameProps {
  actionUrl: string;
  challengeRequest?: string;
}

export default function VerificationFrame({
  actionUrl,
  challengeRequest,
}: VerificationFrameProps) {
  const formRef = useRef<HTMLFormElement>(null);
  const frameRef = useRef<HTMLIFrameElement>(null);
  const submittedRef = useRef(false);
  const reactId = useId();

  const frameName = `verification-frame-${reactId.replace(/:/g, "")}`;

  useEffect(() => {
    if (!actionUrl || submittedRef.current) return;

    const frameId = requestAnimationFrame(() => {
      formRef.current?.submit();
      submittedRef.current = true;
    });

    return () => cancelAnimationFrame(frameId);
  }, [actionUrl]);

  return (
    <>
      <iframe
        ref={frameRef}
        name={frameName}
        title="Secure verification"
        allow="payment"
        className="h-[600px] w-full border-0"
      />

      <form
        ref={formRef}
        action={actionUrl}
        method="POST"
        target={frameName}
        hidden
      >
        {challengeRequest ? (
          <input
            type="hidden"
            name="challengeRequest"
            value={challengeRequest}
          />
        ) : null}
      </form>
    </>
  );
}

这里使用 useId() 生成唯一 iframe 名称，避免页面同时出现多个验证组件时发生冲突。

#为什么不能直接使用 iframe.src

iframe.src 只能导航到一个 URL，默认执行的是 GET：

复制<iframe src={actionUrl} />

它相当于：

复制GET /start-verification

如果第三方接口要求：

复制POST /start-verification

直接设置 src 就不符合接口协议。

而 form 可以明确指定请求方法：

复制<form method="POST" target="verification-frame">

因此，“POST 接口并将响应显示到 iframe”是 form 与 iframe 联动的典型使用场景。

#为什么不使用 fetch

fetch 更适合获取 JSON 或由 JavaScript处理的普通接口响应，但第三方验证页面往往涉及：

• 跨域请求。
• HTTP 302/303 重定向。
• 第三方 Cookie。
• 服务端生成的 HTML 表单。
• 发卡行或认证机构页面。
• 浏览器安全策略。
• 用户交互和多次页面跳转。

如果使用 fetch，可能首先遇到 CORS：

复制await fetch(thirdPartyUrl, {
  method: "POST",
});

即使请求成功，前端也不一定能读取响应内容或最终地址。

原生 form 提交属于浏览器页面导航，不需要 JavaScript读取第三方响应。浏览器会把整个请求和重定向链直接交给 iframe。

#如何知道 iframe 中的验证已经完成

由于 iframe 页面来自第三方域名，父页面通常不能读取：

复制iframe.contentWindow.location.href;

浏览器会因为同源策略阻止访问。

第三方页面通常使用 postMessage 通知父页面：

复制window.parent.postMessage(
  {
    type: "verification_complete",
    transactionId: "SANITIZED_TRANSACTION_ID",
  },
  "https://merchant.example.com"
);

父页面监听消息：

复制useEffect(() => {
  const handleMessage = (event: MessageEvent) => {
    if (event.source !== frameRef.current?.contentWindow) {
      return;
    }

    if (
      typeof event.data !== "object" ||
      event.data === null ||
      event.data.type !== "verification_complete"
    ) {
      return;
    }

    completeVerification(event.data.transactionId);
  };

  window.addEventListener("message", handleMessage);

  return () => {
    window.removeEventListener("message", handleMessage);
  };
}, []);

如果第三方消息来源域名固定，还应同时校验 event.origin：

复制if (event.origin !== "https://payment.example.com") {
  return;
}

如果认证过程中会跳转到多个动态域名，可以至少校验：

• event.source 是否属于当前 iframe。
• 消息结构是否符合预期。
• 交易标识是否与当前交易一致。
• 最终结果是否经过自己的后端确认。

#不要把 postMessage 当成最终支付凭证

iframe 发出的“验证成功”消息只适合用来触发下一步操作，不应该直接作为支付成功依据。

更安全的流程是：

复制iframe 发出验证完成消息
        ↓
前端把交易标识提交给自己的后端
        ↓
后端调用支付服务完成或查询交易
        ↓
后端确认交易状态
        ↓
前端展示充值成功

也就是说：

复制async function handleVerificationComplete(transactionId: string) {
  const response = await fetch("/api/payment/complete-verification", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ transactionId }),
  });

  const result = await response.json();

  if (result.status === "succeeded") {
    showPaymentSuccess();
  }
}

支付成功最好还要结合服务端 webhook 最终确认。

#常见限制

#第三方不允许被 iframe 加载

如果响应包含以下响应头：

复制X-Frame-Options: DENY

或者：

复制Content-Security-Policy: frame-ancestors 'none'

浏览器将拒绝在 iframe 中显示页面。

这种限制无法由前端绕过，只能：

• 联系第三方调整配置。
• 使用其官方嵌入式 SDK。
• 改为顶层页面跳转。
• 使用新窗口作为兜底。

#第三方 Cookie 可能受限

Safari 和部分隐私模式会限制 iframe 中的第三方 Cookie。认证服务需要正确支持无第三方 Cookie模式，或者提供顶层跳转方案。

#不要使用 sandbox 限制未知的支付页面

给 iframe 添加 sandbox 可以增强隔离，但也可能阻止表单、脚本、Cookie或页面跳转：

复制<iframe sandbox="allow-forms allow-scripts"></iframe>

支付页面需要哪些权限，应按照服务商文档配置，不能随意添加或删除。

#总结

form 和 iframe 的联动依靠两个属性：

复制<form target="secure-frame">
<iframe name="secure-frame">

它特别适合下面这种需求：

• 第三方接口要求 POST。
• POST 响应是 HTML 页面。
• 响应可能继续重定向。
• 页面需要内嵌展示。
• JavaScript不需要读取第三方响应内容。

最终实现可以概括为：

复制业务接口返回启动 URL
        ↓
form 使用 POST 提交启动 URL
        ↓
target 指向具名 iframe
        ↓
浏览器在 iframe 中处理响应和重定向
        ↓
第三方通过 postMessage 通知验证完成
        ↓
自己的后端确认结果并继续业务

这是一个很“传统”的 HTML 能力，却非常适合现代支付、3DS、身份认证和第三方授权流程。