postMessage 转移 MessagePort 后原端口还能用吗

不能。把 MessagePort 放进 postMessage() 的 transfer 列表后，交出去的是端口所关联资源的所有权，不是复制出第二个可并行使用的端口。发送侧那个原 MessagePort 对象不应再承担收发任务；接收侧得到的新对象才是该端点的新持有者。

最实用的记法：创建 MessageChannel 后，主线程保留 port1，只把 port2 转移给 Worker 或 iframe。之后双方分别通过 port1 与“接收侧的 port2”通信。

规范与文档：https://html.spec.whatwg.org/multipage/web-messaging.html、https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Transferable_objects

先给结论：转移的是端口所有权

MessagePort 是 transferable object。执行转移时，浏览器会保存该端口的消息队列以及它所关联的远端端口；接收侧反序列化时创建新的 MessagePort 对象，把等待投递的消息任务移动过去，并让新对象重新与另一端建立关联。原对象则与通道脱离。

这件事有两个容易误判的地方。第一，变量 channel.port2 可能仍然存在，并不代表它仍拥有通道资源。第二，不要把“调用没有立刻报错”当成端口仍可用。按照消息端口的发送算法，一个已经没有配对目标的端口可以在序列化消息后直接返回，因此用 try...catch 探测端口是否转移并不可靠。应用应自己维护明确的所有权状态。

按正确的端口分工建立通道

主线程先绑定 port1 的接收逻辑，再把 port2 同时放入消息数据与 transfer 列表。transfer 列表决定哪些资源要移动，消息数据则给接收侧一个清楚的字段来取得它。

const worker = new Worker("./worker.js", { type: "module" });
const channel = new MessageChannel();

// 中文注释：主线程只保留 port1，并通过它收取 Worker 的回复
channel.port1.onmessage = (event) => {
  console.log("主线程收到：", event.data);
};

worker.postMessage(
  { type: "connect", port: channel.port2 },
  [channel.port2], // 中文注释：port2 的所有权在这里交给 Worker
);

// 中文注释：后续主线程只使用仍由自己持有的 port1
channel.port1.postMessage({ type: "ping", requestId: "req-001" });

Worker 从 event.data.port 取得接收侧端口。这里使用 onmessage，第一次设置该属性时端口消息队列会自动启用。

let peerPort;

self.onmessage = (event) => {
  if (event.data.type !== "connect") return;

  // 中文注释：这是接收侧的新 port2，不是对旧对象的共享引用
  peerPort = event.data.port;
  peerPort.onmessage = (messageEvent) => {
    peerPort.postMessage({
      type: "pong",
      requestId: messageEvent.data.requestId,
    });
  };

  // 中文注释：先完成监听绑定，再通知主线程通道已经就绪
  peerPort.postMessage({ type: "ready" });
};

如果发送侧仍然需要两个独立下游，就不能把同一个 port2 当成可复制资源。应为每个下游创建新的 MessageChannel，或者让接收侧再创建一条通道并把新端口传回来。

接收侧启用端口并确认就绪

使用 onmessage 时，设置处理器会隐式启用端口；使用 addEventListener("message", ...) 时，则需要显式调用 start()。漏掉这一步，消息可能已经进入队列，但处理器迟迟不执行，看起来很像“转移失败”。

function activatePort(port) {
  // 中文注释：addEventListener 方式必须显式启动端口队列
  port.addEventListener("message", (event) => {
    console.log("收到通道消息：", event.data);
  });

  port.addEventListener("messageerror", (event) => {
    console.error("消息无法反序列化：", event.data);
  });

  port.start();
}

规范要求转移时把待触发 message 事件的任务移动到接收侧新端口的消息队列，并让新端口以“尚未启用”的状态开始。因此，队列不会因为转移自动丢失，但何时开始交付仍取决于接收侧是否设置 onmessage 或调用 start()。

生产代码最好再加一层 ACK。接收侧完成监听绑定后发出 ready，发送侧收到后再提交业务消息；同时设置超时，如果规定时间内没有 ACK，就关闭通道并重建。这样，初始化状态不再依赖“Worker 大概已经准备好”的猜测。

把转移、关闭和异常分开处理

这些 API 解决的是不同问题，混在一起会让故障状态难以判断：

• transfer：把端口资源从一个上下文交给另一个上下文，旧持有者退出。
• start：启用接收侧端口的消息队列，只在 addEventListener 方案中需要显式调用。
• ACK：应用层确认接收侧已经绑定监听器，可用于超时、重试和可观测性。
• messageerror：处理收到消息却无法反序列化的情况，它不是普通业务错误事件。
• close：主动终止端口关联，用于页面卸载、Worker 退出或业务会话结束后的资源清理。

建议把发送侧状态限制为 creating、transferred、ready、closed 四种。只有 ready 状态允许投递业务消息；一旦进入 transferred，代码审查就应禁止再次访问旧 port2；进入 closed 后则释放待处理请求和超时器。

let channelState = "creating";

function handoffPort(worker, port) {
  worker.postMessage({ type: "connect", port }, [port]);
  // 中文注释：从此以后不再读写参数 port
  channelState = "transferred";
}

function disposeChannel(port1) {
  // 中文注释：关闭保留端，并同步清理应用层状态
  port1.close();
  channelState = "closed";
}

用一张检查表定位常见误区

常见问题

转移 port2 后，port1 还能用吗？

能。port1 没有被转移，它仍留在创建端，并会与接收侧获得的新 port2 通信。这正是 MessageChannel 最常见的用法。

旧 port2 调用 postMessage 没报错，是否说明还能用？

不能这样判断。旧端口已经不再是通道的有效持有者，调用是否同步抛错不是可靠的所有权信号。请以应用自己的状态字段为准，并在转移后清空或封装旧引用。

转移期间已经排队的消息会不会丢？

规范的转移接收步骤会把待触发消息事件的任务移动到接收侧新端口的消息队列。接收侧仍要启用该队列；对于业务级可靠性，还应使用 requestId、ACK、超时和必要的幂等处理。

close() 和 transfer 是一回事吗？

不是。transfer 是把端口所有权交给另一个上下文，并让通道在新对象上继续工作；close() 是主动断开端口关联，表示这条通道结束。