Cloudflare 追出 hyper 隐蔽漏洞：200 OK 也会截断大图响应

Cloudflare 在重构 Workers 的 Images binding 过程中，意外挖出了一个埋在 hyper 里的老问题：某些大图请求明明返回了 HTTP 200，Content-Length 也看起来正常，但真正送到客户端的 body 却只剩下一小截。外层链路看到的是“读取消息体时提前 EOF”，而内层服务日志却没有报错，因此这个问题一开始非常难定位。

更有意思的是，问题并不是业务逻辑算错了，而是一个很典型的时序型连接收尾 bug。Cloudflare 追踪了六周，最后通过 strace 看到：在 reader 消费较慢、socket outbound buffer 一时排不空时，hyper 会在剩余数据还滞留在内部缓冲区时就提前 shutdown(SHUT_WR)。结果就是 header 和前面一小段 body 先发出去了，后面大块响应数据却永远没真正离开进程。

他们还特别确认，这不是某个新版本回归，而是跨多个 hyper 大版本都存在的老问题；真正修复只用了四行代码。对 Rust 生态来说，这类案例的价值不只是“Cloudflare 修了个 bug”，而是把高并发网络服务里 flush / shutdown 竞态这类平时极难复现的问题，拆成了非常清楚的一条工程排障路径。

文章原文：https://blog.cloudflare.com/hyper-bug/ hyper 仓库：https://github.com/hyperium/hyper

原文链接：https://blog.cloudflare.com/hyper-bug/

hotpath 0.18 新增 wrap 通道观测：把异步队列堆积和锁竞争直接量出来

hotpath 最近这波更新，最值得看的不是传统 CPU profile，而是它开始更认真地补 async / concurrency observability 这块短板。作者在新文章里重点介绍了 0.18.0 带来的 wrap = true 通道观测模式：不再只靠代理通道侧面估算，而是直接把 sender / receiver 包进自定义 wrapper 里，让队列深度、消息延迟、内存占用这些指标真正能被量出来。

这件事对 Rust 并发程序很实用。很多异步系统“卡住”时，CPU profiler 并不会告诉你根因，因为瓶颈常常不是算力，而是channel 排队、消费者追不上、或者锁被长时间持有。hotpath 这次把 channel、Mutex、RwLock 这些点都纳入同一套观测面后，开发者更容易分清：到底是函数本身慢、I/O 等待多，还是任务之间的协调出了问题。

作者还顺手用这套新观测能力去反向 profile hotpath 自己，并给出一个很具体的 breaking point：在他的机器上，后台处理链路大致能扛到每秒约 1700 万 profiling events，超过后队列长度和延迟会明显冒出来。这个例子挺有说服力——它说明这些指标不只是“看起来很专业”，而是真的能帮你判断并发系统什么时候开始失速。

文章原文：https://hotpath.rs/blog/profiling-async-rust 项目仓库：https://github.com/pawurb/hotpath-rs crates.io：https://crates.io/crates/hotpath

原文链接：https://hotpath.rs/blog/profiling-async-rust

Tokio 异步爬虫实战：边抓边画图，把网页关系实时长出来

作者把自己一年前写的同步 C++ 爬虫，完整重写成了一个 Rust + Tokio 的异步版本，而且不只是“换语言复刻”，而是连架构也一起升级了。新版本的核心目标很明确：增量返回结果、并行抓取处理、再加一个可交互 GUI，让页面关系图不是等全部抓完才显示，而是边发现边扩展。

实现上，作者采用了很适合这类场景的 actor model：crawler、view、connector 分开，通过消息通道通信。crawler 内部把抓取请求拆成 command / event 两层，再把耗时网络请求交给 tokio::spawn，把 CPU 更重的解析任务交给 spawn_blocking。这样 event loop 本身始终保持轻量，不会因为某个页面慢、某段 HTML 难解析，就把整个系统拖停。

这篇内容的好处，是它没有停在“Tokio 很强”这种泛泛而谈，而是把同步 UI 与异步 actor 怎样桥接、为什么要用 bounded channel 防止消息无限堆积、为什么解析必须和 runtime worker 线程隔离这些实操点都讲清楚了。对想写桌面工具、可视化爬虫或带实时反馈的 Rust 应用的人来说，参考价值很高。

文章原文：https://raydroplet.dev/log/crawler/ 项目仓库：https://github.com/raydroplet/crawler-rs

原文链接：https://raydroplet.dev/log/crawler/

CodeStory：给编程代理提前铺好本地图索引，把 repo 语境先“落地”再提问

CodeStory 这个项目切的点很贴近最近的 agent 工作流：它不是再造一个聊天界面，而是做一个本地 codebase grounding engine，先把仓库索引成文件、符号、调用路径和 snippet 组成的本地图，再把这些带引用的上下文包喂给编程代理，减少每次都从头扫树、反复读文件的开销。

从仓库说明给出的基准看，作者主打的收益相当直接：在一组固定公共仓库任务里，启用 CodeStory 后，上下文 token 下降约 43%，重复任务 wall time 下降约 45%，tool calls 下降约 87%，而且 direct source reads 甚至可以降到 0。它的思路本质上不是“让 agent 更会猜”，而是让 agent 在开始行动前，先站在一个可引用、可约束、带不确定性提示的本地证据层上工作。

这个方向之所以值得看，是因为它很像给 coding agent 补了一层更工程化的“本地检索底座”：既强调 100% local，又把插件、stdio server、readiness / repair 流程都一起做了。对越来越多把 Codex、Claude Code、Copilot 之类工具拉进真实代码库的人来说，这种“先 ground，再 agent”的路线，正在变成很实际的一类基础设施。

项目仓库：https://github.com/TheGreenCedar/CodeStory 文档入口：https://github.com/TheGreenCedar/CodeStory/blob/main/docs/usage.md Reddit 讨论帖：https://old.reddit.com/r/rust/comments/1udwzgi/codestory_a_rust_cli_that_indexes_repos_into_a/

原文链接：https://github.com/TheGreenCedar/CodeStory