Servo 0.7.0 收进 527 个提交，Rust 浏览器引擎更新多项 Web 功能

Servo 0.7.0 收进 9 月的 527 个提交

Servo 0.7.0 是 Servo 浏览器引擎的新版本，官方博客显示它包含了 2026 年 9 月合入的全部改动，共计 527 个提交。博客发布于 2026-11-05。HimikoTogaFromUSSR 在 11 月 6 日把 Phoronix 的报道发到 r/rust，采集时获得 187 分、18 条评论。GitHub release 也确认 v0.7.0 已经就绪，内容就是 9 月的改动。crates.io 上的 servo crate 版本为 0.7.0，最低 Rust 版本 1.88.0，许可证 MPL-2.0。

新合入的网页平台功能包括 :checked 伪类、user-select、<progress>、CSS typed arithmetic、alpha() 和 font-width。DOM 侧加入了 Selection 的 getComposedRanges() 和 direction、CSS modules 和 text modules、Canvas 的 roundRect()、VTTCue 的 getCueAsHTML()，以及 WebCrypto 的 MLKEM768-X25519。开发者工具控制台现在会提前求值 JS 输入。安全更新把 SpiderMonkey 升到 v153.3，mozangle 升到 v0.7，两边都带上了上游报过的安全修复。

兼容性方面有两个例子：egui.rs 的 demo 在 --pref dom._webegpu_enabled 下按预期工作；一个 Candy Crush 游戏现在可以玩。Control+A（macOS 上是 Command+A）会选中文档里的全部内容。密码输入框里的文本不能再被复制。

嵌入 API 有几处调整：无障碍工具产生的事件改走 Servo::forward_accessibility_action。WebView::clear_session_history 可以清掉会话历史。WebView::set_throttled 被移除了，WebView 隐藏时自动节流，显示时停止。webgl 进入 default_web_features，不想带 WebGL 的嵌入方需要关掉默认 feature。多进程模式改为构建时打开，去掉这项支持大约能省下 2MB。Linux 上打开了线程亲和性提升。Android 的 JVM 兼容目标升到 11。Windows 主机可以交叉编译 OpenHarmony 构建。OpenHarmony SDK 更新到 API 23。

release 附件里的 servo-aarch64-linux-ohos.hap 签给 OpenHarmony，不是 HarmonyOS。HarmonyOS 目前需要自行签名，说明指向 ArkTS Servo Demo 仓库。

捐款数字写在文末。经常性捐款是每月 8144 美元，比 8 月高 1%。thanks.dev 上有 37 个依赖 Servo 的 GitHub 用户在赞助，比 8 月多 1 个。博客列出了 10 位这个月第一次给 Servo 合入补丁的贡献者。

Bassfaceapollo 的评论有 58 分，希望 Servo 至少成为 Gecko 的替代品。noobjaish 的评论有 19 分，提到 Ladybird 计划在接下来几个月放出二进制。r2vcap 的评论有 0 分，写 Servo 由 Linux Foundation Europe 支持，并提到华为通过 OpenHarmony 参与。barsoap 的评论有 2 分，问这怎么构成对中国的依赖，并写 545400 欧元的资助相对很小。

原文链接：Servo 博客

tokio-tun 0.23.0 补上 Linux offload

tokio-tun 是一个用 Tokio 异步 创建 TUN/TAP 设备的 Rust 库。仓库在 https://github.com/yaa110/tokio-tun 。n47id 于 2026 年 11 月 7 日发到 r/rust，采集时 0 分、0 条评论。采集时仓库有 95 星、35 个 fork、58 个 tag，最新版本是 v0.23.0。

README 写到，在支持的平台上，包 I/O 都通过 AsyncFd 注册到 Tokio。没有单独的轮询循环，没有阻塞回退，也不自己抽出文件描述符。Tun::builder() 可以设置名字、地址、前缀、对端和 up。名字留空时由内核分配。一次 recv 返回一个 IP 包。写回 TUN 的数据必须是合法的 IPv4 或 IPv6 包。

v0.23.0 的 Linux 部分加了 virtio-net offload。TunBuilder::offload() 打开 TSO/GSO/GRO。新增 VirtioNetHeader、VIRTIO_NET_HDR_LEN 和 GSO 常量。每个收到的包前面有 10 字节的 virtio_net_hdr，发出去的包也要带这个头。offload() 配置 checksum、TSO4、TSO6 和基于 NAPI 的 GRO，并且不能和 packet_info() 一起用。NAPI GRO 作用在从用户态写进内核的包上，不会合并交给用户态的包。打开 offload 后，接收缓冲区至少要 VIRTIO_NET_HDR_LEN + 65_536 字节，因为 GSO 包可以超过接口 MTU。多队列附加时，每个队列都要调用 .offload()，状态不一致会被拒绝。

FreeBSD 这一版补了 TAP 的 MAC 地址、TunBuilder::persist()，以及 TAP 的 broadcast。persistence 保留接口身份。FreeBSD 在最后一个描述符关闭时会清掉地址和 up 状态。分配改用 SIOCIFCREATE2，避免误接管或拆掉已经存在的 persistent 或改过名的设备。

平台表写的是：Linux 有 TUN、TAP、多队列和 offload。macOS 只有 TUN，走 utun。Android 和 iOS 只有 TunQueue，分别接 VpnService 和 NetworkExtension 的 fd。FreeBSD 有 TUN 和 TAP，没有多队列，也没有 offload。macOS 和 FreeBSD 上，TUN 的 IPv6 destination 需要 /128 前缀。

原文链接：tokio-tun 仓库

业余开发者问能不能给 rustc 提补丁

这是 Motor_Alternative944 发在 r/rust 的一篇提问。作者表示自己没有计算机专业背景，最近在自学计算机科学和编译器，想知道学习期间能不能给 rustc 或类似的编译器项目做贡献，以及维护者会不会因为水平不够而不收。采集时帖子有 22 分、30 条评论，发布时间是 2026-11-06 15:32 UTC。

Ok-Zookeepergame4391 的评论有 38 分，写除了能力以外没有门槛。Crouton4035 的评论有 67 分，认为理论上谁都可以提议代码，但实际要有专业水平的知识和经验，补丁才比较有机会通过。评论还提到，维护者普遍报酬低、已经超负荷，不确定自己在做什么的时候不要增加他们的工作量；建议先把 Rust 代码库下载下来读，先不要指望马上贡献。

Anthony356 的评论有 1 分。作者写自己是业余开发者，大约 4 年前开始学，大约一年半前给 rustc 提了自己最早的一批 PR 之一，最近加入了编译器团队。评论认为，业余作者如果愿意听审阅意见，维护者一般不介意一份出于好意的 PR。作者把被邀请进编译器团队的原因写成：有时间去处理大家都认为状态不好、但因为复杂而没人愿意碰的部分，并把它记下来。审阅者目前比较友好，不熟悉的 git 命令也可以问。建议是不要为了改而改。

Kivooeo1 的评论有 12 分，写自己有一篇讲这个话题的文章，以及两篇从 issue 到合并的后续，里面有审阅过程。评论表示可以帮忙看，前提是自己做，不要让 LLM 把整个 PR 做完再一直点继续。维护者现在要花很多时间和精力处理这类自动提交。Equivalent_Head_4803 的评论有 6 分，写 issue 经常在自己动手之前就被机器人占掉，维护者的时间被指向 GitHub 的自动提交占掉了。

QuasiRandomName 的评论有 11 分，写自己最早的开源贡献是给 rust-lang 的两个小 PR，和 fmt::UpperHex / LowerHex 里的检查有关。Eh2406 的评论有 5 分，认为时间够的话，靠持续做会变成熟悉这块的人。在那之前，碰到不懂的缩写或术语就去查，查得到就学会了。解释难找时，可以建议把链接补上，并记下自己找过但没有答案的地方；找不到解释，就告诉维护者。MilkEnvironmental106 的评论有 7 分，建议从 GitHub 上相对简单的 issue 开始提 PR。

原文链接：Reddit 原帖

目录扫描先看 ignore，再谈 Rayon

这是 weaztoven 发在 r/rust 的一篇提问。作者在写一个 Rust CLI，扫描目录并对文件做清理。现在还是单线程，准备用 Rayon 把遍历和处理并行起来。问题是普通 SSD 和网络挂载上，线程池打满时有什么坑，Rayon 是不是还合适，有没有限制并发的写法。采集时帖子有 10 分、8 条评论，时间是 2026-11-06 16:49 UTC。

tylerlarson 的评论有 23 分，认为 Rayon 更偏 CPU 并行。只做目录遍历时，评论把 BurntSushi 为 ripgrep 写的 ignore crate 称为现成做法。它自带多线程池，并行遍历，自动遵守 .gitignore，并处理线程边界。作者回复会去看，因为手写 gitignore 规则比较麻烦。

layla4you2 的评论有 3 分，认为 Rayon 的池子是每个核一个线程，适合 CPU 工作；文件 I/O 大部分时间在等。本地 SSD 用默认值就可以。网络挂载上每次 stat 或 unlink 都是一次往返，在途请求要比核数多，但不能把服务器打满。并发数做成 -j 参数，不要猜。遍历可以用 ignore 的 WalkParallel，也就是 ripgrep 用的那条，或者 jwalk。限制并发的写法是：walker 进一个有界的 crossbeam channel，再由 N 个工作线程消费，背压由 channel 给出。清理时先删子项再删目录，不要跟随符号链接，把 NotFound 当成正常情况。

The_8472 的评论有 1 分，建议先用 strace 看实际系统调用和时间花在哪里。如果要 stat 几百万个文件，可以考虑用 io_uring 把这些调用收成一次系统调用。fiedzia 的评论有 1 分，认为瓶颈多半在操作系统或硬件，除非先证明不是这样。

原文链接：Reddit 讨论

以上是本期 Rust 日报的主要内容。更多 Rust 开发与资源共享，欢迎访问 云栈社区。