浏览器和搜索引擎

一篇有关浏览器和搜索引擎的杂谈。

截至2025-12-30。

浏览器概述

既生Firefox，何生Chromium？

自己用过的浏览器也算比较多了，在Firefox和Chrome生态中间反复横跳了很久之后，现在暂时是落入了Firefox的一极。正好现在AI浏览器概念开始发力，就趁着这个机会写一篇和浏览器有关的杂谈好了。

基本是围绕Chromium系（Blink）和Firefox系（Gecko）展开的，因为自己的设备生态确实没有苹果，就不聊Safari了。

我们关心什么？

在谈论一个浏览器的时候，我们往往会关心以下的几个角度：

• 兼容性
• 稳定性能
• UX
• 扩展生态
• DevTools
• 隐私/安全

其中UX、扩展生态、DevTools没有什么特别好说的。UX描述了一个浏览器的易用性，包括界面布局和可定制性、美观度；扩展生态描述了浏览器的开源插件的丰富性和兼容性，几乎是Chrome一家独大，Firefox其次；DevTools主要面向开发者，包括调试工具、性能分析、网络请求监控等功能。

而隐私/安全在我这里排在最后，一方面，例如教育、医疗、金融领域，广告信息随着身份标识走，隐私泄露几乎已经常态化；另一方面，按《中华人民共和国网络安全法》第二十四条规定，“应当要求用户提供真实身份信息”，平台登陆和手机绑死，会出现“有账密也登不了”的情景，用户“不那么担心被盗”的问题。——我认为“对于自己而言，隐私/安全是最不重要的一环”——当然，这不是说随便泄露隐私就可以，我的意思是，一个浏览器的隐私防护如果在平均线水平以上，那基本就算是我可以接受的水平，而更强的隐私防护我似乎就没有那么需要了。

兼容性

浏览器的兼容性通常被理解为“页面能不能正常打开”，也就是页面是否能够被正确渲染、布局是否正常、交互是否可用。大多数用户并不会关心页面是否严格遵循HTML或CSS规范，而只关心一个现实问题：这个网站在我这里能不能用。

通常来说，我们会认为Chrome的兼容性最好，甚至很多网站会直接提示“推荐使用Chrome浏览器”。从结果上看，Chrome的确更少出现样式错乱或功能失效的问题。

这种“兼容性优势”并不完全来自对Web标准的更好实现，Firefox对Web规范的遵循反而更加严格。Mozilla长期参与W3C与WHATWG的标准制定过程，Firefox在实现HTML、CSS和JavaScript时，更倾向于按照规范文本中明确描述的行为来执行。

当标准尚未定稿，或者规范存在模糊空间时，Firefox通常会选择延迟实现，避免自行定义行为。这种策略在规范一致性和长期可维护性上是合理的。Chromium往往会率先实现尚处于提案阶段的API，甚至引入只在Chromium体系中存在的专有接口。随着Chrome市场占有率的提高，这些实现逐渐被开发者、第三方库和框架当作事实标准来使用。当页面逻辑或库代码直接依赖这些非规范行为时，其他浏览器即便严格遵循规范，也可能表现为“不兼容”。此时的问题并不是Firefox缺少功能，而是它没有复制Chromium的非规范行为。这一问题在MDN的这篇文章中有报告，超过40项Chrome专有API在Firefox中需通过兼容层模拟，且部分行为存在差异。而开发者和三方库使用了很多的Chrome API，这可能导致代码在Firefox中无法正常运行。

这一现象在“老式页面”中尤为明显。许多学校、企业或内部系统使用的是早期PHP、ASP等技术栈，页面往往由非专业前端人员维护。这类页面常见的问题包括：使用浏览器嗅探（user agent sniffing）来分支逻辑、依赖早期IE或Chrome的DOM行为、混用非标准事件模型，甚至把某些浏览器的bug当作稳定特性使用。由于这些系统后续维护成本高、更新频率低，开发者往往只在Chrome上验证可用性，最终演变为“只能用Chrome打开”的结果。

性能

浏览器的性能主要描述了浏览器的使用体验，核心的指标包括了页面的加载和渲染速度、内存占用（尤其是多页面下的内存占用）。

Chromium内核比较“重”，它事实上确实很吃内存。从其底层设计来思考，主要因为多层次的模块化与进程划分带来的代码与运行时状态复制。Chromium把渲染（Blink）、脚本执行（V8）、网络（Network Service）、GPU合成等拆成独立模块并倾向于放到不同进程里运行，因此每个标签页/站点实例会带来独立的渲染器进程、自己的V8堆、各自的渲染树副本和渲染层状态。再加上为兼容现实Web而保留的大量专有API、兼容shim与扩展宿主环境（chrome.* API、扩展后台页、content scripts等），引擎在运行时要维护更多的状态、更多的线程与更多的缓存（比如预编译代码缓存、JIT优化数据、层合成缓存、预取队列），这些都会直接反映为更高的基线内存占用和更多的驻留对象。

不过，性能问题并不是完全取决于浏览器。例如，现代前端框架（如Vue.js、React.js）在首屏阶段常常需要下载并执行大量的运行时代码：打包输出的体积、polyfill和兼容层、框架的运行时初始化、虚拟DOM的首轮构建与差分算法，这些都在主线程上消耗时间并阻塞渲染。即便浏览器的渲染流水线和JIT做得再好，大量同步的脚本执行、长任务阻塞主线程和频繁的强制布局（reflow）仍然会导致用户感知的“卡顿”。换言之，首屏慢很多时候是由打包策略、代码分割（或缺乏）、资源优先级设置不当以及第三方脚本的阻塞行为决定的，而非浏览器内核单方面的低效。

在多标签场景下，Chromium式的进程隔离能在崩溃或安全事件时保护其他标签，但这也意味着在同时打开大量标签时会出现多个重复的运行时实例与内存副本。为了在资源受限时生存，浏览器会引入后台标签冻结、标签页休眠与丢弃策略：休眠可以通过释放渲染器内存、停止计时器与暂停脚本来节省资源，但切回标签时必须恢复执行上下文，可能需要重新加载或重新初始化大量JS状态，产生明显延迟。冷加载与恢复机制会依赖缓存层（HTTP 缓存、service worker 缓存）与内核的进程池策略：如果一个被丢弃的标签需要重建渲染器进程，V8的初始化与JIT冷启动代价会让恢复比保留进程更慢；如果内核使用进程复用或代码快照，则能缓解部分冷启动开销，但这些机制本身也需要额外的内存或磁盘缓存空间。

网络层面的差异会直接改变加载感知。浏览器并非单纯调用操作系统的socket，而是在内核内实现连接管理、请求优先级、连接复用（HTTP/2、QUIC）、资源预取与预连接等功能。一个浏览器可能激进地做preconnect、prerender或speculative prefetch来缩短延迟，但这些行为会消耗带宽与打开第三方连接，有跟踪风险；另一个浏览器出于隐私考虑会限制或延迟这些预热行为，从而在隐私与性能之间做出不同的取舍。此外，现代浏览器还在缓存策略、第三方资源隔离（storage partitioning）和DNS策略（如DoH）上各有实现：分区缓存或严格的第三方请求控制可以阻止跨站追踪，但也可能让重复资源无法跨站重用，影响加载效率；使用DoH可以提高隐私但在某些网络路径上可能增加解析延迟。不同浏览器在这些网络与路由层面的实现，正是“性能与隐私”相互博弈的具体体现。

一些浏览器的使用感受 & 搜索引擎？

我自己算是轻度开发者，不那么看规范，还是更注重实际的使用体验一些，就目前来说，主要使用过Chromium系（Chrome、Edge、Kiwi）、Firefox系（Firefox、Firefox Beta、Waterfox）、WebView系（Via）；目前主力使用的是Waterfox（PC、日常）、Chrome（PC、debug）、Firefox Beta（Android、日常）、Via/Kiwi（Android、日常）。

Microsoft系生态

首先，排除Bing国内特供的那个版本，虽然比百度好点但也还是很烂，不好用。预防措施是自行切代理，一旦发现你代理在国内就会重定向回去无解（dns感觉用处不大，伪装请求头貌似也不大好用）。

Edge转向Chromium内核之后，性能确实有提升，平时自己也是会使用Bing作为主力搜索引擎，但是强绑定Edge（尤其是手机版本），用其他浏览器搜的时候弹个弹窗刷脸上很烦；在PC端也是如此，Edge总会想让你把它设置成默认浏览器，这种偏流氓软件的做法让我很反感。另外Bing加入AI之后，搜索的质量个人感觉有一定下滑。

综合以上因素目前是只用Bing，没用Edge。

Google系生态

Chrome作为Chromium内核的代表，性能与稳定性都很好，同步比较方便（尤其是密码同步和书签同步），有着庞大的插件体系，做开发的时候基本也是优先使用Chrome（原因上面已经说了）；Google的搜索和Bing半斤八两吧，虽然索引还比较全但是有时候就是搜不到想要的东西，并且强推AI比较烦，比Edge好一点没强推Chrome。

另外Chrome比较大的一个问题是太重，占用内存还是比较多，所以后面就转回Firefox家族了。

Mozilla系生态

Firefox用的时间也很长，除了一些兼容性问题（也是最近才了解到原来是这个原因），整体的体验还是不错的，侧栏用起来很爽，虽然插件市场不如Chrome丰富但也相当够看；一方面Firefox生态也可以做同步。手机上用的是Firefox Beta，电脑之前用过一段时间Beta和Nightly，主要是更新太频繁了（基本上隔几天开浏览器就要像Steam一样强制吃一次更新），因为自己开发需求没那么大所以就没用了。Firefox虽然不如Chrome吃内存但也还是有点卡卡的，有时候得用Firemin降一下内存。

相比之下，也用过Firefox的其他分支，比如Zen，但Zen太过于注重隐私导致核心功能缺失用起来比较不爽，而且偏卡。最近是用上了Firefox的另一个支Waterfox，感觉比Firefox流畅很多，而且核心功能基本没有太大的变化，打算用一阵子看看。

其他

Via、Kiwi这俩都是我手机在用的浏览器，Kiwi是基于Chromium的，整体比较轻，Via的话基于Webview更是轻的离谱。两者我基本都是不登录不同步随便查点什么东西用的，目前感觉还不错。

AI搜索和AI浏览器

目前是AI搜索用过一些，AI浏览器没用过，最近是有看到Google和Firefox集成AI进去，Google是推出了实验性的AI浏览器Disco。

AI搜索的上限

AI搜索并没有让搜索变得更好用，相反，它让搜索变得“懒惰”。

从技术角度来说，AI搜索无非就是两件事：生成关键词和生成搜索结果。生成关键词是基于用户输入的，通过已有的内容去“猜”用户想要去搜什么；生成搜索结果则是得到了搜索结果，通过用户画像排序，再把爬到的结果整理成一份有序的文本。

生成的关键词取决于用户使用搜索引擎的熟练程度（如使用正则、约束）和生成AI的算力，从目前的情况来看，搜索引擎倾向于让用户变“懒”，而不充分的上下文能产生的关键词是AI导向而非用户导向，“用户搜不到想要的东西，自动补全瞎脑补”就是很自然的事情。

生成搜索结果取决于索引、用户画像和AI，但由于生成式AI的“自产自销”和SEO，索引的质量事实上在变差，且未来只会越来越差。面对一个搜索的主题，不妨假设一个百万量级的上下文，然后AI要对这些上下文进行索引、排序，在几秒内整理成一个简明、没有事实性错误的搜索结果，即便算力能够实现，成本我认为依旧是不可接受的，那么这就会导向以下的几种可能：

• 缩短上下文——即只接受排在前面一些的数据，索引的质量已经不高了，再由AI加工一道只会更差
• 降低AI思考的时间——我们依旧得不到好的搜索结果
• 提高用户的搜索成本——即用户要为搜索行为买单

发现了吗，问题出在索引，如果索引清洗不够，那么AI生成的搜索结果就无法保证质量；而索引清洗又越来越多地交由AI完成，搜索质量也只会越来越差。AI搜索的上限，其实并不像我们所想象的那样取决于AI，提高AI的算力和水平我认为不能从根本上解决搜索结果变差的问题，互联网上平均质量的下滑，只倒逼使用搜索引擎的人使用更加复杂的方法去搜索，形成了知识的怪圈（要搜到相关的内容，你得“知道”相关的内容）。

AI浏览器

AI浏览器的核心理念是将大模型能力深度集成到浏览行为中，以任务完成取代信息检索。Google 2024年推出的试验性Disco浏览器即典型：它不提供传统地址栏和搜索框，而是让用户直接输入自然语言目标（如“帮我订下周去东京的cheapest航班”），由内置AI自动解析意图、调用多个网站API、聚合结构化结果并执行操作。这种设计隐含“搜索引擎中介可被绕过”的逻辑——浏览器自身成为信息调度与决策代理。

除了上面所述的，索引这一底层逻辑的质量得不到保障，AI搜索就无法发力以外，AI浏览器仍然具有垄断和越权问题。它如果成为互联网上的唯一入口，就会垄断用户的搜索和浏览行为，从而控制了互联网上的信息流和流量，对市场竞争和用户隐私构成威胁；此外，和AI手机一样，AI浏览器具有越权问题，假设一个平台需要用户登陆才能访问，用户就需要授予浏览器账户的权限，这是极具风险的操作，当这一操作涉及资金流，例如“买一张机票”，问题就变得更加严重，从用户的层次来看，用户无法确定AI被赋予权限后有没有在后台“偷偷摸摸”利用权限做其他事情。

总而言之

AI并没有从根本上解决搜索和浏览长期存在的结构性问题，反而把这些问题前置并放大了。

AI搜索试图用生成能力弥补索引质量下滑，但索引本身的退化、SEO 污染和内容平均质量下降，使得“更聪明的整理”建立在越来越不可靠的原材料之上；当上下文被压缩、推理时间受限、成本需要控制时，生成结果不可避免地趋向于表层化和同质化。AI浏览器则进一步将“查找信息”转化为“代替用户行动”，在技术上确实提高了任务完成效率，但同时也将浏览器从一个中立的执行环境，推向了高度集权的决策代理：它更容易形成入口垄断，更深度地介入用户行为，并在权限、责任与可审计性上留下难以回避的风险。在这种背景下，AI更像是对既有搜索与浏览生态的一次加速器，而不是一次范式重建；它看似能改善局部体验，但不能改变索引、内容生产和分发机制，很难说它会让“搜索”这件事真正变得更可靠。