发布时间：2025 年 10 月 29 日
除非另有说明，否则这些变更适用于 Android、ChromeOS、Linux、macOS 和 Windows 的 Chrome 143 Beta 版。如需详细了解这些功能，请访问提供的链接或 ChromeStatus.com。从 Google.com 下载适用于桌面设备的 Chrome 143 Beta 版，或在 Android 设备上从 Google Play 商店下载。
CSS 和界面
CSS 锚定后备容器查询
此功能引入了 @container anchored(fallback)，用于根据应用的 position-try-fallbacks 值来设置锚定位置元素的后代的样式。
例如，您可以使用此类查询来设置锚定元素的系绳或其动画的样式，具体取决于锚点和锚定元素彼此之间的相对位置。
示例：
#anchored {
position-try-options: flip-block;
container-type: anchored;
}
@container anchored(fallback: flip-block) {
#anchored > .arrow {
--arrow-rotation: 180deg;
}
}
如需了解详情，请参阅使用锚定容器查询检测后备位置（自 Chrome 143 起）。
EditContext：TextFormat underlineStyle 和 underlineThickness
Chromium 随附的 EditContext API 存在一个 bug，即由 EditContext/textformatupdate_event 提供的 TextFormat 对象为 underlineStyle 和 underlineThickness 属性提供的值不正确。在 Chromium 中，可能的值包括 None、Solid、Dotted、Dashed、Squiggle 和 None、Thin、Thick。不过，根据 EditContext 规范，它们应该是 none、solid、dotted、dashed、wavy 和 none、thin、thick。
Web API
允许在 JavaScript DOM API 中使用更多字符
HTML 解析器一直（或很长时间以来）允许元素和属性具有各种有效的字符和名称，但用于创建相同元素和属性的 JavaScript DOM API 更加严格，与解析器不匹配。
此更改放宽了对 JavaScript DOM API 的验证，以与 HTML 解析器保持一致。
如需了解更多背景信息，请访问： github.com/whatwg/dom/issues/849
此更改预计不会导致兼容性问题，因为之前允许的所有元素和属性名称在新行为中仍然有效。
推测规则：移动设备“急切”程度的改进
在移动设备上，对于“急切”程度的预提取和预渲染推测规则，现在会在 HTML 锚元素在视口中停留一小段时间时触发。
之前，预提取和预渲染会尽快开始，相当于“立即”热切度。更新后的行为更有用，因为它能更好地反映作者的意图，即比“中等”更急切，但比“立即”不急切。
实现 CSS 属性 font-language-override
此功能在 Chromium 中引入了对 font-language-override CSS 属性的支持。借助此属性，开发者可以直接在 CSS 中指定四字符语言标记，从而替换用于 OpenType 字形替换的系统语言。
这样可以实现精细的排版控制，这对于多语言内容或具有特定于语言的字形变体的字体非常有用。
WebGPU：纹理组件混色
纹理分量混杂可让 GPUTextureViews 在着色器访问纹理的红色、绿色、蓝色或 Alpha 通道时，重新排列或替换这些通道中的颜色分量。
ICU 77（支持 Unicode 16）
Unicode 支持库 ICU（International Components for Unicode，国际化组件）从版本 74.2 升级到 77.1，添加了对 Unicode 16 的支持并更新了语言区域数据。以下两项变更可能会对假定 Intl JavaScript API 采用特定格式的 Web 应用构成风险：
- 现在，默认的意大利数字格式会针对 4 位数字省略千位分隔符。例如，
new Intl.NumberFormat("it").format(1234)会返回“1234”，而不是“1.234”。您可以使用Intl.NumberFormat构造函数的useGrouping参数来实现旧行为。 - 在某些英语语言区域设置（例如 en-AU、en-GB 和 en-IN）中，全长星期几后添加了英文逗号，将“Saturday 30 April 2011”更改为“Saturday, 30 April 2011”。Web 应用必须避免依赖于日期的精确格式。
- Intl 和 RegExp (V8)：许多细微的更改。意大利数字格式更改的风险最高，因此有专门的标志。
- IDNA：此升级通常允许更多内容，并改进了 WPT 中的总体测试结果。
- 文本分段：最显著的变化是，在使用
word-break: auto-phrase时，日语换行效果有所改进。这与 https://chromestatus.com/feature/5133892532568064 有关。
针对 insertFromPaste、insertFromDrop 和 insertReplacementText 输入事件的 DataTransfer 属性
此功能会使用 insertFromPaste、insertFromDrop 和 insertReplacementText 的 inputType 填充输入事件的 dataTransfer 属性。在 contenteditable 元素中进行编辑操作期间，此权限可提供对剪贴板和拖放数据的访问权限。
dataTransfer 对象包含与 beforeinput 事件期间可用的数据相同的数据。
此功能仅适用于 contenteditable 元素。对于表单控件（textarea、input），行为保持不变，data 属性包含插入的文本，而 dataTransfer 仍为 null。Safari 和 Firefox 都已支持此功能。Chrome 采用此功能可增强浏览器之间的互操作性，为 Web 作者提供更一致的体验。
FedCM - 支持来自 IdP 的结构化 JSON 响应
借助此功能，身份提供方 (IdP) 可以通过 id_assertion_endpoint 向信赖方 (RP) 返回结构化 JSON 对象，而不是纯字符串。
此更改消除了手动序列化和解析 JSON 字符串的需求，从而简化了开发者的集成流程。它提供更动态、更灵活的身份验证流程，使 RP 可以直接解读复杂响应，并支持各种协议（如 OAuth2、OIDC 或 IndieAuth），而无需带外协议。
WebTransport 应用协议协商
借助 WebTransport 应用协议协商，您可以在 WebTransport 握手中协商 Web 应用使用的协议。
Web 应用可以在构建 WebTransport 对象时指定应用协议列表。然后，这些协议会通过 HTTP 标头传达给服务器。如果服务器选择其中一种协议，则可以在响应标头中指明，并且该回复可在 WebTransport 对象中使用。
适用于独立式 Web 应用的 Web Smart Card API
仅适用于独立式 Web 应用 (IWA)。借助此功能，智能卡 (PC/SC) 应用可以迁移到 Web 平台。这使它们能够访问主机操作系统中可用的 PC/SC 实现（和读卡器驱动程序）。
管理员可以通过以下两种方式控制此 API 的可用性：
- 全局 - 使用
DefaultSmartCardConnectSetting政策 - 按应用 - 使用
SmartCardConnectAllowedForUrls和SmartCardConnectBlockedForUrls政策
Web 应用清单：指定更新资格条件，图标网址的 Cache-Control 为 immutable
清单规范现在包含更新资格算法。这使得更新过程更具确定性和可预测性，让开发者可以更好地控制更新何时应用于现有安装，并让用户可以更好地选择如何处理更新，例如在需要时忽略更新。它还允许移除用户代理为避免浪费网络资源而实现的“更新检查节流”。
重度广告干预：发送到嵌入框架的报告
广告干预报告现在会发送到广告的嵌入框架，而不仅仅是广告框架本身。发送到嵌入框架的报告将包含广告 iframe 的 ID 和在报告正文的消息字段中卸载的框架的预重定向网址。此项变更使嵌入上下文能够识别有问题的广告提供商并处理干扰性广告，从而改善用户体验。
正在进行的源试用
在 Chrome 143 中，您可以选择启用以下新的源试用。
Digital Credentials API（支持签发）
借助此功能，签发网站（例如大学、政府机构或银行）可以安全地启动数字凭证的配置（签发）流程，直接将数字凭证配置到用户的移动钱包应用中。在 Android 上，此功能使用 Android IdentityCredential CredMan 系统（Credential Manager）。在桌面设备上，它使用基于 CTAP 协议的跨设备方法，类似于数字凭据呈现跨设备流程。
TCP 套接字池限制随机化
通过利用 Chrome 上连接池大小的限制，您可以获取有关跨网站状态的知识，而这些知识在其他情况下是无法获取的。具体来说，您可以（在一定统计确定性下）评估登录状态、访问历史记录，甚至更具体的信息，例如 Gmail 收件箱中是否有待处理的邮件。
为了缓解此问题，我们为 TCP 套接字池的限制方式添加了随机化，以便观察网站无法以很高的确定性推断出此信息。
弃用和移除
此版本的 Chrome 引入了以下各部分中介绍的弃用和移除功能。如需查看计划弃用、当前弃用和之前移除的功能列表，请访问 ChromeStatus.com。
此版本的 Chrome 弃用了两项功能
弃用了 Intl Locale Info 的 getter
Intl Locale Info API 是 ECMAScript TC39 提案的第 3 阶段，旨在通过公开语言区域信息（例如周数据 [一周中的第一天、周末开始日期、周末结束日期、第一周中的最少天数]）和语言区域中使用的文字方向小时周期来改进 Intl.Locale 对象。
该实现已在 Chrome 99 中提供。不过，该提案后来在第 3 阶段发生了变化，并将多个 getter 移到了函数中。必须移除已弃用的 getter，并重新启动重命名的函数。
弃用 XSLT
XSLT v1.0 于 1999 年标准化，所有浏览器都遵循此标准。与此同时，XSLT 已发展到 v2.0 和 v3.0，添加了许多功能，并与浏览器中实现的版本有所不同。这种缺乏进步的情况，再加上 JavaScript 库和框架的兴起（它们可提供灵活而强大的 DOM 操作），导致客户端 XSLT 的使用量大幅下降。基于 JavaScript 的技术（例如 JSON 和 React）已在很大程度上取代了它在 Web 浏览器中的作用。
Chromium 使用 libxslt 库来处理这些转换，但 libxslt 在 2025 年大约有 6 个月的时间处于无人维护状态。Libxslt 是一个复杂的旧版 C 代码库，容易受到内存安全漏洞（例如缓冲区溢出）的攻击，这可能会导致任意代码执行。由于客户端 XSLT 现在是一种很少使用的利基功能，因此这些库获得的维护和安全审查比核心 JavaScript 引擎少。不过，它们是处理不受信任的网络内容的直接攻击面。事实上，XSLT 是近期多起重大安全漏洞的根源，这些漏洞仍在威胁着浏览器用户的安全。
出于上述原因，Chromium 计划废弃并从 Web 平台中移除 XSLT。WHATWG 决定提前弃用 XSLT。
如需详细了解弃用情况，以及如果您依赖 XSLT，应该怎么做，请参阅移除 XSLT 以打造更安全的浏览器。