admin管理员组

文章数量:1028042

Chrome 会成为 OpenAI 的下一个目标？

在 weekly.fatbobman[1]订阅本周报的电子邮件版本。访问我的博客 肘子的 Swift 记事本[2]查看更多的文章。加入 Discord[3]社区，与 2000+ 中文开发者深入交流 Swift、SwiftUI 开发体验。

Chrome 会成为 OpenAI 的下一个目标？

美国司法部（DOJ）与谷歌之间的反垄断诉讼近期取得了重大进展。法院认定，谷歌通过将其广告服务器与广告交易平台捆绑销售，以及操控广告拍卖机制等行为，排挤了竞争对手，损害了出版商和消费者的利益。作为补救措施的讨论之一，美国司法部正在考虑建议强制谷歌出售其 Chrome 浏览器，并终止与设备制造商的默认搜索引擎协议。继传闻将以 30 亿美金收购 WindSurf 后，OpenAI 在上述判决之后立刻表达了对 Chrome 的收购兴趣。

如今的浏览器，无论从功能还是规模上来说，都与成熟的操作系统不相上下。市场上看似存在多种不同名称的浏览器，但事实上，很大一部分都基于相同的 Chromium 内核。自该项目启动以来，谷歌一直承担着主要的开发和维护工作。截至 2024 年，Chrome 系浏览器的市场份额已超过 65%，形成了事实上的浏览器标准。

推动谷歌持续投入 Chrome（Chromium）开发的核心动力，来自于其搜索广告模式的商业闭环：更好的浏览体验 → 更多的网络查询 → 更精准的结果投放 → 更高的广告收入。正是在这个内因驱动下，谷歌才不惜投入大量人力和资金发展 Chrome。如果 Chrome 被从谷歌剥离出来，很难想象谷歌还有动力继续支持 Chromium 的开发。对于 Chrome 这种级别的产品来说，仅仅从谷歌挖走一批人才远远不足以维持其目前的发展速度与质量。

更值得深思的是：假设有一家具备维护 Chromium 项目能力的公司接手 Chrome，我们又如何确保它不会利用 Chrome 的巨大影响力建立新的垄断壁垒？不让其利用 Chrome 获取产品之外的商业价值，这家公司又何来继续投入的动力？历史诸多因反垄断而拆分失败的案例历历在目，这恰恰暴露了反垄断执法的两难处境：拆分易，防垄断难。

反垄断机制的核心本应是确保市场竞争的公平性，防止具备垄断地位的公司利用其优势地位打压竞争者。对于谷歌垄断地位的认定，我认为是无可厚非的。然而，推动其剥离 Chrome，真的是解决问题的正确方向吗？或者说，这真能带来更健康的市场环境吗？

坦率地讲，即使 Chrome 最终被迫出售，OpenAI 也绝非一个理想的收购方。这并非我个人的忧虑，网络上已有大量用户表达了对 OpenAI 收购 Chrome 的不安。尽管当前 AI 大模型公司如日中天，但其产品主要仍面向企业或专业领域，尚未真正深入普通消费者的日常生活。因此，它们急需一种能快速触达普通用户并深入绑定的载体，以构建更广泛且牢固的用户联系。

将 ChatGPT 与 Chrome 融合，的确能迅速提升 OpenAI 在普通用户中的影响力。但与此同时，也极可能催生一种前所未见的新型垄断——一个融合先进 AI 技术与海量用户数据入口的超级平台。浏览器不仅是用户进入互联网的门户，更是个人数据的重要入口，而这种结合的影响将远超我们当前的想象。尽管谷歌也具备这种能力，但其广告盈利模式制约了它将 AI 与搜索进行完全整合。

作为一个 90% 时间都使用 Safari 的开发者，我完全赞同对大公司滥用市场优势地位的有效制约，但我并不认为从谷歌中简单地剥离 Chrome 是明智之举，更不希望看到它落入另一个可能建立新型垄断的公司手中。市场真正需要的并不是简单的拆分与重组，而是建立更加开放且具备健康竞争的生态环境。这才是反垄断执法与科技创新之间应当追求的平衡之道。

原创

构建类型安全、高效的 SwiftData/Core Data 模型[4]

Swift 强大的类型系统使我们能够创建语义明确且安全的数据模型。然而，当面对 SwiftData 或 Core Data 时，我们常因底层存储机制的限制，而不得不在类型表达上做出妥协。这种妥协不仅模糊了领域模型的本意，也为应用的稳定性埋下隐患。本文将探索如何在数据持久化的约束下，通过巧妙的类型封装和转换，构建兼具类型安全、语义明确与高效性能的数据模型。

【Tip】解决在 Monorepo 项目中 SwiftLint 配置文件无效[5]

近期推荐

让 NSImage 支持并发安全传递[6]

Swift 6 对并发编程引入了更严格的检查，要求跨线程使用的类型必须是安全可发送的（Sendable）。但 NSImage并不符合这一要求。 Khoa Pham[7]在文中提供了三种应对方式：使用 @unchecked Sendable强制标注、将 NSImage转换为 Sendable 友好的数据（如 PNG 数据或 CGImage）、或通过 Actor 包装来实现线程安全。

用 SwiftUI 自定义 macOS App 的 About 窗口[8]

随着 SwiftUI 在 macOS 上能力的增强，许多专为该平台设计的视图修饰器被引入。本文中，Natalia Panferova[9]详细介绍了如何使用 SwiftUI 构建一个完全自定义的“关于”窗口，并展示了如何应用新特性，如调整工具栏、启用拖动、设置半透明背景、控制窗口按钮、限制窗口大小和关闭位置复原。通过这些步骤，开发者可以全面掌控基于 SwiftUI 的 macOS 窗口外观与行为，使其更好融入应用整体设计。

优雅地解决 Swift 错误处理的历史遗留问题[10]

Swift 的 Error协议底层桥接了 Objective-C 的 NSError，这导致如果开发者没有为错误类型实现 LocalizedError，往往只能看到 (YourError error 0)这样的模糊信息。而由于 LocalizedError中属性为可选，开发者容易遗漏必要声明，造成实际体验不佳。Cihat Gündüz[11]给出了改进方案：定义 Throwable协议，强制每个错误类型提供明确的 userFriendlyMessage。配合他发布的 ErrorKit[12]，开发者可以在保留原生错误处理语法的同时，显著提升错误信息的清晰度、可控性与本地化支持。

摩诃不思议的 Swift[13]

很多人觉得现代强类型语言的设计趋同，只要掌握一门便能快速上手另一门。但实际上，即使是相似概念，不同语言间也存在着巨大的差异。Xheldon[14]在拥有丰富 TypeScript 经验的前提下，学习 Swift 时依然屡屡感到震惊。本文记录了他从注释、可选绑定、集合类型、控制流、闭包、枚举、结构体与类、协议、泛型等各个方面，遇到的 Swift 特有设计与理解过程。

不仅是语言特性比较，也是从另一个角度重新认识 Swift 的机会。

用 SwiftUI 原生集成系统分享面板[15]

分享面板（Activity View）列出了用户在当前上下文中可以执行的一系列操作。早期 SwiftUI 版本需要借助 UIKit 才能调用分享功能，而从 iOS 16 开始，SwiftUI 提供了原生的 ShareLink[16]组件，大幅简化了实现流程。Gabriel Fernandes Thomaz[17]和 Tiago Gomes Pereira[18]在本文中介绍了 ShareLink的基本用法，包括分享 URL、自定义 Label 和 Preview，以及通过 Transferable协议支持自定义类型。掌握这些技巧，可以让应用更好地整合系统分享体验，提升用户操作的流畅度。

Chrome 会成为 OpenAI 的下一个目标？

在 weekly.fatbobman[1]订阅本周报的电子邮件版本。访问我的博客 肘子的 Swift 记事本[2]查看更多的文章。加入 Discord[3]社区，与 2000+ 中文开发者深入交流 Swift、SwiftUI 开发体验。

Chrome 会成为 OpenAI 的下一个目标？

美国司法部（DOJ）与谷歌之间的反垄断诉讼近期取得了重大进展。法院认定，谷歌通过将其广告服务器与广告交易平台捆绑销售，以及操控广告拍卖机制等行为，排挤了竞争对手，损害了出版商和消费者的利益。作为补救措施的讨论之一，美国司法部正在考虑建议强制谷歌出售其 Chrome 浏览器，并终止与设备制造商的默认搜索引擎协议。继传闻将以 30 亿美金收购 WindSurf 后，OpenAI 在上述判决之后立刻表达了对 Chrome 的收购兴趣。

如今的浏览器，无论从功能还是规模上来说，都与成熟的操作系统不相上下。市场上看似存在多种不同名称的浏览器，但事实上，很大一部分都基于相同的 Chromium 内核。自该项目启动以来，谷歌一直承担着主要的开发和维护工作。截至 2024 年，Chrome 系浏览器的市场份额已超过 65%，形成了事实上的浏览器标准。

推动谷歌持续投入 Chrome（Chromium）开发的核心动力，来自于其搜索广告模式的商业闭环：更好的浏览体验 → 更多的网络查询 → 更精准的结果投放 → 更高的广告收入。正是在这个内因驱动下，谷歌才不惜投入大量人力和资金发展 Chrome。如果 Chrome 被从谷歌剥离出来，很难想象谷歌还有动力继续支持 Chromium 的开发。对于 Chrome 这种级别的产品来说，仅仅从谷歌挖走一批人才远远不足以维持其目前的发展速度与质量。

更值得深思的是：假设有一家具备维护 Chromium 项目能力的公司接手 Chrome，我们又如何确保它不会利用 Chrome 的巨大影响力建立新的垄断壁垒？不让其利用 Chrome 获取产品之外的商业价值，这家公司又何来继续投入的动力？历史诸多因反垄断而拆分失败的案例历历在目，这恰恰暴露了反垄断执法的两难处境：拆分易，防垄断难。

反垄断机制的核心本应是确保市场竞争的公平性，防止具备垄断地位的公司利用其优势地位打压竞争者。对于谷歌垄断地位的认定，我认为是无可厚非的。然而，推动其剥离 Chrome，真的是解决问题的正确方向吗？或者说，这真能带来更健康的市场环境吗？

坦率地讲，即使 Chrome 最终被迫出售，OpenAI 也绝非一个理想的收购方。这并非我个人的忧虑，网络上已有大量用户表达了对 OpenAI 收购 Chrome 的不安。尽管当前 AI 大模型公司如日中天，但其产品主要仍面向企业或专业领域，尚未真正深入普通消费者的日常生活。因此，它们急需一种能快速触达普通用户并深入绑定的载体，以构建更广泛且牢固的用户联系。

将 ChatGPT 与 Chrome 融合，的确能迅速提升 OpenAI 在普通用户中的影响力。但与此同时，也极可能催生一种前所未见的新型垄断——一个融合先进 AI 技术与海量用户数据入口的超级平台。浏览器不仅是用户进入互联网的门户，更是个人数据的重要入口，而这种结合的影响将远超我们当前的想象。尽管谷歌也具备这种能力，但其广告盈利模式制约了它将 AI 与搜索进行完全整合。

作为一个 90% 时间都使用 Safari 的开发者，我完全赞同对大公司滥用市场优势地位的有效制约，但我并不认为从谷歌中简单地剥离 Chrome 是明智之举，更不希望看到它落入另一个可能建立新型垄断的公司手中。市场真正需要的并不是简单的拆分与重组，而是建立更加开放且具备健康竞争的生态环境。这才是反垄断执法与科技创新之间应当追求的平衡之道。

原创

构建类型安全、高效的 SwiftData/Core Data 模型[4]

Swift 强大的类型系统使我们能够创建语义明确且安全的数据模型。然而，当面对 SwiftData 或 Core Data 时，我们常因底层存储机制的限制，而不得不在类型表达上做出妥协。这种妥协不仅模糊了领域模型的本意，也为应用的稳定性埋下隐患。本文将探索如何在数据持久化的约束下，通过巧妙的类型封装和转换，构建兼具类型安全、语义明确与高效性能的数据模型。

【Tip】解决在 Monorepo 项目中 SwiftLint 配置文件无效[5]

近期推荐

让 NSImage 支持并发安全传递[6]

Swift 6 对并发编程引入了更严格的检查，要求跨线程使用的类型必须是安全可发送的（Sendable）。但 NSImage并不符合这一要求。 Khoa Pham[7]在文中提供了三种应对方式：使用 @unchecked Sendable强制标注、将 NSImage转换为 Sendable 友好的数据（如 PNG 数据或 CGImage）、或通过 Actor 包装来实现线程安全。

用 SwiftUI 自定义 macOS App 的 About 窗口[8]

随着 SwiftUI 在 macOS 上能力的增强，许多专为该平台设计的视图修饰器被引入。本文中，Natalia Panferova[9]详细介绍了如何使用 SwiftUI 构建一个完全自定义的“关于”窗口，并展示了如何应用新特性，如调整工具栏、启用拖动、设置半透明背景、控制窗口按钮、限制窗口大小和关闭位置复原。通过这些步骤，开发者可以全面掌控基于 SwiftUI 的 macOS 窗口外观与行为，使其更好融入应用整体设计。

优雅地解决 Swift 错误处理的历史遗留问题[10]

Swift 的 Error协议底层桥接了 Objective-C 的 NSError，这导致如果开发者没有为错误类型实现 LocalizedError，往往只能看到 (YourError error 0)这样的模糊信息。而由于 LocalizedError中属性为可选，开发者容易遗漏必要声明，造成实际体验不佳。Cihat Gündüz[11]给出了改进方案：定义 Throwable协议，强制每个错误类型提供明确的 userFriendlyMessage。配合他发布的 ErrorKit[12]，开发者可以在保留原生错误处理语法的同时，显著提升错误信息的清晰度、可控性与本地化支持。

摩诃不思议的 Swift[13]

很多人觉得现代强类型语言的设计趋同，只要掌握一门便能快速上手另一门。但实际上，即使是相似概念，不同语言间也存在着巨大的差异。Xheldon[14]在拥有丰富 TypeScript 经验的前提下，学习 Swift 时依然屡屡感到震惊。本文记录了他从注释、可选绑定、集合类型、控制流、闭包、枚举、结构体与类、协议、泛型等各个方面，遇到的 Swift 特有设计与理解过程。

不仅是语言特性比较，也是从另一个角度重新认识 Swift 的机会。

用 SwiftUI 原生集成系统分享面板[15]

分享面板（Activity View）列出了用户在当前上下文中可以执行的一系列操作。早期 SwiftUI 版本需要借助 UIKit 才能调用分享功能，而从 iOS 16 开始，SwiftUI 提供了原生的 ShareLink[16]组件，大幅简化了实现流程。Gabriel Fernandes Thomaz[17]和 Tiago Gomes Pereira[18]在本文中介绍了 ShareLink的基本用法，包括分享 URL、自定义 Label 和 Preview，以及通过 Transferable协议支持自定义类型。掌握这些技巧，可以让应用更好地整合系统分享体验，提升用户操作的流畅度。

本文标签： Chrome 会成为 OpenAI 的下一个目标

版权声明：本文标题：Chrome 会成为 OpenAI 的下一个目标？ 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://it.en369.cn/jiaocheng/1747482852a2168416.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。