配了五年 WebSocket，每次连本地服务都要绕过混合内容限制——今天 Chrome 154 用一个 options bag 把这件事彻底原生化了

写过前端的人都踩过这个坑——WebSocket 连本地开发服务器，每次都要面对混合内容限制。http 页面不能连 ws://，而本地服务又往往没有 HTTPS。于是要么让用户装证书，要么手动配置 IP 白名单，体验一言难尽。

Chrome 154 今天用 WebSocket constructor options bag，把这件事彻底原生化了。

旧写法：

// 只能传字符串或数组，没有扩展空间
const ws = new WebSocket("ws://192.168.1.100:8080", "soap");

新写法：

// options bag，可扩展
const ws = new WebSocket("ws://local-server.example", { 
  targetAddressSpace: "local" 
});

targetAddressSpace: "local" 告诉浏览器：这个连接虽然是公共域名，但实质上指向本地网络。浏览器因此允许混合内容页面向它发请求，不需要用户手动配置 IP 白名单。

这套机制和 Fetch API 的 targetAddressSpace 一致，WHATWG WebSocket 规范也已合并相关 PR（whatwg/websockets#76）。

目前只有 Chrome 154+ 支持，其他浏览器尚未跟进。用之前记得做特性检测：

try {
  const ws = new WebSocket(url, { 
    targetAddressSpace: "local" 
  });
} catch {
  // 浏览器不支持，回退旧写法
  const ws = new WebSocket(url, []);
}

options bag 这个设计本身也值得关注——它给 WebSocket 构造函数预留了扩展能力，未来更多选项（比如 credentials、headers）都可以通过同一个对象传入，不再需要像以前那样通过参数顺序来区分字符串协议数组和选项对象。

下一步： 如果你本地有 ws 开发服务，可以装一个 Chrome 154 测试版，把 { targetAddressSpace: "local" } 加上，观察 Network 面板里混合内容警告是否消失。