Chrome 141 于 2025 年 9 月 30 日进入稳定通道,带来一系列针对 Web 平台的改进与新特性,覆盖 CSS、DOM、媒体能力、存储、性能与安全等多方面。对于前端开发者、无头服务、实时通信工程师和安全工程师而言,理解这些变更能帮助优化兼容性、提升性能并减少潜在安全风险。下面将从要点入手,结合实现细节与迁移建议,帮助你在项目中更快地采用或适配 Chrome 141 的新能力。 在样式与渲染层,Chrome 141 修复了 getComputedStyle 在枚举自定义属性时的缺陷 - - 此前对自定义 CSS 变量的迭代会遗漏这些属性,导致返回对象的 length 计算不准确。该问题已在本版本中修复,使得在运行时读取并遍历计算样式时可以可靠地获得所有自定义属性。对依赖动态样式检查或样式分析工具的工程团队,这意味着对样式表或运行时注入变量的检测脚本将更稳定,避免了因遗漏自定义属性而导致的渲染或逻辑分支错误。
建议在检测浏览器行为或 polyfill 时优先检查用户代理和特性检测,而非通过硬编码 UA 字符串判断版本。 可访问性方面,Chrome 141 引入了 ariaNotify JavaScript API。ariaNotify 允许开发者直接向屏幕阅读器发送文本通告,而不必依赖传统的 ARIA live region 的 DOM 变更触发方式。相比 ARIA live,ariaNotify 更可控、可靠,适用于需要在复杂单页应用或动态交互中主动告知用户状态变化的场景。例如,当应用完成长耗时任务、或者需要在 iframe 内部给屏幕阅读器用户反馈时,ariaNotify 可以降低遗漏通知的概率。需要注意的是,iframe 对该功能的使用可以通过 aria-notify 权限策略进行限制,在设计跨域或第三方嵌入组件时应评估权限边界与用户隐私。
与页面加载和展示相关的隐式行为也有细微但重要的变化。hidden=until-found 与 details 元素的揭示算法在规范层面进行了调整,以避免在某些递归或复杂 DOM 结构中出现无限循环卡死的情况。虽然通常用户不容易触发该边缘情况,但对库作者与组件框架维护者而言,这个修复提高了稳定性并减少了复杂场景下的渲染死锁风险。建议通过测试套件覆盖包含 nested details 和 hidden=until-found 的组合组件,以便提早发现潜在问题。 在实时通信与媒体功能方面,Chrome 141 做了若干重要更新。RTP 统计对象的创建时机现已与规范对齐。
对依赖 WebRTC 性能监控与统计的系统来说,这意味着统计数据的生命周期和触发点更加一致,便于与其他浏览器进行行为对比与跨浏览器指标对齐。此外,WebRTC Encoded Transform V2 正式与规范保持一致,修复了此前早期实现与标准之间的差异,使得基于编码后流的自定义处理(例如硬件编解码流水线、第三方转码或分析)在多浏览器环境中更可移植。需要注意的是,generateKeyFrame 方法仍在讨论阶段,若你的流程依赖该功能,应关注后续规范更新与浏览器路标。 在 getUserMedia 的约束集上,echoCancellation 的扩展为 "all" 与 "remote-only" 两个新选项提供了更细粒度的回声消除控制。对于需要微调麦克风回声抑制策略的音频工程师或会议应用,这能帮助在保留某些系统回放信息与提升语音清晰度之间做出权衡。与此同时,捕获显示媒体相关的限制属性中添加了 restrictOwnAudio,和将 windowAudio 扩展到 getDisplayMedia 的能力,为屏幕共享场景提供了更多用户体验控制。
restrictOwnAudio 在捕获表面自带系统音频时生效,可用于限制应用捕获本地系统音。windowAudio 允许将 hint 提供给 UA,以决定在用户选择窗口时是否提供音频共享选项,可选值包括排除系统音、仅窗口音或包含系统音。对于那些既要录制屏幕又要控制音频来源的产品,这些参数能显著改善隐私与体验。 媒体能力更新还包括对索引数据库和缓存的优化。IndexedDB 新增了 getAllRecords() 方法,并为 getAll() 与 getAllKeys() 增加了 direction 参数。getAllRecords() 通过同时枚举主键与值,简化了获取记录列表的流程,并在某些真实业务场景中带来显著性能提升。
对大型离线优先应用或需要频繁批量读取数据的产品,使用 getAllRecords() 能减少游标迭代带来的开销。对于依赖旧式游标遍历的代码,可考虑优先检测特性支持并采用更高效的读取路径,同时保持对不支持该方法的浏览器的回退策略。 HTTP 缓存层也获得了 No-Vary-Search 的磁盘缓存支持。No-Vary-Search 允许服务器声明哪些查询参数不会影响资源结果,从而让多个 URL(仅查询参数不同)共享同一个缓存条目。这个特性在典型的场景中非常有用,例如 URL 中的跟踪参数或一次性标识字段不应触发新资源请求。Chrome 141 将 No-Vary-Search 的支持扩展到通用 HTTP 磁盘缓存,意味着更多基于磁盘缓存的场景能够通过服务端设置减少重复网络请求,节省带宽并提升回访性能。
在使用该特性时,务必确保声明的查询参数确实不会改变资源的可见内容或副作用,以免缓存过期带来错误数据。 性能相关的另一个改进是桌面端 speculation rules 的 "eager" eagerness 调整。在鼠标悬停触发预取或预渲染的时间上,eager 现在会比 moderate 更早启动,但又不至于像 immediate 那样尽早触发。对内容提供者而言,这意味着对未来页面进行预先加载的时机更贴近作者意图,有助于在用户有较高转化意图时提升响应速度,同时避免过度预取带来的资源浪费。建议基于用户行为数据与成本分析来调整 speculation rules,并监控预取带来的负载与带宽影响。 安全性方面,Storage Access API 的语义调整强化了与同源策略的一致性。
document.requestStorageAccess() 在嵌入框架调用时,现在默认只将 cookie 附带到 iframe 的 origin,而非更宽泛的 site 范围。对依赖跨站点第三方 cookie 的旧式集成或广告身份解决方案,这一更改会强制开发者采用更明确的授权策略或使用 CookiesAllowedForUrls 政策、Storage Access Headers 作为替代路径。总体上,这一改动是为了减少跨站点跟踪的滥用风险,提高用户隐私保护。建议评估第三方服务的依赖关系并尽量迁移到安全上下文或使用站点级允许清单来管理例外。 Signature-based Integrity 是本版本引人注目的安全与供应链防护功能之一。它允许服务器使用 Ed25519 密钥对响应进行签名,客户端可以通过声明希望使用的公钥来验证资源的来源与完整性。
与 URL 基于的 CSP 和内容哈希的 Subresource Integrity 不同,Signature-based Integrity 提供了基于签名的可验证来源证明,适合在依赖第三方资源或 CDN 时建立更高层次的信任链。对开源库托管、供应链攻击缓解和受信任内容发布场景尤其有价值。实现时需要关注密钥管理、签名策略和回退机制,以避免因密钥轮换或签名失效导致资源不可用。 内容安全策略方面,Chrome 141 引入了对扩展 CSP script-src 的支持,也称为 script-src-v2。该扩展允许通过新的关键字对基于 URL 的哈希以及 eval() 和类似函数的内容哈希进行允许列表配置。对使用大量动态脚本、频繁更新脚本内容或者在受控环境中使用可控 eval 场景的开发者,script-src-v2 提供了更灵活的安全策略:可以精确允许特定 URL 的脚本或明确允许已知安全的 eval 内容,而不会开放全部 eval 行为。
升级安全策略时应逐步验证并确保在不支持该扩展关键字的浏览器中仍能维持合理的安全姿态。 对于需要证明身份或与移动钱包交互的 Web 应用,Digital Credentials API 的演进是一个重要信号。Chrome 141 引入了对 Android IdentityCredential CredMan 系统的集成路径,使网站可以从移动钱包中请求身份信息,并以可扩展的格式支持 ISO mDoc、W3C 可验证凭证等多种格式。该机制还在设计上考虑到限制生态级滥用的手段。对需要现实世界身份验证的应用(如金融、出行或政务系统),Digital Credentials API 提供了更流畅的用户体验与更高的互操作性,但同时也要求开发者在隐私、数据最小化与同意管理方面负起更多责任。 导航 API 的 precommit handler 功能为导航拦截提供了更大灵活性。
通过向 navigateEvent.intercept() 传入 precommitHandler,开发者可以在导航真正提交之前异步处理任务,并在处理完成后对导航的 URL、状态或历史行为(push/replace)进行修改。对于需要在导航前进行身份验证、数据同步或复杂路由决策的单页应用来说,这个能力能显著提升控制粒度。实现时需要注意避免长时间阻塞导航以免影响用户体验,并针对低带宽和离线场景设计降级策略。 联邦式认证 FedCM 在账户选择界面上新增了使用电话和用户名作为可选字段,这为没有或不愿透露邮件地址的用户提供了更多灵活性。网站可以控制在披露文案中如何呈现这些字段,从而在隐私与可用性之间取得平衡。建议在实现 FedCM 时,合理测试不同标识字段组合对用户理解与转化率的影响。
Chrome 141 还引入了多个面向实验与评估的 origin trial。包括对在非安全上下文中发起的本地网络访问请求进行临时放行,以便开发者有时间迁移到安全上下文;Proofreader API 的试验允许网页提供基于模型的文本校对建议;WebAssembly custom descriptors 的试验用于更高效地在 WebAssembly 对象上存储源级类型相关数据并配置原型链等。参与 origin trial 可以帮助早期获取能力与反馈,但也需要注意试验期满或策略变更时的应对计划。 此外,对管理型 ChromeOS 的增强包括为 Device Attributes API 引入权限策略及相关企业策略项,使得在托管环境中对设备属性访问有更严格的控制。这对 Kiosk 应用或托管的隔离 Web 应用尤为重要。 最后值得关注的弃用与移除项是对 Purpose: prefetch 头部的逐步停用。
由于预取相关场景已经改用 Sec-Purpose 头部,旧的 Purpose: prefetch 将被移除。依赖旧头部的服务器或代理应尽快切换到标准化的 Sec-Purpose,以避免未来兼容性问题。 如何在工程中应对 Chrome 141 的变化?首先,采用特性检测优先于浏览器版本判断,使用 capability detection 来决定是否启用新 API。其次,对于可能影响用户隐私的改变,例如 Storage Access API 的同源策略调整、windowAudio 与 restrictOwnAudio 的音频控制、Digital Credentials 的身份处理,应进行隐私影响评估与明确的用户同意流程。在性能方面,对 IndexedDB 的新方法和 No-Vary-Search 的缓存策略进行 A/B 测试,量化真实用户的性能提升与资源占用变化。对于安全性增强(如 Signature-based Integrity 和 script-src-v2),需要与后端和运维团队协调密钥管理、签名流程与 CSP 头部的生成逻辑。
总的来说,Chrome 141 在兼容性修复、可访问性、媒体控制、存储性能与安全防护等方面都做出了明确的改进。对于希望提供更安全、更高效与更具可访问性体验的开发团队,这一版本提供了值得采纳的新工具与策略。建议在 CI 测试中引入基于 Chrome 141 的回归测试用例,使用真实用户监测指针(RUM)观测变更对性能的实际影响,并逐步在生产环境中启用新能力。 要获取更多细节,可参考 Chromium 的跟踪问题与规范链接,关注 ChromeStatus 更新,并在本地或测试环境中验证关键路径的行为变化。通过有计划的评估与渐进式部署,你的产品可以更平滑地拥抱 Chrome 141 带来的改进,同时降低兼容性与安全风险。 。
