给Agent配浏览能力这件事，我之前一直用headless Chrome硬扛。手上那台1核2GB的Ubuntu小机跑着几个定时抓取任务，每次Chrome起来，free -m 掉到100MB出头的可用内存，多开两个任务就得考虑先后顺序。前几天Lightpanda刷屏的时候------就是那个用Zig从零写的无头浏览器，掘金热榜和HN都在转------README里那行"16x lighter and 9x faster than Chromium"我没直接信，因为官方基准是AWS m5.large上爬933个页面的聚合数字，跟我这种2GB小机跑零散任务的场景差得远。
正好手头环境现成，我把它跟Chrome在同一台机器上跑了一遍。结论先放这：省内存是真的，我量出来约14倍，跟官方16倍是一个量级；"9倍快"在我这个场景没复现------网络瓶颈的页面两边打平，CPU吃得重的页面Lightpanda快1.5到2倍；最值得说的是一个README里没写的坑------它的并发模型跟Chrome完全不同，代码直接迁会翻车。
先跑起来：比想象的顺利
安装就是官方README那三行，nightly二进制直接下：
bash
curl -L -o lightpanda https://github.com/lightpanda-io/browser/releases/download/nightly/lightpanda-x86_64-linux \
&& chmod a+x ./lightpanda
./lightpanda version
# 1.1.0-nightly.11795+277beb9c7README里有个容易漏的点：Linux版二进制链接glibc，要求x86_64至少2.35。我这台Ubuntu 22.04恰好是2.35，压线过。你要是跑Alpine（musl）会直接cannot execute: required file not found，这一点比Chrome娇气。
起CDP服务一行命令，Playwright当客户端连上去就能用：
css
LIGHTPANDA_DISABLE_TELEMETRY=true ./lightpanda serve \
--host 127.0.0.1 --port 9222 --log-level error
css
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
browser = p.chromium.connect_over_cdp("http://127.0.0.1:9222")
ctx = browser.new_context()
pg = ctx.new_page()
pg.goto("https://quotes.toscrape.com/js/", timeout=30000, wait_until="load")
# 这个页面的引言全靠JS注入，能拿到35个链接说明V8真跑了
print(pg.evaluate("document.querySelectorAll('a').length")) # 35
pg.close()
browser.close()到这一步都没踩坑。JS渲染也验证了：quotes.toscrape那个靠JS注入内容的页面，35条引言链接全部拿到；react.dev这种SPA也能正常挂载，2.4秒返回的h1是"React"而不是空壳。内置V8这件事它是认真的。
内存：14倍，跟官方说的16倍对上了
内存测试我用的是最笨但最诚实的办法：读/proc/<pid>/status里的VmRSS。Lightpanda是单进程，直接读；Chrome是多进程，主进程加所有子进程累加。两边打开同一批页面，每个页面记录加载耗时和瞬时RSS。 结果比我预期还夸张。Lightpanda空载12.2MB，处理页面时的峰值43.4MB。Chrome headless跑完同样一轮后，进程组驻留469.6MB，单页峰值干到605.4MB------别忘了这是加了--disable-gpu --disable-dev-shm-usage的精简参数。 605.4除以43.4，约14倍。官方说16倍，考虑到官方是100页并发的爬虫场景（Chrome的多页签内存会随页数膨胀得更狠），我这单页顺序处理的14倍算是给16倍做了个交叉验证：这个数字不是营销，量级是真实的。 对你来说这个数字的实际意义取决于你跑在什么机器上。官方那组"100页峰值123MB vs 2GB"翻译一下：一台2GB的小机，Lightpanda理论上能同时伺候几十个页面，Chrome连零头都塞不下。
速度：那个"9倍"要看场景
耗时对比就现实得多。同一批页面两边各跑一遍：
| 页面 | Lightpanda | Chrome headless |
|---|---|---|
| demo站campfire-commerce（JS电商页） | 1.7s | 3.45s |
| quotes.toscrape.com/js/（JS注入页） | 2.42s | 4.21s |
| example.com | 1.14s | 1.16s |
| books.toscrape.com（1000+条目列表页） | 13.88s | 14.33s |
| python.org | 10.95s | 超时30s失败 |
规律很清楚：凡是CPU主导的页面（JS执行、DOM构建），Lightpanda快1.5到2倍；凡是网络主导的页面，两边打平。books.toscrape那14秒纯粹是我这台小机出海带宽慢，换什么浏览器都一样。官方的"9倍快"是933页连续爬取的聚合值，无渲染开销会累积，单页场景复制不出来，这个预期要先摆正。
还有个反直觉的：python.org这个页，Lightpanda 11秒正常返回，Chrome直接30秒超时失败。我一开始以为Chrome那边抽风，重跑了一次还是超时。合理解释是Chrome要加载全量CSS和图片资源，在这个带宽下撑破了超时窗口，而Lightpanda根本不下载不渲染这些资源，只拉DOM和JS需要的东西。慢网络环境下这个差异反而是Lightpanda的主场。 （HN、Wikipedia、go.dev三个站两边都超时了，那是我云机的网络问题，跟工具无关，从样本里剔了出去。）
真正的坑：并发模型跟你想的不一样
内存测试跑得顺，我心想核心数据都拿到了，接下来把多页签并发跑一遍就齐活。结果第一行代码就翻车------这段脚本开到第二个页面时报错：
go
BrowserContext.new_page: Protocol error (Target.createTarget): TargetAlreadyLoaded我以为是Playwright连CDP的姿势问题，换了三种写法：默认context里连开多页、一个context里开完关掉再开、开多个context各跑各的。前一种报上面那个错，后两种更直接：
less
Browser.new_context: Protocol error (Target.createBrowserContext):
Cannot have more than one browser context at a time这个报错是Lightpanda服务器端明确返回的，不是Playwright的猜测。也就是说它的并发模型是：一个CDP连接只允许一个browser context，一个context同时只允许一个活页面。想顺序抓取没问题------开一个页面、抓完、关掉、再开下一个，10个页面能全跑完------但"同时挂10个页签"这种Chrome上的常规操作，它现在就是不做。
我去翻了serve的CLI参数想确认是不是配置问题，--cdp-max-connections默认16，连接数根本不是瓶颈，就是context和target的实现现状。官方文档的定位也印证了这一点：它给自己的标签是"designed for AI and automation"，抓取、表单、内容提取都是单页任务流，没有承诺过Chrome那种多tab工作区。
想并发怎么办？多开几个serve进程，一个进程一个端口一个页面。按我实测的内存数字算笔账：空载12MB、峰值43MB，起10个实例峰值也就430MB左右，2GB机器毫无压力------Chrome单实例挂3个页签，进程组就涨到862MB，再开第4个时资源耗尽直接失败。所以内存优势在并发场景依然成立，甚至更成立，但代价是你的调度代码要从"一个browser对象开N个page"改成"管理N个独立进程" ，进程健康检查、端口分配、故障重启这些都得自己补。这不是改两行配置的事，是架构层面的迁移成本。
还有一条边界：canvas和图形场景别碰
这个不用多测，一句话带过：Lightpanda没有图形渲染，echarts官方示例页我加载了20.8秒，document.querySelectorAll('canvas')返回0，图表画布根本没出现在DOM里。截图、可视化验证、任何依赖canvas/WebGL的页面，这条路走不通。纯文本抓取和表单自动化才是它的主场。
所以要不要换
我的建议不绕弯。要给Agent或爬虫配"读网页"的能力，机器又小，那就迁，内存收益是实打实的两位数倍率，JS渲染也够用。手里已有大把browser.new_page()开页签并发的代码？先别急着换，把进程架构怎么改想清楚再动手。至于图表截图给人看的场景，别折腾了，Chrome还是唯一解。