Cot v0.7 发布：表单、ORM、安全和文档链路一起补强

Rust Web 框架 Cot v0.7 这次更新很像一轮“底层能力补全”。作者没有只盯着某个 headline feature，而是把表单、ORM、密码安全、错误输出和文档维护这几块一起往更成熟的框架体验推进。先看表单系统，v0.7 给常见字段类型补上了更多 HTML 属性配置能力，比如 placeholder、readonly、autocomplete、autocapitalize、dir、list、min_length、size、step 等；FileField 还新增了 capture，可以提示设备使用摄像头或麦克风作为输入源。

ORM 这边的两个变化也很实用。第一是 #[model(field_name = ...)] 允许 Rust 字段名和数据库列名解耦，这对接手历史数据库或者只想重命名 Rust 侧字段的项目会方便很多。第二是外键现在终于能在模型层直接配置 on_delete / on_update 策略，不再强制一律走 RESTRICT。也就是说，Cascade、SetNull、SetDefault、NoAction 这些更接近真实业务需求的策略，现在都能在 Cot 里显式表达。

安全相关的变化则集中在 Password 和 SecretKey。作者把它们的底层存储切换到了 securer-string，从而让敏感数据在 drop 时主动清零、比较时使用 constant-time 比较，并尽可能通过 mlock 避免被 swap 到磁盘。这种设计不一定会立刻改变框架的营销话术，但对真正处理账户系统、后台配置和密钥的 Web 项目来说，是很扎实的一步。

文档和开发体验也没有落下。Cot guide 里的代码片段已经接入 CI 自动编译测试，避免文档和实际 API 默默漂移；ProjectConfig 新增 extra 兜底字段，让应用可以更自然地向 config/*.toml 塞入项目私有配置。整体看下来，v0.7 不是那种“只多了几个 API”的例行版本，而是很明显在朝可长期维护的 Web 框架打磨。

原文链接：https://mackow.ski/blog/cot-v07-lazily-thorough/

FPV 乐高小车继续进化：no_std Rust 驱动摄像头、Wi‑Fi 图传和网页遥控

这篇 Fearless Embedded Rust: A FPV Lego car 很像一篇把“嵌入式 Rust 能做到什么”直接摊在桌面上的实战记录。作者在上一篇无线乐高小车的基础上，继续把项目升级成 第一视角 FPV 小车：前端是网页控制界面，嵌入式端挂上 Arducam 摄像头，通过 Wi‑Fi 传输图像流，再用键盘方向键实时操控车辆。最有意思的是，这整套链路并不是“某个地方用了一点 Rust”，而是从 RP2040 上的 no_std 任务，到后端 GUI 服务，再到浏览器交互，全链路都围绕 Rust 搭起来。

文章把软硬件取舍都写得很具体。嵌入式侧运行在 Embassy 上，拆出多个并行任务去处理命令接收、驱动控制、摄像头流、网络栈和 USB 日志；桌面侧则用 tokio + axum 做 Web GUI 和命令 / 视频隧道。作者特别强调，这种“通道 + 并发任务”式的结构，让嵌入式程序和后端程序在组织方式上 surprisingly 接近：一个运行在没有操作系统的小芯片上，一个运行在普通电脑上，但它们都在异步收发消息、管理状态和协调多个消费者。

硬件踩坑也很有参考价值。作者提到，真正难的不是把 Rust 代码写出来，而是把 SPI、I2C、供电和抗干扰调到一个稳定状态：大面包板和长导线会让高频总线变得极不可靠，最终必须换成更小的 breadboard 和更短的连线；摄像头加上 Wi‑Fi 峰值电流之后，原本的供电路径又不够，需要引入 buck converter 和肖特基二极管来稳定供电并保护 USB 回灌。这类“软件几乎顺利，电子部分反而反复试错”的经验，对很多想上手 Rust 嵌入式的人来说比抽象教程更有价值。

最终成品能提供 640x480 下约 7~8 FPS 的实时视频流、网页方向键遥控、纯乐高电池供电，以及一个意外很接地气的附加功能：rodent motion detector。它当然不是一个通用框架发布，但作为一篇完整展示 no_std + async + TCP/Wi‑Fi + Web UI 如何拼成可玩成品的项目记录，这篇内容很值得进今日候选。

原文链接：https://dystroy.org/blog/picamobile/

rust-analyzer Changelog #336：数组长度不匹配 quick fix 上线，proc macro server 跨工作区共享

本周的 rust-analyzer changelog #336 虽然篇幅不长，但对日常 IDE 体验的改善很实在。最直观的新功能，是新增了 array length mismatch 的 quick fix。这类错误在写 demo、重构常量数组或者泛型相关代码时并不罕见，现在可以更快从诊断直接跳到修复动作，少走一层手动编辑。

性能方面，这一版把 proc macro server 在多个 workspace 之间共享，并改成使用两个进程来承载相关工作。对大型 monorepo 或同时打开多个 Rust 工程的人来说，这种改动往往比单个小功能更有体感，因为它直接碰的是补全、分析和启动时延背后的系统开销。

兼容性和稳定性修复也不少。更新里明确提到支持 Cargo 1.97 的 CARGO_RESOLVER_LOCKFILE_PATH 设置；同时修掉了 merge_imports 尾部分隔符 panic、generate_function 在 unresolved module 下崩溃、MIR lowering 对错误类型 crash、proc macro TokenStream::from_str 处理 doc comments 等一串边界问题。看得出来，这期 changelog 的重点不是造一个大 headline，而是在持续压缩那些“编辑器偶尔抽一下风”的粗糙感。

内部重构同样推进得很猛，包括去掉更多 ExpandDatabase / DefDatabase 相关历史包袱、精简查询和改进 LSP 结构。这类改动对普通用户往往不可见，但通常决定了项目后面还能不能继续维持高频迭代。对于 rust-analyzer 这种已经是很多 Rust 开发者日常主力工具的项目来说，#336 更像一次稳扎稳打的“可维护性加固”。

原文链接：https://rust-analyzer.github.io/thisweek/2026/07/13/changelog-336.html

4 套 Rust 密码库 TLS 握手横评：Graviola 表现亮眼，OpenSSL 路线最慢

这篇性能测试把 aws-lc-rs、Graviola、ring、OpenSSL 四套密码学库，放到同一套 TLS 握手基准里做横向比较，测试维度覆盖了 3 种密钥协商、5 种签名算法、3 种 cipher suite。作者使用 WTX 项目中的 TLS 实现，加上 hyperfine 做顺序测量，重点观察的是握手从 PEM 解码到 Finished 结束这一整段真实执行路径，而不是只抽取某一个底层原语做微基准。

文章的价值在于，它没有把结果写成“谁赢了”的简单结论，而是把不同库和算法组合之间的差异摆在同一个实验框架里看。作者指出，在这批测试里 OpenSSL 路线整体最慢，暂时还不确定原因到底是编译参数、内部配置、openssl-sys 封装，还是 OpenSSL 本身；而 Graviola 则展现出相当有潜力的表现，尤其在这类对握手路径较敏感的场景里值得继续观察。

另外几条结论也挺有意思：三种主流 cipher suite 在整体结果上的差异并没有想象中那么大；secp384r1 的 key agreement 在 OpenSSL 和 ring 上似乎还有明显优化空间；而 aws-lc-rs 在 RSA-PSS 相关场景里不一定比 ring 或 Graviola 更快。对做网络栈、代理、边缘服务或安全中间件的 Rust 团队来说，这篇基准至少提供了一个很好的出发点：TLS 握手成本不是抽象概念，不同密码库的组合选择确实可能在真实握手路径里拉开差距。

原文链接：https://c410-f3r.github.io/thoughts/tls-handshakes-measuring-the-performance-of-4-cryptography-libraries/