我也活跃在开源社区，主要给 DataFusion 和 Arrow Rust 等项目贡献，是 Apache DataFusion 项目 committer。

这是我的 Github 资料：https://github.com/lewiszlw 。

目前我已定居武汉，所以只接受武汉现场办公 or 远程办公。目前想找 data infra 相关工作，如有 ai infra 机会我也乐意尝试。

如有意向，可通过我的邮箱 lewiszlw520@gmail.com 联系我和获取简历～

• Dashboard 与 HTTP API 全面升级
  • 内嵌 Dashboard 并支持历史记录持久化，UI 全面改版。
  • 节点页改版，新增节点详情页与客户端详情页。
  • 新增丢弃消息面板（异常/非订阅者页签），支持集群特性监控。
  • 新增保留消息查询 API，Dashboard 支持直接删除保留消息。
  • HTTP API 文档全面更新。
• MQTT 协议与网络增强
  • 为 MQTT/TCP 连接启用 TCP SO_KEEPALIVE，tcp_keepalive 配置简化为布尔值。
  • 修复 QoS 2 重复 PUBLISH 与会话恢复场景下的精确一次投递语义。
  • 隔离 inflight 报文标识符（packet-id）空间，防止 PUBREL 恢复时被覆盖。
  • 修正空 ClientId 且 CleanStart/CleanSession=0 时的 CONNACK 原因码；在 retain 不可用时拒绝带 Will Retain 的 CONNECT。
  • 修复 proxy-protocol 缓冲区导致的栈溢出问题（改为堆分配）。
• 问题修复与稳定性
  • 修复集群插件中 retain/消息同步对 MessageReply::Success 的处理。
  • 连接错误日志中加入远端地址，便于排查。
  • 修复 cargo publish 时 Dashboard 资源无法打包的问题（改为从 crate 本地资源内嵌）。
• 性能与架构
  • HTTP API 历史刷新任务改用专用执行器，避免阻塞主执行器。
  • 服务端统一 main/run 模式，改进错误处理。
• 测试与文档
  • 新增 MQTT v3/v3.1.1/v5 规范符合性测试覆盖；测试套件支持按用例切换 broker 配置。
  • 同步测试套件引用计数与覆盖描述文档。
• 依赖与构建
  • Rust 最低版本要求从 1.89.0 提升至 1.94.0（含 CI MSRV）。
  • 版本号升级至 0.23.0 / 0.23.1，同步更新 Docker 与 Makefile。

更多更新完整列表，请参阅 RMQTT Release Notes

Github: https://github.com/rmqtt/rmqtt

Basalt 是一个以画面表现为导向的 Minecraft 启动器，后端使用 Rust，前端使用 React，整体基于 Tauri 框架。

启动器支持独立实例、Fabric / Quilt / NeoForge / Forge 模组加载器，以及从 CurseForge 和 Modrinth 下载模组、整合包、资源包和数据包。项目可从 Prism、ATLauncher 和 Modrinth App 导入实例且不改动原文件，并在高风险变更前生成实例快照；游戏崩溃时会读取日志并尝试给出原因。凭据写入系统钥匙串，并带有游戏时长统计。当前处于 beta，主要面向 Linux，同时可在 Windows 和 macOS 运行，提供 Nix flake、AUR 包、AppImage 和 Debian 包。

原文链接：https://github.com/MegalithOfficial/basalt-launcher

JJ-Bond：面向 Jujutsu 的平滑 TUI

jj-bond 是一个面向 Jujutsu（jj）版本控制系统的终端 UI，用于在短时间内完成大量提交重组操作。

项目提供历史查看、show、files、diff，以及 new、describe、edit、split、abandon、squash、duplicate、rebase、fetch、push 等变更操作，并支持 bookmark / tag 管理与 operation 查看。作者基于自研异步 Ratatui 框架 Ratzgo 降低频繁执行 jj 命令带来的交互延迟，可通过 cargo install jj-bond 安装，命令入口为 jb。

原文链接：https://github.com/TD-Sky/jj-bond

Razz：光线追踪、嵌入式传输与自研编译器

Razz 是一个围绕光线追踪展开的实验项目，在完成 Ray Tracing In One Weekend 的 Rust 实现之外，加入了嵌入式图像传输和自研场景语言编译器。

作者将本机渲染结果通过自定义协议流式传输到 Arduino，涉及位操作、校验和，以及 RGB888 到 BGR565 的压缩。Razz Compiler 将 .rz 源码经 Lexer、Parser、Type Checker、SSA IR Lowering、HIR Structurizer 生成 Rust 代码，场景操作使用类似 HTTP 动词的语法（如 POST /hittable sphere;）。编译器还实现了常量折叠、常量传播和死代码消除等基础优化。

原文链接：https://github.com/sudo-JP/Razz

poisoned：处理被污染 std 锁的小工具 crate

poisoned 是一个无依赖的小 crate，为 Mutex / RwLock 的 PoisonError 结果提供 LockExt 扩展方法。

当线程在持有锁时 panic 后，后续 lock() 会返回 PoisonError。or_panic() 在正常路径上对 poisoned lock 直接 panic；若当前线程已在 unwind，则通过 PoisonError::into_inner 取回 guard，避免二次 panic 导致进程 abort。crate 还提供 or_panic_with 自定义消息，以及 or_recover 在恢复时先修复内部值。

原文链接：https://github.com/abhishekshree/poisoned

RSMalloc 是一个基于 Restartable Sequences（RSEQ）的通用内存分配器，最新 Alpha-2 版本包含近 100 个提交的改进、优化和缺陷修复。

本次更新加入了 4 KB 以上 size class 的后台 trim、部分 NUMA 感知、基于 bitmap 的内存窃取、adaptive refilling 策略，以及用于大块内存元数据的 RB-tree。项目还提供每 CPU 快速路径、buddy 分配器、调试模式和仍在开发中的 page allocator 支持。

原文链接：https://github.com/Metehan120/rsmalloc

基于 127 位 dHash 与本地 CLIP 的图片去重工具

synology-dedup-photos 是一个用于识别重复照片和翻拍照片的本地工具，核心使用同时记录水平与垂直亮度梯度的 127 位 dHash，并将哈希存入 u128，通过异或和 count_ones 计算差异。

工具可用本地 CLIP 模型按向量余弦相似度识别同一场景的翻拍照片；在 Synology 图片库中，它可以直接处理 DSM API 返回的约 10 KB 缩略图，不必下载原图。审核界面使用 tiny_http，并为每次运行生成 CSRF token 和 Host 校验。

原文链接：https://github.com/LowLevelLogic/synology-dedup-photos

Sift：带事务日志的 Rust 本地文件整理器

Sift 是一个使用 Rust 编写的本地文件整理 CLI，面向大规模文件的规则匹配和 EXIF/ID3 元数据提取。

项目为移动、复制、回收站和压缩等文件操作写入事务日志，sift undo 可以按逆序回滚；默认运行在 dry-run 模式下，只有添加 -x 才会修改磁盘。实现使用 notify 监听文件变化，使用 ratatui 与 crossterm 提供 TUI，并通过 trash 接入系统回收站。

原文链接：https://github.com/taevel02/Sift

Rust Wayland 桌面尝试由合成器统一驱动动画

zaytun-os 是一个使用 Rust 构建的 Wayland 桌面环境实验项目，动画由合成器统一管理，因此应用卡住时桌面仍可继续运行其他窗口动画。

项目使用可解析求解的阻尼弹簧模型，动画被打断时保留当前速度；合成器在没有可见变化时停止渲染，并在一次测试中修复了阈值过小导致的半秒内渲染 13,000 多帧问题。Shell 直接运行在合成器内部，以减少面板的逐帧 IPC 和 buffer 上传。

原文链接：https://github.com/zoir-dev/zaytun-os

这段 GUADEC 2026 演讲介绍了一个基于 Rust 的 GNOME 系统组件栈，讨论内容涉及使用 Varlink/JSON-RPC 连接系统组件，以及文件回收、FUSE 等场景中的进程间通信与接口设计。

社区讨论集中在 RPC 和 JSON 序列化放入高频路径后的性能、非 UTF-8 文件名表示，以及与现有 GNOME 组件和 Rust GTK 绑定的集成方式。相关方案仍处于设计和讨论阶段。

原文链接：https://www.reddit.com/r/rust/comments/1vh3w3m/a_new_rustbased_stack_for_gnome_system_components/

format!() 不一定为结果字符串预分配最优容量

这篇 Rust 讨论分析了 format!() 生成字符串时的容量估算行为：输出字符串容量使用的是估算值，既不保证是上界，也不保证是下界，运行时参数的实际长度不会直接用于得到最优预分配容量。

作者在性能分析中发现 format!() 可能贡献了额外的字符串重新分配，并追溯了标准库实现及 2017 年引入容量估算的改动。相关代码位于 core::fmt，讨论还提供了 Rust 源码和历史 PR 链接。

原文链接：https://www.reddit.com/r/rust/comments/1vgngmg/til_format_does_not_necessarily_preallocate_the/

Rust 原生 Spotify 客户端 Canora

Canora 是一个使用 Rust 编写的原生 Spotify 客户端，作者为避免官方 Electron 客户端的内存、显存占用以及 Wayland 分数缩放问题，使用自研 UI 框架实现了桌面应用。

项目不依赖 JavaScript 引擎或 Flutter，播放部分使用 librespot；作者公布了基于底层 zgui UI 框架与 GPUI 的初步性能对比，并说明当前仍在优化 Vello 后端带来的内存和显存开销。应用目前主要面向 Wayland，支持 OAuth 登录。

原文链接：https://github.com/zortax/canora

Rust 实现 2D Guillotine 切割优化器

这是一个面向家具板材切割的 Rust 2D guillotine cutting stock optimizer，用于在满足板锯直线切割约束的同时减少 MDF 或刨花板的材料浪费。

项目使用遗传算法搜索布局，提供 SLAS 和 GLAS 两种编码方式；同时实现了单板材场景的动态规划精确求解器，以及用于快速返回结果的贪心启发式算法。CLI 和 Axum + SSE Web UI 会通过后台线程推送求解进度，多个遗传算法岛使用独立随机种子并在同步屏障迁移，以保持多线程运行的确定性。项目还提供 JSON 接口，可接入 Excel/VBA 并导出 AutoCAD 切割方案。

原文链接：https://github.com/nlinker/guillotine-cutting-2d

一、公司与团队简介

我们是一家位于美国西海岸的基础架构初创团队，目前处于 Stealth Mode（隐形保密模式） 阶段。公司专注于构建下一代云原生基础设施与高性能服务。

由于创始人在济南生活多年，对家乡非常熟悉，因此非常希望能寻找一位常驻济南（或周边）的 Rust 技术伙伴长期合作。

二、岗位职责

• 基础设施工具开发：基于 Rust 开发高效、稳定的 GCP 自动化运维工具、CLI 工具及系统监控组件。
• 高性能网络服务：参与高性能 API 网关、代理与网络传输模块的设计、开发与性能调优。
• 云端系统集成：结合 GCP 云原生生态（GCE, GKE, Cloud Networking 等），编写高并发、低延迟的服务端代码。
• 架构测试与优化：编写单元测试与集成测试，配合团队进行突发故障排查（Incident Response）与内存/CPU 性能瓶颈定位。

三、任职要求

• 工作地点：必须常驻 济南及周边（100% 远程办公，工作地点自由）。
• 经验与语言：具备 2–4 年 实际开发经验，熟练掌握 Rust 语言核心特性（如 Ownership, Borrow Checker, Async/Await, Traits, Lifetime 等）。
• 技术栈要求：
  • 熟悉 Async Rust 异步编程生态（如 Tokio, Hyper, Tonic/gRPC 等）。
  • 熟悉网络编程（TCP/UDP, HTTP/HTTPS, WebSockets, TLS/SSL）及 API 网关设计概念。
  • 了解/熟悉 GCP（Google Cloud Platform）或自动化运维工具开发经验者优先。
  • 了解 Docker / Kubernetes 或 Terraform 者为加分项。
• 语言与沟通：能无障碍阅读和编写英文技术文档/API 日志（日常沟通直接用中文交互即可）。
• 综合素质：具备良好的代码风格与工程素养，责任心强，能够独立排查并解决问题。

四、工作形式与薪酬

• 工作性质：独立合同工（Independent Contractor）。
• 工作时间：全职（约 40 小时/周）或兼职/半职均可，形式灵活协商。
• 薪酬标准（支持美金/人民币按月结算）：
  • 中级 Rust 工程师（2–4年经验）：$15 – $25 / 小时（全职折合约 ¥1.5万 - ¥2.5万/月）
  • 特别优秀的高级/资深大牛薪资可另行协商（$25 – $40 / 小时）。

五、面试流程

1. 线上初筛（8月 - 9月）：线上初步技术沟通与简历审核。
2. 线下终面（9月下旬）：9 月 25 日中秋节前，创始人将亲赴济南进行线下终面与技术交流（咖啡厅/高新区）。

六、联系方式

• 请将简历（中英文皆可）发送至：freedafeng@outlook.com
• 邮件主题格式：【应聘Rust工程师】姓名 - 期望工作形式(全职/兼职) - 期望时薪

TrailBase 0.32 是一个开源、单可执行文件的 Firebase 替代方案，提供数据库、认证和 API 等后端能力。

项目以 Rust 构建，强调部署简单和运行时依赖较少；本次版本更新继续完善面向应用开发的服务端功能。

原文链接：https://github.com/trailbaseio/trailbase

2.37 倍更快的 OpenGraph 图片生成

Ditching Puppeteer for 2.37x faster opengraph image generation 是一篇关于替换 Puppeteer、优化 OpenGraph 图片生成流程的项目文章。

文章标题给出的基准结果是生成速度提升 2.37 倍，展示了 Rust 工具在服务端图片生成任务中的应用。

原文链接：https://mem.red/posts/faster-og-image-generation/

Rust 硬件抽象层的通用硬件在环测试方案

PoC for universal hardware-in-the-loop HAL test suite 是 Tweede golf 对通用硬件在环 HAL 测试套件概念验证的介绍。

该方案针对嵌入式 Rust 硬件抽象层测试，尝试用统一的测试方法覆盖不同硬件实现，重点放在可复用的测试基础设施和真实设备验证流程。

原文链接：https://tweedegolf.nl/en/blog/240/PoC-for-universal-hardware-in-the-loop-HAL-test-suite/

Rust 中 Downcasting Arc 的实现方法

Downcasting Arcs in Rust 是一篇介绍如何在 Rust 中对 Arc 持有的 trait object 进行 downcast 的教程文章。

文章围绕共享所有权、trait object 和类型恢复之间的关系展开，给出了在实际代码中处理 Arc<dyn Trait> 的实现思路。

原文链接：https://ashdnazg.github.io/articles/26/Downcasting-Arcs-in-Rust

Kitesurf 是 Cloudflare 发布的 agent-first 无头浏览器，在 V8 Isolates 中运行，并使用 Dioxus Blitz 构建浏览器界面与渲染相关组件。

项目面向 Cloudflare Workers 环境，目标是在隔离的 V8 运行时中执行浏览器自动化任务。该项目展示了 Dioxus Blitz 与 Rust 浏览器基础设施结合的实现路径。

原文链接：https://blog.cloudflare.com/kitesurf/

SurtGIS 1.0：纯 Rust 单文件地理空间库

SurtGIS 1.0 是一个用 Rust 编写的栅格 GIS 库，覆盖地形、水文和遥感处理，并提供原生 GeoTIFF I/O，不要求依赖 GDAL。

项目包含 7 个已发布 crate，可编译到原生平台、WASM 和 Python；通过编译期 maybe_rayon 模式支持并行与单线程构建，并用计数信号量限制云端栅格合成的内存占用。作者还记录了模糊测试发现的 32 GB OOM 问题及修复后的基准结果。

原文链接：https://www.reddit.com/r/rust/comments/1vgd3hj/surtgis_10_a_singlebinary_geospatial_library_no/

Rust 编译器性能在 2026 年 7 月继续提升

How to speed up the Rust compiler in July 2026 是 Nicholas Nethercote 对 rustc 性能工作的阶段性总结。

文章统计了 2025 年 12 月 3 日至 2026 年 7 月 29 日的测量结果，整体平均墙钟时间降低 5.59%；排除 rustdoc 后仍降低 2.90%。其中 rustdoc 的平均墙钟时间降低 37.92%，改进来自 impl 处理、PGO 训练集以及排序实现等改动，Clippy 也有新的性能优化。

原文链接：https://nnethercote.github.io/2026/07/31/how-to-speed-up-the-rust-compiler-in-july-2026.html

Cargo 工作流改进方向讨论

A Vision for Cargo 是 Cargo 维护者 epage 对未来 Cargo 工作流的设计讨论。

文章从依赖管理、构建性能、适应性和 Cargo 维护四个方向梳理问题，涉及 crates.io 依赖发现、质量信号、构建脚本以及更高层次的开发流程。作者也讨论了 agentic development 对 Cargo、Rust 和 crates.io 工作方式可能带来的影响，并邀请社区参与方案设计。

原文链接：https://epage.github.io/blog/2026/08/cargo-vision/

This Week in Rust 662 是 Rust 社区周报，汇总了 2026 年 7 月底的项目、工具和语言仓库更新。

本期项目与工具更新包括 afrim 0.7.0、cargo-reapi、exiftool-rs 0.7.0、SeaORM 2.0、BrewFS 等；观察文章涉及 std::simd::swizzle_dyn、查询循环、C++ 到 Rust 迁移和高性能二维数组。周报还记录了 Rust 仓库上周合并的 570 个 pull request，并列出编译器、标准库和 Cargo 的近期改动。

原文链接：https://this-week-in-rust.org/blog/2026/07/29/this-week-in-rust-662/

用 ratatui 实现 Pong 终端游戏

Pong in tui 是一个使用 Rust 的 ratatui 库实现的终端版 Pong 游戏项目。

作者发布了运行演示视频，项目展示了用 TUI 框架构建实时交互小游戏的基本方式。

原文链接：https://www.reddit.com/r/rust/comments/1vcr4iw/pong_in_tui/

Rust 会议费用讨论

这是一篇关于 Rust 会议费用的社区讨论帖，作者表示部分会议的参会价格较高，并询问社区成员是否通常自行承担全额费用。

帖子没有给出具体会议或价格对比，主要围绕 Rust 社区活动的参与成本和参会方式展开。

原文链接：https://www.reddit.com/r/rust/comments/1vctmkk/rust_conferences_feel_like_cash_grab/

Rust 开发者希望有哪些 API

这是一篇面向 Rust 社区的 API 需求讨论帖，作者询问开发者希望有哪些目前不存在、价格更低或更易使用的 API。

讨论范围包括新 API、现有服务的易用性、功能完整度和价格等方面，帖子目前以社区征集需求为主，没有限定具体实现方向。

原文链接：https://www.reddit.com/r/rust/comments/1vd2zab/what_apis_do_you_wish_existed/

--

From 日报小组 Mike

社区学习交流平台订阅：

• Rustcc论坛: 支持rss
• 微信公众号：Rust语言中文社区

数据库 ↔ Git ↔ SSH / SFTP ↔ 剪贴板

• GitHub：https://github.com/tools-rs/ramag
• 下载：https://github.com/tools-rs/ramag/releases/tag/v0.0.2
• 更新记录：https://github.com/tools-rs/ramag/blob/main/CHANGELOG.md

v0.0.2 主要更新

SSH 连接管理

新增完整的 SSH 管理入口，支持：

• 密码、系统 SSH 配置和密钥认证
• 解析 ssh user@host -p 2222 -i /path/to/key 命令
• 连接测试、默认目录和生产连接标记
• 多连接标签和连接搜索
• 本机加密保存密码与敏感连接参数

终端连接复用系统 OpenSSH，因此可以继续使用现有的 ~/.ssh/config、SSH Agent、密钥和 known_hosts。

内嵌终端与 SFTP 文件工作区

连接成功后，可以在同一个工作区中使用内嵌终端和远程文件浏览：

• ANSI 终端显示和常用键盘输入
• 一个连接下打开多个终端标签
• 始终保留至少一个终端，避免误关后留下空页面
• 远程目录浏览、路径导航和名称搜索
• 文本预览与编辑、日志跟随
• 文件和目录上传下载
• 覆盖确认、取消和传输进度

还可以从当前路径、目录或文件所在位置创建新终端。新终端会进入对应远程目录，不影响已有终端的运行状态。

生产连接会禁止 SFTP 上传、编辑、重命名和删除。终端命令仍由远端账号权限与服务器策略约束。

JumpServer 导入

支持保存多个 JumpServer 登录，并直接读取：

• 组织与资产树
• 已授权资产
• 资产平台和地址
• 可用的授权账号

选择资产与授权账号后，可以导入为普通 SSH 连接，继续编辑、测试和打开。未开放 SSH 协议的资产会明确提示，不会错误导入。

数据库改进

• 结果搜索支持字符串 ID 与整数 ID 双向转换。
• 内置 Base10、Base16、Base36、Base58 Bitcoin、Base58 Flickr 和自定义字符表。
• 支持带路径、超时和输出限制的外部转换器。
• 修复 MySQL SHOW WARNINGS 被识别为普通分页查询的问题。
• 数据库连接导入导出迁移到全局设置，可统一处理 MySQL、PostgreSQL、Redis 和 MongoDB。
• 编辑连接时完整回填现有参数，生产连接继续受只读保护。

Git 与剪贴板改进

Git 工作台新增明确的克隆入口，Markdown 文件默认渲染预览，并重新整理了分支、远端、Tag 和 Stash 操作。同时修复新建分支导致的界面崩溃、分栏宽度串联和部分标签无法通过 ⌘W / Ctrl+W 关闭的问题。

剪贴板仍默认关闭。启用状态、采集行为、全局热键和“清空全部历史”统一迁移到全局设置；关闭后会隐藏入口并释放全局快捷键。

macOS：⌘⇧V
Windows：Ctrl+Shift+V

本地优先与安全边界

Ramag 不要求登录账号，也不会把数据库连接、SSH 凭据、Git 仓库或剪贴板内容上传到 Ramag 服务。

• 敏感配置使用 AES-256-GCM 加密。
• 主密钥保存在 macOS Keychain 或 Windows Credential Manager。
• SSH 认证、主机校验和 Git 网络操作复用系统已有配置。
• 数据库和 SSH 生产连接会限制界面中的写操作。

Git 功能仍处于试验阶段。生产数据库操作、Git 写操作和远程终端命令仍需要使用者确认目标环境和影响范围。

下载

v0.0.2 Release：

https://github.com/tools-rs/ramag/releases/tag/v0.0.2

当前提供：

Ramag-0.0.2-macos-arm64.dmg
Ramag-0.0.2-macos-x86_64.dmg
Ramag-0.0.2-windows-x64-setup.exe
SHA256SUMS.txt

支持 macOS 12+ Apple Silicon、macOS 12+ Intel 和 Windows 10/11 x64，暂不支持 Linux。

当前 Windows 安装包尚未做 Authenticode 签名，macOS 安装包尚未完成 Developer ID 签名与 Apple 公证。请只从项目 Releases 下载，并使用同一页面的 SHA256SUMS.txt 校验文件。

从源码运行：

git clone https://github.com/tools-rs/ramag.git
cd ramag
make develop

如果你正在使用 Rust、GPUI、数据库工具或 SSH/SFTP 工作流，欢迎下载体验。遇到问题时，可以在 GitHub Issues 中附上操作系统、Ramag 版本和复现步骤；提交前请删除服务器地址、用户名、密码和业务数据。

• Issues：https://github.com/tools-rs/ramag/issues
• 源码：https://github.com/tools-rs/ramag

🔐 安全性大幅增强

• 移除 SHA-1，新增 SSH layer，支持后量子密钥交换算法 mlkem768x25519，彻底修复 SSH 安全警告
• 修复了 git clone 无法安全断开 TCP 连接的问题

⚙️ 后台管理优化

• 支持用户软删除，数据管理更灵活
• 支持用户安全更新邮箱

🚀 CI 与体验提升

• 支持 cursor-based CI 日志拉取，交互更顺畅
• UI 全面打磨，修复了多项历史遗留问题，视觉和操作更一致流畅

为什么要做这个项目: 第一点: 肯定是因为兴趣爱好, 因为我喜欢写代码, 喜欢做这个事情 第二点: 我见识过类似的各种平台, 但都是差强人意, 体验很糟糕 第三点: 的的确确我找不到工作, 失业了, 职场远远不是你想写代码那么简单, 这是一个很痛的现实, 但我必须要接受, 因为我还想继续写代码直到写不动的那一天, 可现实不允许我这样

欢迎大家下载试用，也期待大家的反馈和建议！ 🙏

关于大家关心的源代码开源问题, 目前有计划在将来进行开源, 但具体开源时间还不确定.

详细发布日志:

https://github.com/gitbundle/gitbundle/releases/tag/server-v3.5.0

Features Async-First Design: Built from ground up for async/await with Tokio integration Zero-Copy: Efficient buffer management using the bytes crate Lock-Free Buffer Pool: High-performance memory management with crossbeam Connection-Oriented: High-level connection abstractions (KcpStream, KcpListener) Protocol Compatible: Compatible with original C KCP implementation Observability: Integrated tracing and metrics support Memory Efficient: Object pooling and buffer reuse Multiple Performance Modes: Normal, Fast, Turbo, Gaming presets Installation Add this to your Cargo.toml:

[dependencies] kcp-tokio = "0.4" tokio = { version = "1.0", features = ["full"] } Quick Start Client use kcp_tokio::{KcpConfig, KcpStream}; use tokio::io::{AsyncReadExt, AsyncWriteExt};

#[tokio::main] async fn main() -> Result<(), Box> { let config = KcpConfig::new().fast_mode(); let mut stream = KcpStream::connect("127.0.0.1:12345".parse()?, config).await?;

// Send data
stream.write_all(b"Hello, KCP!").await?;

// Receive response
let mut buffer = [0u8; 1024];
let n = stream.read(&mut buffer).await?;
println!("Received: {}", String::from_utf8_lossy(&buffer[..n]));

Ok(())

} Server use kcp_tokio::{KcpConfig, KcpListener}; use tokio::io::{AsyncReadExt, AsyncWriteExt};

#[tokio::main] async fn main() -> Result<(), Box> { let config = KcpConfig::realtime(); let mut listener = KcpListener::bind("127.0.0.1:12345".parse()?, config).await?;

println!("Server listening on 127.0.0.1:12345");

while let Ok((mut stream, addr)) = listener.accept().await {
    println!("New connection from {}", addr);
    tokio::spawn(async move {
        let mut buf = [0u8; 1024];
        while let Ok(n) = stream.read(&mut buf).await {
            if n == 0 { break; }
            let _ = stream.write_all(&buf[..n]).await;
        }
    });
}

Ok(())

} Architecture ┌─────────────────────────────────────────────────────────────┐ │ Application Layer │ │ (User code using KcpStream/KcpListener) │ ├─────────────────────────────────────────────────────────────┤ │ High-Level API Layer │ │ KcpStream KcpListener │ │ (AsyncRead/AsyncWrite, TCP-like interface) │ ├─────────────────────────────────────────────────────────────┤ │ Protocol Core Layer │ │ KcpEngine │ │ (ARQ logic, congestion control, retransmission) │ ├─────────────────────────────────────────────────────────────┤ │ Common Layer │ │ KcpSegment, KcpHeader, BufferPool, Constants │ ├─────────────────────────────────────────────────────────────┤ │ Transport Layer │ │ Generic Transport trait (UDP default) │ └─────────────────────────────────────────────────────────────┘ Configuration Performance Presets // Gaming - ultra-low latency (3ms update interval) let config = KcpConfig::gaming();

// Real-time communication (8ms update interval) let config = KcpConfig::realtime();

// File transfer - high throughput let config = KcpConfig::file_transfer();

// Testing with packet loss simulation let config = KcpConfig::testing(0.1); // 10% packet loss Performance Modes Mode Update Interval Resend Congestion Control Use Case Normal 40ms 0 Yes General purpose Fast 8ms 2 Yes Low latency Turbo 4ms 1 No Maximum speed Gaming 3ms 1 No Real-time games Custom Configuration use std::time::Duration;

let config = KcpConfig::new() .fast_mode() .window_size(128, 128) .mtu(1400) .connect_timeout(Duration::from_secs(10)) .keep_alive(Some(Duration::from_secs(30))) .stream_mode(true); Examples

Run performance test server

cargo run --example perf_test_server -- 127.0.0.1:12345 gaming

Run performance test client

cargo run --example perf_test_client -- 127.0.0.1:12345

Run simple echo example

cargo run --example simple_echo Testing

Run all tests

cargo test

Run resilience tests (packet loss, reorder, concurrent connections)

cargo test --test resilience_test

Run benchmarks

cargo bench

Run with logging

RUST_LOG=debug cargo test -- --nocapture

Run clippy

cargo clippy --all-targets -- --deny clippy::all Documentation Detailed documentation is available in the doc/ directory:

Document Description ARCHITECTURE.md System architecture and design MODULES.md Module reference and APIs USAGE.md Usage guide and examples TESTING.md Testing guide Performance KCP provides significant latency improvements over TCP:

30-40% lower latency in typical network conditions Better performance on lossy networks Configurable trade-offs between latency and bandwidth Optimizations in this Implementation Actor-based lock-free architecture: KcpEngine runs in a single dedicated tokio task, eliminating Arc<Mutex<>> contention Generic Transport trait: Associated Addr type with RPITIT — zero heap allocation on hot path (no Pin<Box>) DashMap for packet routing: Listener uses lock-free concurrent hashmap on the hot path Lock-free buffer pools: crossbeam::queue::ArrayQueue for zero-allocation fast path BTreeMap receive buffer: O(log n) insertion for out-of-order packets (vs O(n) linear scan) Zero-copy segment encoding: Flush avoids cloning segments, encodes by reference Cached timestamps: Single syscall per input() call instead of 3+ Pre-allocated buffers: VecDeque::with_capacity based on window sizes, avoiding grow overhead on send burst Zero-copy packet handling with bytes crate Grouped state structs for better cache locality Configurable update intervals (3-40ms) Batch ACK processing Use Cases Gaming: Ultra-low latency for real-time multiplayer VoIP/Video: Real-time communication Live Streaming: Low-latency data delivery File Transfer: Reliable bulk data transfer IoT: Efficient communication for constrained devices Compatibility Protocol: Compatible with original C KCP Rust: Edition 2021, stable toolchain Tokio: 1.0+ License MIT License - see LICENSE file.

Contributing Contributions are welcome! Please feel free to submit a Pull Request.

Resources Original KCP Protocol KCP Protocol Documentation Tokio Documentation Benchmarks Criterion benchmarks measure engine-level throughput and latency:

cargo bench Benchmark Description engine_throughput 10/100/500 x 1KB messages engine_small_messages 1000 x 64B messages engine_large_message Single 16KB/64KB message fragmentation + reassembly Version History v0.4.0: Extract kcp-core as standalone protocol crate, restructure source layout (src/ → kcp/, flatten async_kcp/) v0.3.7: Fix ACK window/UNA fields, generic Transport trait with RPITIT, resilience tests, criterion benchmarks v0.3.4: Engine refactoring, lock-free buffer pools, documentation v0.3.3: Performance optimizations, sub-millisecond latency v0.3.1: Full async support, comprehensive configuration v0.2.x: Performance improvements and bug fixes v0.1.x: Initial implementation

核心能力

• 混合架构：兼顾 B+ 树读速与 LSM 树写吞吐
• MVCC 并发：非阻塞的并发读写
• 闪存优化：面向 SSD/NVMe 的 log-structured 设计
• 大值分离：独立 Blob 存储，减少写放大
• ACID 事务：完整的事务支持

性能数据

注：以上为与 RocksDB 对比的中位数倍数。

适用场景

• 需要高并发读写的嵌入式服务（尤其是 mixed/read-heavy 负载）
• 写入吞吐敏感的本地存储层（中小 value 场景优势更明显）
• 混合读写 + 扫描的业务
• 需要本地事务和 MVCC 的 Rust 应用

地址

• 源码：https://github.com/abbycin/mace
• Benchmark 脚本：https://github.com/abbycin/kv_bench（scale 分支）

mace 还在非常早期的阶段，目前还在努力提升稳定性以及对特定workload进行优化...

0.0.29 版更新

Rudis 是一个采用 Rust 语言编写得高性能键值存储系统，旨在利用 Rust 语言的优势来重新复现 Rudis 的核心功能，以满足用户对高性能、可靠性和安全性的需求，同时保证与 Rudis API 的兼容。

跨平台，兼容 windows、linux 系统架构。 兼容 字符串、集合、哈希、列表、有序集合数据结构。 提供 rdb 与 aof 机制以支持数据备份和恢复。 拥有卓越的处理速度和即时响应能力。 兼容 Rudis 的命令和协议规范。

欢迎在 GitHub 上关注我们的项目发展轨迹：

👉 https://github.com/lunar-landing/rudis

更新日志：

• 新增 List 数据结构 Blpop、Brpop 命名。
• 新增 Hash 数据结构 HSCAN 命令，支持 MATCH 和 COUNT 参数。
• 新增 String 数据结构 SETEX、PSETEX、SETNX、SETBIT、GETBIT、BITCOUNT、BITOP 命令。
• 新增 Set 数据结构 SRANDMEMBER、SDIFFSTORE、SINTERSTORE、SMOVE 命令。
• 新增 HyperLogLog 数据结构及 PFADD、PFCOUNT、PFMERGE 命令。
• 重构 SortedSet 底层实现，采用 HashMap + SkipList 架构提升性能，并支持 bincode 序列化。
• 修复 SETEX/PSETEX 过期记录清理逻辑以及系统时间倒退导致的 RDB 调度 Panic 问题。

这几年接私活、做外包、做独立项目，有一个问题一直困扰我：

我们其实不知道一个项目「合理的价格」是多少。

不是技术难度不知道，而是——
你不知道别人真实成交是多少，只能靠猜、靠平台最低价、靠「听说」。

需求方会说：

「别人比你便宜一半。」

开发者只能纠结：

「我是报高了，还是别人报低了？」

时间久了，就变成大家都在往下试探，
内卷不是某个人的选择，而是信息不透明的结果。

我已经做了什么

我先从自己开始。

我把自己这几年做过的一些真实项目整理出来，包括：

• 项目类型
• 实际成交价格
• 大概工期
• 是否反复改需求
• 是否包含售后

做成了一个 独立开发者行情板。

目前一共 23 个案例：

• 大部分是我自己的真实成交
• 少部分是朋友的
• 也有几个是匿名提交的

我不回避这个事实：
数据现在还很少，而且并不「漂亮」。

但它至少是真实的。

为什么我需要更多人，而不是「更多数据」

我一个人的案例，其实没什么意义。

但如果有：

• 50 个
• 100 个
• 200 个

来自不同背景、不同技术栈、不同城市的真实案例，
至少可以做到一件事：

让后来的人，在报价时有一个不被平台最低价绑架的参考。

你不需要证明你多厉害，
也不需要报一个「体面」的价格，
真实比好看重要。

关于匿名和安全

我知道大家最担心什么，所以我一开始就做了两件事：

• 提供 匿名提交
• 不要求任何可追溯身份信息

目前有两个入口：

飞书表单 行情板网站

不署名、不展示来源、不做商业售卖。
你可以只写你愿意写的字段。

说一句更远一点的想法（不画饼）

行情板不是终点。

我真正想做的，是一个 不竞价、不抽佣、不负责售后 的撮合平台，
只做一件事：

把预算真实的需求方，和愿意按合理价格做事的开发者，匹配到一起。

行情板只是前战，是定价共识的基础。
如果连「合理价格区间」都没有，
任何撮合都会退化成比谁便宜。

我不确定这条路能走多远，
但至少想先试一次。

最后

如果你愿意贡献一个案例：

• 成功的
• 失败的
• 觉得自己报低了的
• 或者被压价压得很难受的

都可以。

如果你不想提交，也没关系，
至少希望这个东西能让你下次报价时，心里多一点底气。

• 算力层聚合：广泛接入全球闲散 GPU 算力资源，通过标准化调度技术实现算力的统一管理与高效利用；

• 服务层赋能：在聚合算力之上深度部署 MaaS 模型服务，客户无需投入高昂成本搭建算力与模型架构，只需通过简洁的大模型接口，即可按需调用 AI 能力，快速赋能业务创新。

算纽（GPUNexus）打通算力资源与模型应用的壁垒，让 AI 服务更便捷、更普惠。

2. 产品形态

2.1. 算力资产分享

算纽算力资产分享产品，核心打破算力孤岛，依托智能调度技术，实现各类计算资源一键接入、整合与统一调度，激活分散算力价值。

产品支持全场景接入，覆盖算力中心、企业服务器等专业设备及个人电脑、手机等终端，实现“云-边-端”全域覆盖。无论闲置算力拥有方（企业/机构/个人）还是算力需求方，均可通过平台精准匹配、高效流转。

无需复杂配置即可快速上线，智能调度实现供需实时匹配，既提升算力利用率，又帮助需求方降本、分享方变现，构建互利共赢的算力生态。

2.2. MAAS服务

算纽 MaaS服务，一站式整合30 余款主流开源大模型矩阵，囊括 DeepSeek、Qwen、GLM、Kimi、MiniMax 等明星模型，深度覆盖编程开发、学术研究与论文创作、数学推理、视觉处理与多模态交互、对话与长文本处理五大核心场景。

2.3. 开发者套餐

算纽开发者套餐，专为学生、独立开发者及中小团队量身定制，以超高性价比解锁顶级大模型编程能力，让每一份开发需求都能高效落地。

套餐核心优势直击开发痛点：成本颠覆性降低，计费低至传统tokens计费的一折，大幅压缩开发成本；模型自由切换，无需冗余购买多平台会员，一键直达GLM-4.7、MiniMax-M2.1、Kimi-K2三大顶级编程模型，最新最强的模型能力随心选；高效创作不等待，生成速度媲美同类高级套餐，助力快速完成代码编写、调试、优化等核心工作。

更有7天免费体验限时开启！零成本即可抢先体验顶级模型的强悍编程能力，轻松开启高效开发新体验。

​

• 官方网址：https://gpunexus.com/
• 咨询电话：010-53650986
• 联系邮箱：data@chengfangtech.com

一个终端看板应用，灵感来自 Helix 编辑器的键位设计。

预览

特性

• 📁 基于文件存储 - 使用 Markdown 文件和 TOML 配置，易于版本控制
• 🎯 多项目支持 - 支持全局项目和本地项目（.kanban/）
• ⌨️ Helix 风格键位 - 符合直觉的键盘快捷键
• 🪟 窗口管理 - 支持垂直/水平分屏，同时查看多个项目，自动保存和恢复工作区布局
• 🎨 现代 TUI - 基于 ratatui 的美观终端界面
• 📝 Markdown 支持 - 任务使用 Markdown 格式，支持外部编辑器
• 🔍 任务预览 - 内置预览和外部预览工具支持
• ⚙️ 自动配置 - 首次运行自动检测编辑器和预览器

安装

从 crates.io 安装

cargo install helix-kanban

从源码构建

git clone https://github.com/menzil/helix-kanban.git
cd helix-kanban
cargo build --release

快速开始

首次运行会显示欢迎对话框，自动检测系统编辑器和 Markdown 预览器：

hxk

输入法切换（macOS）

为了更好的输入体验，在正常模式下自动切换到英文输入法，在对话框模式（如创建/编辑任务）时保持用户的输入法。

推荐安装 im-select 工具：

# 使用 Homebrew 安装
brew install im-select

# 或者使用 curl 安装
curl -Ls https://raw.githubusercontent.com/daipeihust/im-select/master/install_mac.sh | sh

注意：如果不安装 im-select，程序仍可正常运行，只是不会自动切换输入法。

配置管理

查看当前配置：

hxk config show

设置编辑器：

hxk config editor nvim
hxk config editor "code --wait"

设置 Markdown 预览器：

hxk config viewer glow
hxk config viewer "open -a Marked 2"

键位绑定

基础导航

任务操作

项目管理

窗口管理

命令模式

按 : 进入命令模式，支持的命令：

• :q / :quit - 退出应用
• :open / :po - 打开项目
• :new / :pn - 创建新项目（全局）
• :new-local / :pnl - 创建新项目（本地）
• :add / :tn - 创建新任务
• :edit / :te - 编辑任务
• :view / :tv - 预览任务
• :reload / :r / :refresh - 重新加载当前项目
• :reload-all / :ra / :refresh-all - 重新加载所有项目
• :vsplit / :sv - 垂直分屏
• :hsplit / :sh - 水平分屏
• :help / :h - 显示帮助

数据存储

全局项目

全局项目存储在 ~/.kanban/projects/ 目录下。

本地项目

在任何目录下按 n 创建本地项目，会在当前目录的 .kanban/ 下存储：

your-project/
├── .kanban/
│   └── kanban-project/
│       ├── .kanban.toml
│       ├── todo/
│       ├── doing/
│       └── done/
└── ... (你的其他文件)

项目结构

project-name/
├── .kanban.toml          # 项目配置
├── todo/                 # Todo 任务
│   ├── 001.md
│   └── 002.md
├── doing/                # 进行中任务
│   └── 003.md
└── done/                 # 完成的任务
    └── 004.md

任务文件格式

任务以 Markdown 格式存储：

# 任务标题

created: 2025-12-10T10:30:00+08:00
priority: high

任务的详细描述内容...

## 子任务

- [ ] 子任务 1
- [x] 子任务 2

配置文件

应用配置存储在 ~/.kanban/config.toml：

editor = "nvim"
markdown_viewer = "glow"

# 隐藏的全局项目列表（软删除）
hidden_projects = ["old-project", "archived-project"]

工作区状态保存

应用会自动保存窗口布局和工作状态，下次启动时恢复：

保存内容：

• 分屏结构（垂直/水平分割）
• 每个窗格打开的项目
• 当前选中的列和任务
• 聚焦的窗格

保存位置：

• 全局工作区：~/.kanban/workspace.toml - 在任何目录启动时使用
• 本地工作区：.kanban/workspace.toml - 在项目目录下启动时优先使用

使用场景：

• 经常需要同时查看多个项目？设置好分屏布局后，下次启动自动恢复
• 在不同项目目录工作？每个目录都有自己独立的工作区布局
• 想要重置布局？使用命令 :reset-layout 恢复默认单窗格

示例工作区配置 (workspace.toml)：

# 自动生成，通常无需手动编辑
focused_pane = 2
next_pane_id = 4

[[panes]]
id = 0
type = "horizontal_split"
left = 1
right = 2

[[panes]]
id = 1
type = "leaf"
project = "work-project"
selected_column = 1
selected_task_index = 0

[[panes]]
id = 2
type = "leaf"
project = "personal-project"
selected_column = 0
selected_task_index = 2

开发

# 运行开发版本
cargo run

# 运行测试
cargo test

# 构建 release 版本
cargo build --release

致谢

• 键位设计灵感来自 Helix Editor
• UI 框架使用 ratatui

许可证

MIT OR Apache-2.0

今天的核心主题是：如何利用 Rust 过程宏的强大能力，将这些繁琐的持久化逻辑自动化，让开发者只需声明字段，即可获得健壮的乐观锁支持。

宏架构：分治与协作

实现一个完整的、自动化的乐观锁流程，需要宏在两个不同的代码层面进行注入和协作：

1. 数据变更层 (ActiveModelBehavior)：负责在数据写入数据库前，自动管理版本号 (version) 和时间戳 (updated_at) 的递增/更新。
2. 持久化操作层 (Repository::save)：负责实现核心的原子更新逻辑，即 CAS 检查。

Part 1: ActiveModel 的预处理钩子 (before_save)

这是我们实现乐观锁的第一步：确保在更新操作中，版本号能够正确地 自增。

我们通过宏注入或修改 sea-orm::ActiveModelBehavior Trait 的 before_save 钩子。

宏注入逻辑概览：

// 宏片段：insert_active_model_behavior_impl 的核心逻辑
if need_version {
    let version_stmt = quote! {
        if insert {
            // 插入 (insert=true) 时，版本号初始化为 1
            self.version = Set(1);
        } else if self.is_changed() {
            // 更新 (insert=false) 且模型有业务字段变化时，版本号自增
            let current_version = match self.version {
                Set(v) => *v,
                _ => 0,
            };
            self.version = Set(current_version + 1);
        }
    };
}
// updated_at 逻辑类似：非插入且 is_changed 时设置为当前时间

关键成果： 当我们在 Repository 中执行更新操作时，ActiveModel 已经通过 before_save 确保了两个重要事实：

1. 它携带着我们从数据库中读出的 旧版本号。
2. 它将尝试写入的 version 值，是 旧版本号 + 1。

Part 2: Repository 的原子 CAS 更新 (save 方法)

这是乐观锁实现的核心战场，由 fn create_tenant_save_impl 宏片段生成。其逻辑必须严格遵循 三步走 策略，以处理成功、冲突和首次插入三种情况。

Step 1: 原子 UPDATE (Compare-and-Swap)

我们使用 sea-orm 的 update_many 配合 filter 条件，来实现原子性检查。

我们从聚合根 (entity) 中取出 旧版本（即 current_version），并将其作为 WHERE 子句的一部分。

// 宏片段：create_tenant_save_impl 的核心 CAS 逻辑

// 从聚合获取当前版本（即期望的旧版本）
let current_version = entity_model.#optimistic_lock_field_ident();

// 1) 原子 UPDATE（带 version CAS）
let res = models::Entity::update_many()
    #id_filters // 主键和 TenantId 过滤
    // ⬇️ 核心：只有当数据库中的版本号等于旧版本号时，才允许更新 ⬇️
    .filter(models::Column::#optimistic_lock_col_ident.eq(current_version)) 
    .set(update_model.clone())
    .exec(&conn)
    .await?;

if res.rows_affected > 0 {
    // 成功！说明版本匹配，且更新成功写入
    // ... 事件处理并返回 Ok(())
    return Ok(());
}

如果 rows_affected > 0，任务圆满完成。如果 rows_affected == 0，则进入下一步判断。

Step 2 & 3: 冲突检测与首次插入

如果 CAS 更新失败（rows_affected == 0），我们需要区分是 版本冲突（记录存在但版本号不匹配）还是 首次插入（记录根本不存在）。

// 2) UPDATE 未命中，检查记录是否存在
if models::Entity::find()
    #id_filters // 仅按主键和 TenantId 查找
    .one(&conn)
    .await?
    .is_some()
{
    // 记录存在，但 Step 1 未命中 -> 乐观锁冲突！
    return Err(#crate_root::domain::RepositoryError::optimistic_lock_error(
        "Optimistic lock conflict: Version mismatch".to_string(),
    ));
}

// 3) 记录不存在，执行首次插入
let insert_model: models::Model = entity_model.clone().try_into()?;
let mut active_model = insert_model.into_active_model();
active_model.insert(&conn).await?;
// ... 事件处理并返回 Ok(())

Talk is cheap, show me the code

before_save

fn insert_active_model_behavior_impl(input: &mut ItemMod, model_config: &ModelConfig) {
  let Some((_, items)) = &mut input.content else {
      return;
  };

  let mut has_active_model_behavior = false;
  for item in items.iter_mut() {
      if let syn::Item::Impl(item_impl) = item
          && let Some((_, path, _)) = &item_impl.trait_
          && path.segments.last().unwrap().ident == "ActiveModelBehavior"
      {
          has_active_model_behavior = true;
          break;
      }
  }

  if !has_active_model_behavior {
      let active_model_behavior_impl = quote! {
          #[async_trait]
          impl ActiveModelBehavior for ActiveModel {
              async fn before_save<C>(mut self, db: &C, insert: bool) -> Result<Self, DbErr>
              where
                  C: ConnectionTrait,
              {
                  Ok(self)
              }
          }
      };
      items.push(parse_quote!(#active_model_behavior_impl));
  }

  for item in items.iter_mut() {
      if let syn::Item::Impl(item_impl) = item
          && let Some((_, path, _)) = &item_impl.trait_
          && path.segments.last().unwrap().ident == "ActiveModelBehavior"
      {
          let mut has_before_save = false;
          for item in item_impl.items.iter_mut() {
              if let syn::ImplItem::Fn(method) = item
                  && method.sig.ident == "before_save"
              {
                  has_before_save = true;
                  break;
              }
          }

          if !has_before_save {
              let before_save_method = quote! {
                  async fn before_save<C>(mut self, db: &C, insert: bool) -> Result<Self, DbErr>
                  where
                      C: ConnectionTrait,
                  {
                      Ok(self)
                  }
              };
              item_impl.items.push(parse_quote!(#before_save_method));
          }

          let need_created_at = model_config
              .fields
              .iter()
              .any(|f| f.ident.as_ref().unwrap() == "created_at");
          let need_updated_at = model_config
              .fields
              .iter()
              .any(|f| f.ident.as_ref().unwrap() == "updated_at");

          let need_version = model_config
              .fields
              .iter()
              .any(|f| f.ident.as_ref().unwrap() == "version");

          if !(need_created_at || need_updated_at || need_version) {
              return;
          }

          for item in item_impl.items.iter_mut() {
              if let syn::ImplItem::Fn(method) = item
                  && method.sig.ident == "before_save"
              {
                  let mut stmts = Vec::new();
                  stmts.push(quote! {
                      let now = chrono::Utc::now();
                  });

                  if need_created_at {
                      let created_at_stmt = quote! {
                          if insert {
                              self.created_at = Set(now);
                          }
                      };
                      stmts.push(created_at_stmt);
                  }
                  if need_updated_at {
                      let updated_at_stmt = quote! {
                          if insert {
                              self.updated_at = Set(now);
                          } else if self.is_changed() {
                              self.updated_at = Set(now);
                          }
                      };
                      stmts.push(updated_at_stmt);
                  }

                  if need_version {
                      let version_stmt = quote! {
                          if insert {
                              self.version = Set(1);
                          } else if self.is_changed() {
                              let current_version = match self.version {
                              Set(v) => *v,
                              _ => 0,
                          };
                              self.version = Set(current_version + 1);
                          }
                      };
                      stmts.push(version_stmt);
                  }

                  let stmts = parse_quote!({#(#stmts)*});

                  // 插入到方法体的开头
                  method.block.stmts.insert(0, stmts);
              }
          }
      }
  }
}

宏生成的代码示例

 impl ActiveModelBehavior for ActiveModel {
        #[allow(
            elided_named_lifetimes,
            clippy::async_yields_async,
            clippy::diverging_sub_expression,
            clippy::let_unit_value,
            clippy::needless_arbitrary_self_type,
            clippy::no_effect_underscore_binding,
            clippy::shadow_same,
            clippy::type_complexity,
            clippy::type_repetition_in_bounds,
            clippy::used_underscore_binding
        )]
        fn before_save<'life0, 'async_trait, C>(
            self,
            db: &'life0 C,
            insert: bool,
        ) -> ::core::pin::Pin<
            Box<
                dyn ::core::future::Future<Output = Result<Self, DbErr>>
                    + ::core::marker::Send
                    + 'async_trait,
            >,
        >
        where
            C: ConnectionTrait,
            C: 'async_trait,
            'life0: 'async_trait,
            Self: 'async_trait,
        {
            Box::pin(async move {
                if let ::core::option::Option::Some(__ret) =
                    ::core::option::Option::None::<Result<Self, DbErr>>
                {
                    #[allow(unreachable_code)]
                    return __ret;
                }
                let mut __self = self;
                let insert = insert;
                let __ret: Result<Self, DbErr> = {
                    {
                        let now = chrono::Utc::now();
                        if insert {
                            __self.created_at = Set(now);
                        }
                        if insert {
                            __self.updated_at = Set(now);
                        } else if __self.is_changed() {
                            __self.updated_at = Set(now);
                        }
                    }
                    Ok(__self)
                };
                #[allow(unreachable_code)]
                __ret
            })
        }
    }

Repository::save

fn create_tenant_save_impl(
    crate_root: &Path,
    aggregate: &Path,
    args: &RepositoryStructArgs,
    id_filters: &TokenStream,
) -> TokenStream {
    // 若指定了乐观锁字段，准备字段名/Column ident
    let optimistic_lock_field = args.optimistic_lock_field.as_ref().map(|lit| {
        let optimistic_lock_field_name = lit.value();
        let optimstic_lock_field_ident = new_id(&optimistic_lock_field_name); // 用于 ActiveModel/Model 字段访问
        let optimistic_lock_col_ident = new_id(&to_pascal_case(&optimistic_lock_field_name)); // 用于 models::Column::Xxx
        (
            optimistic_lock_field_name,
            optimstic_lock_field_ident,
            optimistic_lock_col_ident,
        )
    });

    // 根据是否指定乐观锁字段，生成 save 的实现
    if let Some((
        optimistic_lock_field_name,
        optimistic_lock_field_ident,
        optimistic_lock_col_ident,
    )) = optimistic_lock_field
    {
        if optimistic_lock_field_name == "version" {
            quote! {
                async fn save(
                    &self,
                    txn: &mut TC,
                    entity: &mut #crate_root::domain::EventSourcedEntity<#aggregate>,
                ) -> Result<(), #crate_root::domain::RepositoryError> {
                    use #crate_root::domain::SeaOrmModelUpdater;
                    use sea_orm::{ActiveModelTrait, ColumnTrait, EntityTrait, IntoActiveModel, QueryFilter};
                    use sea_orm::ActiveValue::Set;

                    let conn = txn.get_connection();
                    let entity_model: &#aggregate = entity;

                    let id = entity_model.id();
                    let tenant_id = entity_model.tenant_id();

                    // 从聚合获取当前版本与期望旧版本
                    let current_version = entity_model.#optimistic_lock_field_ident();

                    // 构造用于原子更新的 ActiveModel（只写回必要列）
                    let mut update_model = models::Model::from(entity_model.clone()).into_active_model();

                    // 1) 原子 UPDATE（带 version CAS）
                    let res = models::Entity::update_many()
                        #id_filters
                        .filter(models::Column::TenantId.eq(*tenant_id))
                        .filter(models::Column::#optimistic_lock_col_ident.eq(current_version))
                        .set(update_model.clone())
                        .exec(&conn)
                        .await?;

                    if res.rows_affected > 0 {
                        entity.move_event_to_context(txn);
                        return Ok(());
                    }

                    // 2) UPDATE 未命中，检查记录是否存在（按主键 + tenant）
                    if models::Entity::find()
                        #id_filters
                        .filter(models::Column::TenantId.eq(*tenant_id))
                        .one(&conn)
                        .await?
                        .is_some()
                    {
                        return Err(#crate_root::domain::RepositoryError::optimistic_lock_error(
                            "Optimistic lock conflict: Version mismatch".to_string(),
                        ));
                    }

                    // 3) 记录不存在，插入数据
                    let insert_model: models::Model = entity_model.clone().try_into()?;
                    let mut active_model = insert_model.into_active_model();
                    active_model.insert(&conn).await?;
                    entity.move_event_to_context(txn);
                    Ok(())
                }
            }
        } else {
            // treat as timestamp update_at
            quote! {
                async fn save(
                    &self,
                    txn: &mut TC,
                    entity: &mut #crate_root::domain::EventSourcedEntity<#aggregate>,
                ) -> Result<(), #crate_root::domain::RepositoryError> {
                    use #crate_root::domain::SeaOrmModelUpdater;
                    use sea_orm::{ActiveModelTrait, ColumnTrait, EntityTrait, IntoActiveModel, QueryFilter};
                    use sea_orm::ActiveValue::Set;
                    use chrono::Utc;

                    let conn = txn.get_connection();
                    let entity_model: &#aggregate = entity;

                    let id = entity_model.id();
                    let tenant_id = entity_model.tenant_id();

                    // 读取实体携带的旧时间戳与准备新的时间戳
                    let current_ts = entity_model.#optimistic_lock_field_ident();

                    // 构造用于原子更新的 ActiveModel
                    let mut update_model = models::Model::from(entity_model.clone()).into_active_model();

                    // 1) 原子 UPDATE（带 updated_at CAS）
                    let res = models::Entity::update_many()
                        #id_filters
                        .filter(models::Column::TenantId.eq(*tenant_id))
                        .filter(models::Column::#optimistic_lock_col_ident.eq(current_ts))
                        .set(update_model.clone())
                        .exec(&conn)
                        .await?;

                    if res.rows_affected > 0 {
                        entity.move_event_to_context(txn);
                        return Ok(());
                    }

                    // 2) UPDATE 未命中，检查记录是否存在
                    if models::Entity::find()
                        #id_filters
                        .filter(models::Column::TenantId.eq(*tenant_id))
                        .one(&conn)
                        .await?
                        .is_some()
                    {
                        return Err(#crate_root::domain::RepositoryError::optimistic_lock_error(
                            "Optimistic lock conflict".to_string(),
                        ));
                    }

                    // 3) 记录不存在，直接插入数据
                    let insert_model: models::Model = entity_model.clone().try_into()?;
                    let mut active_model = insert_model.into_active_model();

                    active_model.insert(&conn).await?;
                    entity.move_event_to_context(txn);
                    Ok(())
                }
            }
        }
    } else {
        // no optimistic lock field -> simple update/insert behavior (原始实现)
        quote! {
            async fn save(
                &self,
                txn: &mut TC,
                entity: &mut #crate_root::domain::EventSourcedEntity<#aggregate>,
            ) -> Result<(), #crate_root::domain::RepositoryError> {
                use #crate_root::domain::SeaOrmModelUpdater;
                use sea_orm::{ActiveModelTrait, ColumnTrait, EntityTrait, IntoActiveModel, QueryFilter};

                let conn = txn.get_connection();

                let entity_model: &#aggregate = entity;

                let id = entity_model.id();
                let tenant_id = entity_model.tenant_id();

                if let Some(mut model) = models::Entity::find()
                    #id_filters
                    .filter(models::Column::TenantId.eq(*tenant_id))
                    .one(&conn)
                    .await?
                {
                    if &model.tenant_id != tenant_id {
                        return Err(#crate_root::domain::RepositoryError::mapping_error(
                            format!(
                                "Tenant ID mismatch: expected {}, found {}, id: {}",
                                tenant_id, model.tenant_id, id
                            ),
                        ));
                    }

                    // 更新逻辑
                    model.update_from_aggregate_root(entity_model).await?;

                    let active_model = model.into_active_model();
                    active_model.update(&conn).await?;
                } else {
                    // 创建新记录
                    let model: models::Model = entity_model.clone().try_into()?;
                    let active_model = model.into_active_model();
                    active_model.insert(&conn).await?;
                }

                entity.move_event_to_context(txn);
                Ok(())
            }
        }
    }
}

宏生成的代码示例

  async fn save(
        &self,
        txn: &mut TC,
        entity: &mut core_common::domain::EventSourcedEntity<TenantUser>,
    ) -> Result<(), core_common::domain::RepositoryError> {
        use core_common::domain::SeaOrmModelUpdater;
        use sea_orm::{
            ActiveModelTrait, ColumnTrait, EntityTrait, IntoActiveModel, QueryFilter,
        };
        use sea_orm::ActiveValue::Set;
        use chrono::Utc;
        let conn = txn.get_connection();
        let entity_model: &TenantUser = entity;
        let id = entity_model.id();
        let current_ts = entity_model.update_at();
        let mut update_model = models::Model::from(entity_model.clone())
            .into_active_model();
        let res = models::Entity::update_many()
            .filter(models::Column::Id.eq((id.tenant_id(), id.user_id())))
            .filter(models::Column::UpdateAt.eq(current_ts))
            .set(update_model.clone())
            .exec(&conn)
            .await?;
        if res.rows_affected > 0 {
            entity.move_event_to_context(txn);
            return Ok(());
        }
        if models::Entity::find()
            .filter(models::Column::Id.eq((id.tenant_id(), id.user_id())))
            .one(&conn)
            .await?
            .is_some()
        {
            return Err(
                core_common::domain::RepositoryError::optimistic_lock_error(
                    "Optimistic lock conflict".to_string(),
                ),
            );
        }
        let insert_model: models::Model = entity_model.clone().try_into()?;
        let mut active_model = insert_model.into_active_model();
        active_model.insert(&conn).await?;
        entity.move_event_to_context(txn);
        Ok(())
    }

兼容性处理

宏的另一个优势是其灵活性。它能根据字段名称自动适配不同的乐观锁策略：

• 如果检测到字段为 "version"，则执行版本号的 CAS 逻辑。
• 如果检测到其他时间戳字段如 "updated_at"，则执行基于时间戳的 CAS 逻辑。

结论

通过将 before_save 中的版本递增逻辑，与 Repository::save 中的原子 CAS 检查完美结合，我们使用 Rust 过程宏实现了一个 高内聚、低耦合 的乐观锁基础设施。

开发者现在可以专注于业务逻辑，而将并发控制的复杂性和样板代码完全交给宏来处理。这不仅极大地提高了开发效率，同时也确保了底层持久化操作的健壮性和一致性。

一、乐观锁：不是不锁，而是“巧”锁

数据库的并发控制主要分为悲观锁和乐观锁。

• 悲观锁（Pessimistic Locking）： 假设冲突一定会发生。在读取数据时就对数据行进行锁定，直到事务完成。
• 乐观锁（Optimistic Locking）： 假设冲突很少发生。在整个事务过程中不锁定资源，而是通过检查数据是否被修改来确认。

乐观锁的核心思想是：通过一次原子性的操作来检查并修改数据，而不是依赖两次独立的数据库操作。

二、没有锁的陷阱：丢失更新的竞态条件

让我们以一个 version: i32 字段为例，来看看缺乏原子性操作会导致什么问题。

场景：多人同时更新同一条记录

1. 查询（事务 A/B）： 事务 A 和事务 B 都读取了 ID=1 的记录，其 version 都为 1。
2. 更新（事务 B 提交）： 事务 B 完成修改，执行 无版本检查 的 UPDATE 语句，数据库中的 version 变为 2。
3. 更新（事务 A 提交）： 事务 A 完成修改，也执行 无版本检查 的 UPDATE 语句。

结果： 事务 B 的业务变更被事务 A 的修改覆盖，导致 丢失更新（Lost Update） 的竞态条件。

乐观锁的解决之道：单次原子操作

要解决这个问题，必须让 “检查旧版本” 和 “设置新值” 成为一个原子操作，即在 UPDATE 语句中加入版本过滤条件：

UPDATE records
SET title = '新标题', version = version + 1
WHERE id = 1 AND version = 1; -- 关键：只有旧版本为 1 时才允许更新

在 SeaORM 中，我们使用 update_many() 配合 filter() 来构造这个原子操作，并通过检查 rows_affected 来判断操作是否成功。

三、Upsert 流程的抉择：先 Update 再 Insert 的优势

实现 Upsert 功能主要有两种策略：“先 Update 再 Insert” 和 “先 Insert 再 Update”。在涉及乐观锁的业务中，“先 Update 再 Insert” 模式是更优的选择。

1. 模式一：先 Update 再 Insert（推荐）

这种模式总是优先处理最常见的情况：更新现有记录。

优势分析：

• 天然支持乐观锁： 乐观锁检查（WHERE version = ?）直接集成在 UPDATE 语句中，利用了数据库的原子性，保证了在单次操作中完成检查和修改。
• 高效处理更新： 在高并发的更新场景中，大部分操作都是更新。这种模式只需执行一次成功的 UPDATE 就能完成任务，避免了不必要的 INSERT 尝试。

2. 模式二：先 Insert 再 Update

流程： 尝试 INSERT $\to$ 如果失败（主键冲突），执行 UPDATE。

劣势分析：

• 乐观锁实现复杂： 如果 INSERT 失败，转到 UPDATE 时，必须确保 UPDATE 操作是带有乐观锁检查的，这增加了流程的复杂性。
• 高更新场景效率低： 如果大部分操作是更新，这种模式会强制执行一次注定会失败的 INSERT 操作（抛出主键冲突错误），然后再执行一次 UPDATE，浪费了数据库资源。

总结：选择 “先 Update 再 Insert” 的理由

在处理带有乐观锁的聚合根持久化时，“先 Update 再 Insert” 模式是首选方案。它能够利用 UPDATE 的原子性高效地处理最常见的更新操作，并天然地将乐观锁检查与数据库写操作绑定。

四、SeaORM 中的 Upsert 流程：UPDATE $\to$ FIND $\to$ INSERT

基于 “先 Update 再 Insert” 的策略，我们构建一个清晰的 "原子 UPDATE + FIND + INSERT" 三步流程，以可靠地处理成功更新、并发冲突和成功插入三种情况。

核心实现代码

// 假设 entity.version 是更新后的新版本，expected_old_version = entity.version - 1
async fn save<T: TransactionContext>(
    &self,
    callback: &mut EventSourcedEntity<Callback>,
    txn: &mut T,
) -> Result<(), RepositoryError> {
    let conn = txn.get_connection();
    let entity: &Callback = callback;
    let id = entity.channel.0.clone(); 
    let expected_old_version = entity.version - 1; 

    // 准备 ActiveModel，设置新的 version
    let mut active_model_for_update: ActiveModel = entity.clone().into_active_model();
    active_model_for_update.version = Set(entity.version); 

    // ----------------------------------------------------
    // 第一步：尝试原子 UPDATE（带乐观锁）
    // ----------------------------------------------------
    let res = callback_model::Entity::update_many()
        .set(active_model_for_update)
        .filter(callback_model::Column::Channel.eq(id.clone())) 
        .filter(callback_model::Column::Version.eq(expected_old_version)) // 乐观锁检查
        .exec(conn)
        .await?;

    if res.rows_affected > 0 {
        // 更新成功：影响行数 > 0，说明乐观锁条件满足。
        callback.move_event_to_context(txn);
        return Ok(());
    }

    // ----------------------------------------------------
    // 第二步：UPDATE 失败。使用 FIND 检查记录是否存在（判断是否为并发冲突）
    // ----------------------------------------------------
    if callback_model::Entity::find_by_id(id.clone())
        .one(conn)
        .await?
        .is_some()
    {
        // 记录存在。UPDATE 失败且记录存在，必然是版本不匹配，即并发冲突。
        return Err(RepositoryError::optimistic_lock_error(
            "Optimistic lock conflict: Record exists, but old version did not match."
        ));
    }

    // ----------------------------------------------------
    // 第三步：记录不存在，尝试 INSERT
    // ----------------------------------------------------
    let active_model_for_insert: ActiveModel = entity.clone().into_active_model();
    
    active_model_for_insert.insert(conn).await
        .map_err(|e| {
             // 如果 INSERT 失败，则视为并发冲突（在 FIND 之后被其他事务插入）。
             match e {
                 DbErr::RecordNotInserted | DbErr::Custom(_) => RepositoryError::optimistic_lock_error(
                    "Concurrency conflict: Record inserted after non-existence check."
                 ),
                 _ => e.into(),
            }
        })?;

    callback.move_event_to_context(txn);
    Ok(())
}

结论：告别竞态，拥抱原子性

通过本文的分析和实践，我们可以得出以下关键结论：

1. 乐观锁是高并发的基石： 放弃“先查后改”的传统模式，将版本检查与数据修改集成到一次原子性的 UPDATE 操作中，是避免丢失更新等竞态条件的根本方法。
2. 选择正确的 Upsert 策略： “先 Update 再 Insert” 模式凭借其对乐观锁的天然支持和对更新操作的高效处理，成为处理聚合根持久化的首选。
3. 利用数据库的原子性： 无论是通过检查 rows_affected，还是依赖主键约束错误来区分更新失败的原因，都是在充分利用数据库底层机制来确保数据一致性。

在您的 Rust DDD/CQRS 架构中，将这种原子化逻辑封装进仓储（Repository）层的 save() 方法中，是确保数据完整性和系统高可用性的关键。