Rust 生态里的 png crate（image-png）过去一年不只是继续提速，还真正进入了超大规模生产环境：作者在新博文里确认，它已经自 Chromium M139 起成为 Chromium 各平台默认 PNG 实现，同时也随着 glycin / image-rs 的推广，进入了越来越多 GNOME 应用的默认图像加载路径。

这次更新最值得关注的点有几个：

• 在解码性能上，image-png 依旧保持很强优势。文中基于 2848 张图像语料给出的数据里，Ryzen 9 7950X 上可达 410.8 MP/s average / 339.9 MP/s geomean，Apple M4 上可达 387.7 MP/s average / 310.5 MP/s geomean，继续领先 libpng、stb_image、spng 等传统 C 实现
• Chromium 采用它并不只是因为“Rust 更安全”，还要求它在 功能、兼容性、正确性、性能 上都不能掉链子。为满足浏览器场景，项目补齐了 部分下载时的中间解码状态显示，并加入了 mDCV / cLLI 等新 chunk 支持
• GNOME 方向的价值点则更偏向 内存安全 与 APNG 支持。由于上游 libpng 长期没有内建 APNG，很多 Linux 桌面应用此前并不能默认支持动画 PNG；切到 image-rs / glycin 路线后，这个短板被真正补上
• 性能提升背后并不神秘，主要来自 原地 unfilter、更合理的内部 buffer 尺寸、对 interlacing 的专项优化，以及 simd_adler32 / crc32fast 等生态组件对 AVX-512、NEON 的进一步利用

这条新闻真正有传播力的地方在于：它再次证明了 内存安全实现并不必然牺牲底层性能，而且 Rust 图像基础设施已经不只是“实验室成绩好看”，而是被桌面与浏览器主线真正吃进去了。

文章链接：https://blog.image-rs.org/2026/06/18/png-adoption.html 项目链接：https://github.com/image-rs/image-png/

原文链接：https://blog.image-rs.org/2026/06/18/png-adoption.html

ClickHouse 谈在 150 万行 C++ 数据库里引入 Rust：不是重写，而是可审计增量接入

Rust in Production Podcast 新一期找来了 ClickHouse 创始人 Alexey Milovidov 和长期维护 sqlx 的 Austin Bonander，聊的是一个很多团队都关心的问题：当你的主系统已经是 150 万行、每天跑数千万测试的 C++ 代码库 时，Rust 究竟该怎么进场？

这期内容最有价值的地方，不在于“Rust 很棒”的空泛表态，而是把大型存量系统引入 Rust 的现实阻力摊开讲了：

• ClickHouse 并没有把 Rust 当作“一把梭的重写按钮”，而是优先考虑 把 Rust 组件以可审计、可复现、能满足合规要求 的方式接入现有 C++ 服务
• 讨论里反复提到 Cargo 与 CMake 的边界。对多语言 monorepo 来说，语言本身往往不是最难的，真正麻烦的是 构建系统、依赖供应链、FIPS 合规、可重现构建 这些工程现实
• 节目里还专门提到 Corrosion 这类 CMake ↔ Rust 集成方案，以及 ring、delta-kernel-rs、h3o 等案例，说明 ClickHouse 看重的不是“会不会写 Rust”，而是 Rust 组件能否在已有基础设施里稳定落地
• Austin 本身同时维护 sqlx、参与 ClickHouse Rust 工具链，这让节目兼具数据库一线实践与 Rust 工程生态视角，信息密度相当高

这条内容的意义在于，它给很多大型基础设施团队提供了一个更现实的范式：Rust 的进入方式未必要从重写开始，更可能是从局部、受控、可复现的关键路径切入。

节目页面：https://corrode.dev/podcast/s06e06-clickhouse/ ClickHouse 仓库：https://github.com/ClickHouse/ClickHouse 相关 Rust 客户端：https://github.com/ClickHouse/clickhouse-rs

原文链接：https://corrode.dev/podcast/s06e06-clickhouse/

soa-rs 1.0.0 发布：用 Rust 宏把 Struct of Arrays 做成可落地容器

soa-rs 发布了 1.0.0，核心目标很明确：把 Rust 里常见、但经常要手搓样板代码的 Struct of Arrays（SoA） 数据布局，做成一套更容易在真实项目里落地的容器与派生宏方案。

这次 1.0.0 虽然不是那种“大而全”的重写版本，但几个更新方向都很实用：

• 新增 SoaClone derive macro，让 SoA 类型在需要复制时更自然，不必再围着内部字段自己补样板逻辑
• 改进了 extend 路径里的 size hint 使用方式，意味着批量追加数据时可以更稳地减少不必要的分配与搬运
• 修正了 soa![Foo; n] 在 n > 2 时的行为，让这个宏在更一般化的批量构造场景下按预期工作
• 从 release note 也能看出，项目已经不只是作者一人玩具，开始有外部贡献者参与 1.0.0 的打磨

SoA 这类话题表面上不如“新框架发布”显眼，但它对 ECS、数值计算、批处理、cache-friendly 数据访问 都很关键。soa-rs 做到 1.0，意味着 Rust 生态里这块“高性能布局工具”又多了一个更成熟的选择。

发布说明：https://github.com/tim-harding/soa-rs/releases/tag/1.0.0 项目仓库：https://github.com/tim-harding/soa-rs

原文链接：https://github.com/tim-harding/soa-rs/releases/tag/1.0.0

meon：扁平化、零拷贝、声明式的 Rust 文本解析引擎

meon 是一个很有意思的新项目，作者把它定义成 flat, fast, declarative parsing engine：它不走传统“先建 AST，再遍历节点”的路，而是把解析结果直接组织成 Struct of Arrays 风格的扁平表结构，让不同元素类型各自存放在独立连续数组里。

项目的设计亮点很鲜明：

• 对 Markdown 或其他文本格式来说，解析结果不是一棵 heterogeneous tree，而是像 headings、links、bolds、bullet_items 这样按类型拆开的连续 Vec，访问某一类元素时更接近顺序扫描，cache 友好得多
• 所有元素本质上都是指向原始字节切片的 Span { start, end }，也就是 零拷贝偏移引用；真正需要转成字符串时再解引用
• 项目提供 define_parser! 宏，在编译期生成 parser、content struct 与 find_* 迭代器，强调 没有运行时解释器、没有 vtable、没有额外分发开销
• 文档里还给出了 meon-md、benchmarks、fuzzing 等配套内容，说明这不是只停在概念层面的 parser toy，而是在认真往可测、可 benchmark、可扩展的方向走

从工程角度看，这个项目最值得关注的不是“又一个 Markdown 解析器”，而是它在尝试回答一个更底层的问题：如果把 Rust 的数据布局思维和编译期生成能力真正用到文本解析里，能不能绕开传统 AST 模型的性能包袱？

项目仓库：https://github.com/vgnapuga/meon crates.io：https://crates.io/crates/meon 架构说明：https://github.com/vgnapuga/meon/blob/main/ARCHITECTURE.md

原文链接：https://github.com/vgnapuga/meon

From Rust中文社区 Mike

社区学习交流平台订阅：

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

Rust Foundation 宣布 OpenAI 成为新的 Platinum Member，并将通过基金会总计投入 60 万美元，用于支持 Rust 项目维护者、技术优先事项以及更广泛的生态建设。这不是普通的企业站台新闻，而是一次直接落到资金层面的长期支持承诺。

这笔投入覆盖的方向也很清楚：

• 资金会通过 Rust Foundation 与 Rust Project 既有机制分发，包括 Project Goals、Rust Innovation Lab 和更直接的维护者支持计划
• Rust Foundation 强调，Rust Project 的治理与技术决策仍然保持独立，企业资金不会改变项目本身的决策结构
• OpenAI 方面给出的理由也很直白：Rust 能帮助他们在 性能、安全性、可靠性 之间不必做痛苦取舍
• OpenAI 的 Predrag Gruevski 还将代表公司进入 Rust Foundation 董事会，而他本身也是 Rust 社区长期活跃成员、cargo-semver-checks 的维护者之一

从社区视角看，这条消息真正重要的不是“又一家大公司来了”，而是 Rust 维护工作正在得到更明确、更结构化的资金支持，而且支持方愿意把钱投向维护者与基础设施这些最难被看见、却最关键的环节。

文章链接：https://rustfoundation.org/media/rust-foundation-welcomes-openai-as-platinum-member-announces-donation-to-rust-project/ 补充说明：https://rustfoundation.org/media/on-openais-support-for-rust/

原文链接：https://rustfoundation.org/media/rust-foundation-welcomes-openai-as-platinum-member-announces-donation-to-rust-project/

你的 Rust 服务未必真的泄漏：问题可能出在分配器而不是业务代码

这篇文章讲的是一个非常实用、也非常容易误判的问题：服务在高并发突发流量后内存冲高不回落，未必是 Rust 代码泄漏，可能只是 allocator 把内存留在 RSS 里了。

作者的排查过程很有参考价值：

• 业务模型是事件驱动 + Tokio 并发任务 + Semaphore 限流，负载呈现 每小时 3–4 次突发、每次约 10 万事件 的形态
• 用 dhat 看堆分配时，程序结束后几乎所有堆内存都被释放了，说明 逻辑层面并没有明显泄漏
• 真正的问题出在 glibc ptmalloc 的 arena / sub-heap / 缓存回收机制：即使对象已经释放，RSS 也可能因为堆顶 trimming、碎片与缓存块未合并而长时间维持高位
• 切到 jemalloc 后，借助 size-class slab 与后台 purging，内存在流量峰值后更容易回到基线；而作者测试 MiMalloc 时，在该类稀疏突发工作负载下并没有得到同样理想的效果

文章写得好的地方在于，它没有停留在“换 jemalloc 就行”，而是把 glibc、jemalloc、MiMalloc 在 Tokio work-stealing + sparse workload 下的行为差异 解释得相当清楚。对做 Rust 服务、容器部署和性能排查的人来说，这基本属于一篇很值得收藏的实战笔记。

文章链接：https://pranitha.dev/posts/rust-and-memory-allocators/

原文链接：https://pranitha.dev/posts/rust-and-memory-allocators/

ProcessKit：在 async Rust 里把“孤儿进程”问题做成内核级整树回收

ProcessKit 是一个面向 Tokio 的 Rust 子进程管理库，核心卖点非常明确：不仅能启动子进程，还要在程序 panic、超时、future 被丢弃时，把整棵进程树一起收干净，解决长期困扰自动化工具、测试框架和后台服务的 orphan-process 问题。

它的设计亮点主要在这里：

• 在 Windows 上用 Job Object，Linux 上优先用 cgroup v2，macOS / BSD 则落到 POSIX process group，保证 kill-on-drop 针对的是整棵树而不只是直接子进程
• 除了回收能力，还打包了 streaming I/O、shell-free pipelines、supervision、timeouts / retries / cancellation 等一整套流程控制能力
• 文档里明确把它和 std::process、tokio::process、duct、command-group 等方案做了对比，突出它的差异点就是 whole-tree containment
• 项目已经发布到 crates.io，MSRV 为 Rust 1.88，并且把错误语义、测试替身、record/replay 等工程能力也一起补齐了

这类项目不一定像新框架那样“显眼”，但对做 CI、编译封装器、集成测试、CLI 编排、开发环境守护进程的人来说，“掉了 future 但孙进程还活着” 这种坑非常真实。ProcessKit 把这件事往前推进了一大步。

项目主页：https://zelanton.github.io/processkit/ crates.io：https://crates.io/crates/processkit 文档：https://docs.rs/processkit 代码仓库：https://github.com/ZelAnton/ProcessKit-rs

原文链接：https://zelanton.github.io/processkit/

Fearless Concurrency on the GPU：把 Rust 所有权模型延伸到 GPU Kernel

这篇新论文提出了 cuTile Rust：一个面向 tile-based GPU kernel 的 Rust 系统，目标是把大家熟悉的 所有权与别名约束，真正带进 GPU 内核编写这件事里，而不是一写 CUDA 就重新回到“你自己保证安全”的世界。

论文里最值得关注的点有几个：

• 它把可变输出拆成互不重叠的片段，让 kernel launch 也能维持主机侧的所有权约束
• 开发者仍然可以在需要时 局部退出安全抽象，保留做底层优化的空间
• 系统不仅管 kernel 代码，还提供了从 同步启动、异步流水线到 CUDA Graph replay 的组合式 host 执行模型
• 性能上并没有为了安全抽象明显掉队：论文给出的数据里，B200 上 element-wise 可到 7 TB/s，GEMM 达到 2 PFlop/s，约为 cuBLAS 的 96%

更有意思的是，作者还给出了一个基于 cuTile Rust 的推理引擎 Grout，用它跑通了 Qwen3 的端到端推理路径。也就是说，这不是只停留在 toy example 的类型系统论文，而是 在高性能 GPU 场景里认真尝试“安全并发 + Rust + 实际推理工作负载” 的一套方案。

论文链接：https://arxiv.org/abs/2606.15991

原文链接：https://arxiv.org/abs/2606.15991

Firefox 从 151.0.0 开始，已经把 gzip 压缩/解压实现切换到 zlib-rs。这意味着一个核心浏览器组件正式把传统 zlib 路径替换为 Rust 实现，同时获得了更好的安全性与相当可观的性能收益。

这次集成并不只是“换个库”那么简单：

• Trifecta 团队从 2024 年夏天开始与 Mozilla 合作，前后花了近两年才真正进到生产环境
• zlib-rs 虽然提供 drop-in replacement 体验，但在不同压缩级别上采用了更接近 zlib-ng 的算法，因此输出字节与压缩长度会与 stock zlib 略有不同，Firefox 测试也因此需要调整
• 集成过程中还撞上了 Intel 13/14 代 Raptor Lake CPU 的已知硬件问题：LLVM 生成的某条字节写入指令会偶发触发错误，Firefox 最终通过一段可审计的小型 unsafe 绕过了这个坑
• 根据文中基准，zlib-rs 在 Linux x86_64 上的一次性解压提升非常夸张，部分场景可达 20x 以上

这条新闻的意义不只是“某个 crate 更快了”，而是 Rust 基础设施正在真实进入超大规模终端软件的底层路径。

文章链接：https://trifectatech.org/blog/zlib-rs-in-firefox/

原文链接：https://old.reddit.com/r/rust/comments/1u7cgen/zlibrs_in_firefox_trifecta_tech_foundation/

just 1.53.0：十周年版本带来列表类型与并行依赖映射

命令运行器 just 迎来了一个很适合纪念节点的版本：作者回顾自己十年前提交的第一条 commit，同时发布了 just 1.53.0，核心新特性是 lists（列表）。

这次更新的关键点很清楚：

• just 过去基本把所有值都当作字符串处理；现在改成了“所有值都是字符串列表”，原本的字符串可视作长度为 1 的列表
• 这一变化让不少过去难以优雅表达的能力终于落地，比如变参的正确引用、把变参批量映射成依赖、以及并行展开任务
• 作者给出的例子里，[parallel] build *args: *(compile *args) 可以把参数列表映射成并行构建依赖
• 作者还提到 just 从早期开始就保持了比较完整的单元测试与集成测试，目前累计已有 2076 个测试

从传播角度看，这不是那种“新做了一个小工具”的帖子，而是 Rust 生态里成熟生产力工具的一次类型系统升级。

发布说明：https://github.com/casey/just/releases/tag/1.53.0

原文链接：https://old.reddit.com/r/rust/comments/1u7qtfr/happy_ten_years_of_just_and_lists/

xxutf-rs：把 Unicode 规范化与大小写折叠推到 GB/s 级别

作者发布了 xxutf-rs，这是其底层 C 库 xxUTF 的 Rust 绑定，目标非常直接：把 Unicode normalization 与 case folding 这些通常不太“性感”的文本处理基础能力，做出接近 GB/s 级别 的吞吐。

项目当前状态与亮点包括：

• crate 仍处在 alpha 阶段，但作者表示测试覆盖已经足以支撑对外试用
• 主要提供 NFC / NFD 等规范化路径，以及大小写折叠能力
• API 设计明确不想简单复刻 ICU4X 或 unicode-normalization，而是探索更偏性能导向的接口形态
• 作者还专门写了一篇博客解释 Unicode 规范化本身是什么、为什么值得关心

这类项目很容易被忽视，但只要你做搜索、索引、排序、标识符匹配、跨语言文本处理，Unicode 基础设施的性能与正确性都会直接影响上层产品体验。

项目链接：https://github.com/dzfrias/xxutf-rs 博客说明：https://dzfrias.dev/blog/xxutf/#unicode-normalization

原文链接：https://old.reddit.com/r/rust/comments/1u7r8m7/unicode_normalization_at_gbs/

Fearless Embedded Rust：用 Pico W 驱动乐高小车的 no_std 异步实战

这篇文章展示了一个很有“Rust 教学味”的项目：用 Raspberry Pico W、Embassy、no_std async Rust 和乐高动力组件，做一辆可以通过 Wi‑Fi/TCP 从电脑远程控制的无线小车。

它有意思的地方不只是“能跑起来”，而是作者把很多嵌入式 Rust 的典型约束都压进了一个相对直观的项目里：

• 运行环境是 no_std，没有分配器，很多缓冲区都要静态规划
• 使用 Embassy 处理 async 执行、网络、USB 日志等能力，让并发模型保持清晰
• 不是用常见 hobby 项目那种高层 Python 路线，而是直接做更贴近底层的 Rust 实现
• 小车通过 Wi‑Fi 接收控制命令，仍然保持全无线，且尽量复用乐高现成供电与电机体系

如果说很多 embedded Rust 内容还停留在点灯、串口、温湿度传感器，这篇算是把 网络、驱动、供电、并发、调试链路 都揉进了一个更完整的实战案例里。

文章链接：https://dystroy.org/blog/picomobile/

原文链接：https://old.reddit.com/r/rust/comments/1u7jiir/fearless_embedded_rust_driving_a_lego_car_with_a/

From Rust中文社区 Mike

社区学习交流平台订阅：

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

作为一个长期与 API 打交道的开发者，我发现市面上主流的 API 测试工具（如 Postman、Insomnia 等）大多基于 Electron 或 Web 技术构建。随着时间推移，它们变得越来越臃肿，启动慢、占用内存大，有时甚至让人觉得它们比我要调试的服务还要卡顿。

出于对“极致原生体验”的追求，我决定自己动手，使用 Rust 和 Zed 编辑器开源的底层渲染框架 GPUI，开发了这款高性能的桌面 API 调试工具 —— HiPoster。

✨ 核心亮点：

• 🚀 极其轻快： 纯 Rust 编写，得益于 GPUI 的 GPU 硬件加速，启动秒开，操作丝滑，彻底告别 Electron 的卡顿感。
• 💻 跨平台原生体验： 支持 macOS（原生 Universal 芯片级支持）、Windows 和 Linux。
• 🎨 颜值在线： 内置多种精美开发者主题（GitHub Light, Solarized, Monokai, Catppuccin 等），代码高亮赏心悦目。
• 🛠 完整协议支持： 轻松处理各种复杂的 Headers、Query Params，支持 Raw JSON、FormData、UrlEncoded 等多种 Body 类型，内置 Bearer/Basic 鉴权。
• 📦 开箱即用： 历史记录自动保存，支持数据本地化持久存储。

📖 附带了一本开发指南： 在开发过程中，我踩了不少 GPUI 框架的坑。为了帮助想用 GPUI 开发桌面应用的同学，我把项目的架构、脏标记渲染优化、异步网络处理等实战经验写成了一本开源的《GPUI 实战进阶指南》（使用 mdBook 生成），代码仓库里可以直接看。

🔗 项目地址： https://github.com/wandercn/hiposter (https://github.com/wandercn/hiposter) (如果觉得有意思，欢迎给个 Star ⭐️ 支持一下！)

大家在日常调试 API 时有什么特别的痛点吗？欢迎在评论区交流，我很乐意在后续版本中加入大家需要的功能！

不用导入数据库，不用写脚本，不用装一堆工具。一份 CSV、一个 Excel、一张 MySQL 表，用一条标准 SQL 就能查、能联、能导出。打开即用，全程离线。

先放结论：如果你经常要从各种文件和数据库里捞数据、对数、做清洗，EasyDB 大概率能帮你省下大量「为了查几行数据而折腾环境」的时间。这篇文章会先讲它能帮你做什么，再讲 v2.11.0 这次更新带来了什么。

一、它到底能帮你解决什么问题？

我们每天都在和数据打交道，但很多场景其实卡在「工具太重」上：

• 想查一份几百 MB 的 CSV 里满足条件的行 → Excel 打不开，命令行 grep 又写不出复杂条件
• 想把一个 Excel 报表和数据库里的表对一下账 → 得先把 Excel 导入数据库，建表、定字段类型、写导入脚本……
• 想把清洗后的数据生成 INSERT 语句灌进另一个库 → 手写 SQL 或者临时写个 Python 脚本
• 想用窗口函数、子查询分析本地文件 → 文件不是数据库，根本没法直接跑 SQL

EasyDB 的思路很简单：把文件直接当成数据库表，让你用最熟悉的 SQL 去操作一切数据源。 你已经会的 SQL 技能，在这里能用到 CSV、Excel、JSON、Parquet 上，甚至和 MySQL、PostgreSQL 混在一条语句里查。

-- Excel 报表 × PostgreSQL 库存表，一次 JOIN 对完账
SELECT t1."product_name", t2."inventory_count"
FROM read_excel('/data/products.xlsx') AS t1
INNER JOIN
read_postgres('inventory', host => 'localhost', username => 'postgres', db => 'mydb') AS t2
ON t1."product_id" = t2."id"
WHERE t2."inventory_count" < 100;

没有建表，没有导入，没有 ETL。把文件路径写进 SQL，回车，结果就出来了。

二、它适合谁？几个真实场景

数据分析师 / 运营：拿到一份几十万行的 Excel/CSV，只想筛出符合条件的几行、做个分组统计。拖进 EasyDB，写一句 SQL，⌘Enter 就出结果——比在 Excel 里拉筛选、写公式快得多，文件再大也不卡。

-- 按部门算平均薪资（窗口函数）
SELECT "name", "department", "salary",
       AVG("salary") OVER (PARTITION BY "department") AS dept_avg
FROM read_csv('/data/employees.csv');

DBA / 后端工程师：要把一批文件数据导入数据库，或者把一张表的数据迁到另一个库。用 EasyDB 查出来，直接导出成 INSERT / UPDATE 语句（可选 MySQL / PostgreSQL 方言），还能重命名字段、移除多余列、指定每列的目标类型，生成的 SQL 拿来就能执行。

需要跨源核对数据的人：本地文件和线上数据库的数据不一致？不用来回导出导入，一条 JOIN 直接在同一条 SQL 里比对。

任何临时要查数据、又不想搭环境的人：日志文件、导出的报表、第三方给的数据包……拖进来就能查。完全离线，数据不出本机，敏感数据也放心。

-- 在日志文件里用正则筛出错误行（整行作为一列 column_1）
SELECT *
FROM read_text('/data/app.log', has_header => false)
WHERE REGEXP_LIKE("column_1", '^ERROR:\s+\d{3}');

三、为什么是 EasyDB，而不是别的？

• 真·开箱即用：原生桌面应用（macOS / Windows），下载安装就能用，不需要 CLI、不需要写代码、不需要联网加载资源
• 够快、够省：基于 Rust + Apache DataFusion，几百 MB 到数 GB 的文件也能稳定处理，硬件要求不高
• SQL 足够完整：多表 JOIN、子查询、窗口函数、正则匹配……DataFusion 提供的是完整 SQL，不是阉割版
• 拖拽即生成 SQL：文件拖进编辑器自动生成查询语句，配合语法高亮、智能补全（函数名 + 列名）、格式化，写起来很顺
• 数据安全：纯本地运行，全程离线，数据不上传任何服务器

经常有人问：「这不就是 DuckDB 吗？」两者定位不同，各有长短，这里客观对比一下：

DuckDB 的优势：自研向量化引擎性能更强，尤其在大规模分析查询上；生态成熟、扩展多，能作为库嵌入程序，适合做数据管道和自动化。它的代价是更偏开发者——没有原生 GUI，需要命令行或写代码。

EasyDB 的优势：原生桌面应用、开箱即用、拖拽生成 SQL、内置 SQL 导出，会写 SQL 就能上手，适合临时查数、对账、做清洗。它的不足也很明显——查询性能和生态扩展性不及 DuckDB，也不适合嵌入到其他程序里做自动化。

一句话：要把分析能力嵌进程序、追求极致性能，选 DuckDB；想拖个文件写句 SQL 马上拿结果，选 EasyDB。

四、v2.11.0 这次更新了什么

距离上次在社区分享 v2.8.0，EasyDB 连续迭代了 v2.9、v2.10、v2.11，这里一次性讲清楚。

read_json() 回归，标准 JSON 数组终于支持

早期切换查询引擎时 read_json() 曾被临时移除，只能逐行读 NDJSON。但很多人手上的 JSON 其实是标准数组格式（[{...}, {...}]）。这次它正式回归，而且更聪明：

• 自动识别格式——按文件内容嗅探，[ 开头当标准 JSON 数组，{ 开头当 NDJSON，嗅探不出再回退扩展名
• .json 与 .ndjson 都能直接用，编辑器补全和拖拽模板统一改用 read_json()
• 修复了带 UTF-8 BOM 的 JSON 数组被误判为 NDJSON 的问题

SELECT * FROM read_json('/data/records.json') WHERE "status" = 'active';

导出 SQL 一键复制到剪贴板

SQL 导出对话框新增**「复制 SQL 语句」，生成的 INSERT / UPDATE 不必再落地成文件，直接复制贴进数据库客户端就能跑。导出 / 复制全流程都加了进行中 / 成功 / 失败**状态提示；复制超过 10,000 行会自动截断并给出警告。

保存常用查询，告别重复粘贴（v2.10）

• 常用 SQL 可命名保存，在左侧栏随时加载，支持搜索筛选与删除
• 查询历史增强：关键词搜索、显示条数配置（50 / 100 / 200 / 500 / 全部）、按时间清理（7 / 30 / 90 天前或全部清空）
• 执行后自动切到结果页签，底部显示本次查询耗时

表头直接显示列类型（v2.9）

查询结果表头会展示每列的 Arrow 类型，一眼看清数据结构；SQL 导出的列类型配置也直接复用查询结果的类型信息，少一次后端请求。

性能与稳定性

• SQL 生成改用 RecordBatch 批处理，显著降低导出内存占用
• Apache DataFusion 升级至 53.1.0
• 优化 Excel 日期时间解析，修复序列号被误当日期字符串、空格分隔日期时间等问题
• 修复注册远程文件路径（HTTP / S3 等 URL）时误报「文件不存在」的问题

数据源一览

技术栈

快速开始

1. 访问 GitHub Releases 下载安装包
2. macOS：下载 .dmg，拖拽到应用程序文件夹
3. Windows：下载 .exe，运行安装程序
4. 拖拽任意文件到编辑器自动生成 SQL，按 ⌘Enter 执行

macOS 若提示「应用已损坏」，在终端执行： xattr -r -d com.apple.quarantine /Applications/EasyDB.app

GitHub：https://github.com/shencangsheng/easydb_app

EasyDB 是我利用业余时间维护的开源项目，如果它能帮你少折腾一点、多省一点时间，欢迎点个 Star，也欢迎到 Issues 提想法和反馈——很多功能就是这么一点点被大家提出来、加进去的。

作者发布了 QDRV 1.0（Quantum Dynamic Range Video）首个公开版本，目标是为 HDR 工作流提供一套更开放、可审计的浮点视频格式与工具链，用来替代过早量化到整数域、并依赖专有元数据生态的传统 HDR 管线。

项目核心特点：

• 纯 Rust workspace，共 9 个 crate；代码树里只有 2 处 unsafe，都位于 ZFP FFI 边界
• 采用双层模型：qdrv64 负责 Float64 线性光母版，qdrv32 负责 Float32 PQ/HLG 交付
• 交付层基于标准 AV1，可与 ffmpeg、dav1d、MP4Box、Shaka Packager 等现有工具互通
• 每帧元数据以内嵌 ITU-T T.35 OBU 形式携带，跨 MP4 / CMAF / IVF / OBU 封装仍可保留
• 还支持 HMAC 与 FIPS 204 ML-DSA 后量子签名、每帧 Merkle inclusion proof，以及实验性的浏览器端解码路径

项目主页：https://github.com/qdrv/QDRV

原文链接：https://old.reddit.com/r/rust/comments/1u6yh7p/qdrv_10_an_open_floatingpoint_hdr_video_format/

reliakit 1.0：零依赖、no_std 友好的 Rust 可靠性工具箱

作者发布 reliakit 1.0，这是一个由多个小型 crate 组成的 Rust 可靠性工具箱，主打“在边界处验证数据，把可信约束带进程序内部”，并尽量避免引入运行时耦合与额外依赖树。

包含的能力很完整：

• 验证型基础类型：Port、Email、HttpUrl、BoundedStr、Percent 等
• Secret redaction：Secret<T> / SecretString 在日志和调试输出中自动脱敏
• 有界集合、严格 JSON / CSV、规范化二进制编码
• 运行时无关的 resilience 组件：retry/backoff、circuit breaker、rate limiter、bulkhead、timeout
• 整个项目坚持零第三方依赖、#![forbid(unsafe_code)]、核心 crate 面向 no_std

仓库地址：https://github.com/satyakwok/reliakit

原文链接：https://old.reddit.com/r/rust/comments/1u6p61k/reliakit_10_small_zerodependency_no_std/

Typst 0.15：变量字体、MathML 与多文件导出一起到来

Typst 发布 0.15，这是迄今为止体量最大的一次更新之一。新版本一口气把变量字体、MathML 支持、bundle/multi-file 导出、多 bibliography、多个 PDF 标准并行支持等能力推进到了更可用的状态。

这次更新的亮点包括：

• 变量字体支持：可直接按 weight / stretch / optical size 等轴控制字体变体
• HTML 导出补上 MathML，公式终于不再只能退化成图片或 SVG
• 新的 bundle export 能一次导出多个 HTML / PDF / SVG / PNG 文件，适合文档站点与多页面内容
• 原生支持多个 bibliography，适合按章节或按主题拆分参考文献
• 官方文档已迁移到 Typst 本身，并首次提供完整迁移指南与可打印版本

文章链接：https://typst.app/blog/2026/typst-0.15

原文链接：https://old.reddit.com/r/rust/comments/1u6n46u/typst_typst_015_contains_multitudes_typst_blog/

termem：按目录索引多种 coding agent 会话的 Rust CLI

作者做了一个名为 termem 的 Rust CLI，想解决多种 coding agent 会话彼此割裂、跨工具接续困难的问题。它会把 Claude Code、Codex、Gemini、opencode、shell 等会话按目录索引进 SQLite，重点不是“再调一个模型”，而是给终端工作流加上一层共享记忆与恢复能力。

项目目前主打这些能力：

• 按目录与子目录组织会话，方便在当前项目上下文里找回历史工作
• 可按消息内容、标题、路径做搜索，而不只是按 session 名称翻
• 支持恢复准确的历史会话，并回到正确工具和目录继续工作
• 零网络请求、零模型调用，只负责索引、检索与恢复

项目主页：https://termem.com/

原文链接：https://old.reddit.com/r/rust/comments/1u6sp8i/termem_a_rust_cli_that_indexes_codingagent/

From Rust中文社区 Mike

社区学习交流平台订阅：

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

产品能力：一个引擎，两种用法

FlowDB 提供两层 API：

底层：LSM-Tree Key-Value 引擎

use flowdb::{Engine, Config};

let engine = Engine::open(Config::new("/tmp/mydb"))?;
engine.put(b"key", b"value")?;
let val = engine.get(b"key")?;         // Option<Vec<u8>>
engine.delete(b"key")?;

支持前缀扫描、范围扫描、批量写入、迭代器。这是一个完整的 LSM 引擎，但功能定位很克制——不像 RocksDB 那样有数百个配置项。

上层：JsonDB 文档层

JsonDB 是构建在 LSM 引擎之上的 JSON 文档数据库，兼容 IndexedDB API 范式（object store + index）：

use flowdb::{Engine, Config, JsonDB, Transaction, QueryBuilder};
use serde_json::json;

let engine = Engine::open(Config::new("/tmp/myjsondb"))?;
let jsondb = JsonDB::open(engine)?;

// 创建 store 和索引
let store = jsondb.create_object_store("users", "id")?;
jsondb.create_index("users", "email", true)?;  // unique index

// 写入文档
jsondb.put("users", json!({"id": "u1", "name": "Alice", "email": "alice@x.com", "age": 30}))?;

// 按主键查询
let doc = jsondb.get::<Value>("users", "u1")?;

// 按索引查询
let doc = jsondb.get_by_index::<Value>("users", "email", "alice@x.com")?;

// 范围扫描 + 排序
let results = jsondb.range_by_index::<Value>(
    "users", "age", 20..=40, SortDir::Asc, None
)?;

// 声明式查询 (自动选索引)
let results = QueryBuilder::new("users")
    .where_eq("email", "bob@x.com")
    .collect(&jsondb)?;

核心特性：

• 多索引支持（唯一/非唯一，单字段/复合）
• 嵌套字段查询（"address.city" 点号路径）
• 事务支持（OCC + MVCC，批量原子提交，自动回滚）
• 自动递增主键
• 范围扫描、分页、排序

与 RocksDB 的对比

M 系列芯片, 100K records, 128B value:

JsonDB 文档层性能

（写入瓶颈在 fsync，可用 SyncMode::IntervalMs 或批量提升）

为什么点查比 RocksDB 快 11 倍？

1. Vec memtable — 读路径上活跃数据无 BTreeMap 遍历开销
2. Key 级 bloom — 命中率远高于 (key, ts) 级
3. 无 CGo/CXX 跨语言开销 — 纯 Rust 调用，无需 FFI
4. 配置极简 — 不做 RocksDB 那种上百项调优，默认就快
5. BlockMetaIndex 二维索引 — 按 key 和按时间双索引加速

GitHub: https://github.com/restsend/flowdb crates.io: flowdb

欢迎 issue / PR / 讨论。

这是一个高性能、交互式的命令行（CLI）应用程序，用来查看 2026 年 FIFA 世界杯的分组和积分榜情况。

🌟 项目背景与亮点

这个项目最初是用 Java 实现的，现在我们使用 Rust + TeaQL 数据引擎 + SQLite 进行了完全的重写。得益于 Rust 的特性，这个版本实现了零冷启动开销和极速的执行效率。

最酷的是，它被编译成了一个完全静态链接的独立可执行文件（基于 musl），并打包进了一个 scratch Docker 镜像中，整个 Docker 镜像大小不到 7MB！完全不需要 JVM 或任何其他外部运行时依赖。 核心功能包括： • 交互式 CLI Shell： 带有 wc2026> 提示符的完整 REPL 体验。 • 漂亮的终端视图： 支持查看 A-L 分组，拥有完美的文本对齐、Emoji 国旗支持和动态的颜色高亮。 • TeaQL 无缝集成： 使用 TeaQL 生成的 Rust 宏和 ORM 直接映射到内嵌的 SQLite 数据库。

🛠️ 深入了解 TeaQL 核心 API 实践

在这个项目中，我们深度使用了 TeaQL 框架提供的三大核心 API，不仅让数据操作更加类型安全，也让业务代码极其易读。以下是我们在项目中的一些真实使用场景，希望能给大家在 Rust 中做数据持久化一些参考：

1. Q API (Query API - 查询 API) Q API 提供了强类型、可链式调用的数据库查询方法，非常适合复杂的多表级联和排序。

// 场景：关系联表查询与复杂多重排序
let standings = Q::group_standings()
    .select_tournament_team_with(Q::tournament_teams().select_self()) // 级联加载队伍数据
    .with_match_group_matching(Q::match_groups().with_id_is(g.id()))
    .order_by_points_desc()
    .order_by_goal_difference_desc()
    .order_by_goals_for_desc()
    .purpose("cli").execute_for_list(ctx).await?;

2. E API (Expression Facade - 表达式门面) E API 提供了一种安全、强类型的方式，用来从已加载的实体中提取值或导航关联关系，避免手写魔术字符串。

// 场景：强类型安全地提取实体数据
let name = E::tournament(entity)
    .get_tournament_name()
    .eval();

3. Entity API (实体 API) Entity API 负责状态变更（增、删、改），并且它内置了非常健壮的审计日志（Audit Logging）功能。

// 场景：数据初始化与带审计追踪的插入
let mut t = Q::tournaments().new_entity(ctx);
t.update_tournament_name("FIFA World Cup 2026".to_string());
t.update_total_teams(48);

// 保存实体的同时，生成详细的 trace log 用于后续追踪
t.audit_as("Seed tournament").save(ctx).await?;

🚀 如何体验？

你可以直接使用 Docker 秒速体验（由于镜像极小，拉取瞬间完成）：

docker run -it --rm teaql/worldcup2026:latest group A

或者克隆代码并在本地运行：

cd rust-workspace
cargo run

项目的代码结构非常清晰，分为领域模型 models/ 、生成的实体库 generate-lib/ 和主应用 rust-workspace/ 。非常适合作为学习 Rust 命令行开发 以及 TeaQL 框架使用 的参考样例。

非常欢迎大家去 Repo 看看，跑一下代码。如果觉得有意思欢迎点个 Star ⭐️，也期待在评论区听到你们的建议和探讨！

🔗 项目仓库地址：https://github.com/teaql/teaql-rust-app-examples/tree/main/001-world-cpu-2006-cli

作者从 2024 年开始出于学习目的打造 Zinnia，一款用（几乎）100% Rust 编写、努力避免 unsafe 代码的模块化 64 位类 Unix 内核。目前已能在大量真实 x86_64 机器上启动。

主要特性：

• 实现大量 POSIX 系统调用，并支持 Linux/BSD 常见扩展（epoll、timerfd），可运行 Wayland/X11 现代桌面
• 驱动以模块形式实现——编译为 Rust ELF dylib，在启动时从 initrd 动态加载链接，类似 Linux 模块机制
• 基于 Limine 引导器，支持从任意 UEFI 系统启动
• 规划中：aarch64、riscv64 支持

项目主页：https://zinnia-os.org

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

Diplomat：面向 Rust 库的多语言单向 FFI 工具

Manish Goregaokar 撰文介绍 Diplomat，一个在 ICU4X（Unicode 库 Rust 实现）项目中发展出的多语言单向 FFI 工具。设计初衷：当 Rust 库需要同时暴露接口给 C++、JS、Dart、JVM 等多种语言时，手动维护 FFI 绑定极不可行。

核心理念是"单向"FFI：Rust 作为权威端，代码生成器将 Rust 接口机械映射为各目标语言的绑定，而非双向互相暴露实现细节。经过数年在 ICU4X 上的生产验证，现已正式面向更广泛 Rust 库推广。

GitHub：https://github.com/rust-diplomat/diplomat

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

deconvolution：28 种图像去卷积/复原算法的 Rust 库

作者发布了 deconvolution crate，集成了 28 种图像去卷积/复原方法，覆盖从实用模糊消除到科研级成像算法。

支持的方法包括：

• 逆滤波、Wiener、Richardson-Lucy、约束优化、近端算法、Krylov、MLE 复原
• 盲 Richardson-Lucy、盲最大似然、参数化 PSF 估计
• 高斯、运动、散焦、显微镜模型等多种卷积核

底层使用 image::DynamicImage 与 ndarray，crates.io 已发布，仍在活跃开发中。

GitHub：https://github.com/pbkx/deconvolution

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

From Rust中文社区 Mike

社区学习交流平台订阅：

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

祺洛 AI是一个基于 Rust + Vue 3 的 AI 聊天管理平台，提供多供应商 AI 接入、用户管理、套餐计费、微信生态管理的一站式解决方案。

解决了什么问题？

核心优势

⚡ 性能 — Rust 原生

• 单二进制部署，无运行时依赖
• 内存占用约 15MB（空载），并发
• 启动时间 < 1 秒

🔌 扩展 — 多供应商架构

提供统一的 AI 供应商接口，目前已兼容：

• ✅ OpenAI / Azure OpenAI
• ✅ Anthropic Claude
• ✅ 通义千问（Qwen）
• ✅ DeepSeek
• ✅ 百度文心一言
• ✅ 任何 OpenAI 兼容接口

🎯 完整 — 开箱即用

• AI 管理：供应商、Key、用量、聊天记录、归档
• 用户管理：普通用户（Access Key 接入）和管理员（后台接入）
• 计费体系：VIP 套餐、用量计费、支付二维码
• 系统管理：RBAC 权限、菜单、字典、定时任务、代码生成器
• 微信管理：公众号、菜单、自动回复、消息、用户

🛡️ 可靠 — 企业级特性

• JWT 认证 + 白名单 Token 管理
• 完整的操作审计日志
• 数据库读写分离与连接池
• Redis 缓存加速
• CORS 安全配置

适用场景

技术栈

社区

• ⭐ GitHub: github.com/chelunfu/qiluo_ai
• 💬 问题反馈：GitHub Issues
• 📖 完整文档：https://www.qiluo.vip

🔐 安全性大幅增强

• 移除 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() 方法中，是确保数据完整性和系统高可用性的关键。

问题背景

使用 snafu 进行错误处理时，我们通常需要：

1. 为每个错误变体手动添加 location 字段
2. 添加相应的属性（#[snafu(implicit)]、#[serde(skip)]）
3. 为复杂的 source 字段添加 #[snafu(source(false))]
4. 手动实现工厂方法来创建错误实例

这导致了大量的样板代码：

#[derive(Debug, Serialize, Snafu)]
#[serde(tag = "type")]
pub enum ApiError {
    #[serde(rename = "validate_error")]
    ValidateError {
        message: String,
        #[serde(skip)]
        #[snafu(implicit)]
        location: snafu::Location,
    },
    
    #[serde(rename = "internal_error")]
    InternalError {
        message: String,
        #[serde(skip)]
        #[snafu(source(false))]
        source: Option<Box<dyn std::error::Error + Send + Sync>>,
        #[serde(skip)]
        #[snafu(implicit)]
        location: snafu::Location,
    },
}

impl ApiError {
    #[track_caller]
    pub fn validate_error(message: String) -> Self {
        ApiError::ValidateError {
            message,
            location: GenerateImplicitData::generate(),
        }
    }
    
    #[track_caller]
    pub fn internal_error(message: String) -> Self {
        ApiError::InternalError {
            message,
            source: None,
            location: GenerateImplicitData::generate(),
        }
    }
    
    #[track_caller]
    pub fn internal_error_with_source(message: String, source: Option<Box<dyn std::error::Error + Send + Sync>>) -> Self {
        ApiError::InternalError {
            message,
            source,
            location: GenerateImplicitData::generate(),
        }
    }
}

解决方案：#[with_err_location] 宏

#[with_err_location] 宏可以自动化所有这些工作，让您只需要定义核心的错误结构：

#[with_err_location]
#[derive(Debug, Serialize, Snafu)]
#[serde(tag = "type")]
pub enum ApiError {
    #[serde(rename = "validate_error")]
    ValidateError {
        message: String,
    },
    
    #[serde(rename = "internal_error")]
    InternalError {
        message: String,
        source: Option<Box<dyn std::error::Error + Send + Sync>>,
    },
}

核心特性

1. 自动添加 Location 字段

宏会为每个枚举变体自动添加 location: snafu::Location 字段，并配置必要的属性：

• #[snafu(implicit)]：让 snafu 自动填充位置信息
• #[serde(skip)]：在序列化时跳过该字段（默认行为）

2. 智能 Source 字段处理

宏能识别复杂的 source 字段类型，并自动添加 #[snafu(source(false))] 属性：

// 自动识别并处理
source: Option<Box<dyn std::error::Error + Send + Sync>>

3. 自动生成工厂方法

宏为每个变体生成相应的工厂方法：

普通变体

// 生成：
pub fn validate_error(message: String) -> Self { ... }

复杂 Source 字段变体

对于包含 Option<Box<dyn Error + Send + Sync>> 类型的 source 字段，宏会生成两个方法：

// 基础方法（source = None）
pub fn internal_error(message: String) -> Self { ... }

// 带 source 的方法
pub fn internal_error_with_source(message: String, source: Option<Box<dyn std::error::Error + Send + Sync>>) -> Self { ... }

4. 灵活的配置选项

全局配置

#[with_err_location(serde = true)]  // 不添加 #[serde(skip)]
#[derive(Debug, Snafu)]
pub enum ApiError { ... }

变体级别配置

#[with_err_location]
#[derive(Debug, Snafu)]
pub enum ApiError {
    #[location(serde = true)]  // 此变体不添加 #[serde(skip)]
    SpecialError {
        message: String,
    },
}

实现细节

宏的工作流程

1. 解析输入：解析枚举定义和宏参数
2. 字段分析：检查每个变体的字段类型和现有属性
3. 添加 Location 字段：为没有 location 字段的变体添加
4. 属性处理：添加必要的 snafu 和 serde 属性
5. 工厂方法生成：基于字段类型生成相应的工厂方法

关键函数

字段类型检测

fn should_add_source_false(field: &syn::Field) -> bool {
    let type_str = field.ty.to_token_stream().to_string();
    let is_option_box_dyn_error = type_str.starts_with("Option < Box < dyn");
    let is_source_field = field.ident.as_ref().map(|name| name == "source").unwrap_or(false);
    is_source_field && is_option_box_dyn_error
}

工厂方法生成

fn generate_factory_methods(input_enum: &ItemEnum) -> darling::Result<TokenStream> {
    // 检测复杂 source 字段
    let has_complex_source = fields_named.named.iter().any(should_add_source_false);
    
    if has_complex_source {
        // 生成两个方法：基础方法和带 source 的方法
    } else {
        // 生成单个方法
    }
}

使用示例

基本使用

#[with_err_location]
#[derive(Debug, Snafu)]
pub enum MyError {
    NetworkError { url: String },
    ValidationError { field: String, message: String },
}

// 使用生成的工厂方法
let error = MyError::network_error("https://api.example.com".to_string());

复杂 Source 字段

#[with_err_location]
#[derive(Debug, Snafu)]
pub enum ComplexError {
    DatabaseError {
        query: String,
        source: Option<Box<dyn std::error::Error + Send + Sync>>,
    },
}

// 两种使用方式
let error1 = ComplexError::database_error("SELECT * FROM users".to_string());
let error2 = ComplexError::database_error_with_source(
    "SELECT * FROM users".to_string(),
    Some(Box::new(io_error))
);

配置选项

#[with_err_location(serde = true)]  // 全局配置
#[derive(Debug, Snafu)]
pub enum ApiError {
    #[location(serde = false)]  // 变体级别覆盖
    InternalError { message: String },
    
    PublicError { message: String },  // 使用全局配置
}

完整代码

#[proc_macro_attribute]
pub fn with_err_location(
    args: proc_macro::TokenStream,
    input: proc_macro::TokenStream,
) -> proc_macro::TokenStream {
    let args = args.into();
    with_err_location::with_err_location_impl(args, input.into())
        .unwrap_or_else(darling::Error::write_errors)
        .into()
} 

use darling::{Error, FromMeta, ast::NestedMeta};
use proc_macro2::TokenStream;
use quote::{ToTokens, quote};
use syn::{Attribute, Field, Fields, ItemEnum, Meta, punctuated::Punctuated, token::Comma};

#[derive(Debug, FromMeta, Default)]
struct WithErrLocationArgs {
    pub serde: bool,
}

pub fn with_err_location_impl(
    args: TokenStream,
    input: TokenStream,
) -> darling::Result<TokenStream> {
    let mut input_enum: ItemEnum = match syn::parse2(input) {
        Ok(v) => v,
        Err(e) => return Err(Error::from(e)),
    };

    // 解析全局参数
    let global_args = if args.is_empty() {
        WithErrLocationArgs::default()
    } else {
        let attr_args = match NestedMeta::parse_meta_list(args) {
            Ok(v) => v,
            Err(e) => return Err(Error::from(e)),
        };
        WithErrLocationArgs::from_list(&attr_args).unwrap_or_default()
    };

    // 遍历枚举的所有变体
    for variant in &mut input_enum.variants {
        // 查找并解析 #[location(...)] 属性
        let (location_config, remaining_attrs) =
            parse_and_remove_location_attrs(&variant.attrs, &global_args)?;

        // 移除 location 属性，保留其他属性
        variant.attrs = remaining_attrs;

        match &mut variant.fields {
            Fields::Named(fields_named) => {
                // 检查是否已经有 location 字段
                let location_field_index = fields_named.named.iter().position(|field| {
                    field
                        .ident
                        .as_ref()
                        .map(|ident| ident == "location")
                        .unwrap_or(false)
                });
                match location_field_index {
                    Some(index) => {
                        // 如果已经有 location 字段，确保它至少有 #[snafu(implicit)]
                        let existing_field = &mut fields_named.named[index];
                        ensure_location_field_has_snafu_implicit(existing_field, &location_config);
                    }
                    None => {
                        // 如果没有 location 字段，则添加一个新的（总是带有 #[snafu(implicit)]）
                        let location_field = create_location_field(&location_config);
                        fields_named.named.push(location_field);
                        fields_named.named.push_punct(Comma::default());
                    }
                }
                // 如果有source 且类型是Option<Box<dyn std::error::Error + Send + Sync>>
                // 需要为其加上#[snafu(source(false))]
                for field in &mut fields_named.named {
                    if should_add_source_false(field) {
                        ensure_source_false_attribute(field);
                    }
                }
            }
            _ => {
                return Err(Error::unsupported_format(
                    "Only named fields variants are supported",
                ));
            }
        }
    }

    // 生成工厂方法
    let factory_methods = generate_factory_methods(&input_enum)?;

    Ok(quote! {
        #input_enum
        #factory_methods
    })
}

/// 解析并移除 location 属性，返回配置和剩余属性
fn parse_and_remove_location_attrs(
    variant_attrs: &[Attribute],
    global_args: &WithErrLocationArgs,
) -> darling::Result<(LocationConfig, Vec<Attribute>)> {
    let mut config = LocationConfig {
        serde: global_args.serde,
    };

    let mut remaining_attrs = Vec::new();

    for attr in variant_attrs {
        if attr.path().is_ident("location") {
            // 解析 location 属性的参数
            match &attr.meta {
                Meta::List(meta_list) => {
                    let nested = meta_list.parse_args_with(
                        Punctuated::<NestedMeta, syn::Token![,]>::parse_terminated,
                    )?;
                    let location_args =
                        WithErrLocationArgs::from_list(&nested.into_iter().collect::<Vec<_>>())?;

                    config.serde = location_args.serde;
                }
                _ => {
                    // 如果没有参数，使用默认配置
                }
            }
        } else {
            // 保留非 location 属性
            remaining_attrs.push(attr.clone());
        }
    }

    Ok((config, remaining_attrs))
}

#[derive(Debug)]
struct LocationConfig {
    serde: bool,
}

/// 确保现有的 location 字段至少有 #[snafu(implicit)] 属性
fn ensure_location_field_has_snafu_implicit(field: &mut Field, config: &LocationConfig) {
    // 根据配置添加或确保有 #[serde(skip)]
    if !config.serde {
        let has_serde_skip = field.attrs.iter().any(|attr| {
            if attr.path().is_ident("serde")
                && let Meta::List(meta_list) = &attr.meta
            {
                return meta_list.tokens.to_string().contains("skip");
            }
            false
        });

        if !has_serde_skip {
            let serde_skip_attr: Attribute = syn::parse_quote! {
                #[serde(skip)]
            };
            field.attrs.push(serde_skip_attr);
        }
    }
    let has_snafu_implicit = field.attrs.iter().any(|attr| {
        if attr.path().is_ident("snafu")
            && let Meta::List(meta_list) = &attr.meta
        {
            return meta_list.tokens.to_string().contains("implicit");
        }
        false
    });

    // 如果没有 #[snafu(implicit)]，则添加它
    if !has_snafu_implicit {
        let snafu_implicit_attr: Attribute = syn::parse_quote! {
            #[snafu(implicit)]
        };
        field.attrs.push(snafu_implicit_attr);
    }
}

/// 检查字段是否需要自动添加 #[snafu(source(false))]
fn should_add_source_false(field: &syn::Field) -> bool {
    let type_str = field.ty.to_token_stream().to_string();

    // 检查是否是 Option<Box<dyn std::error::Error + Send + Sync>> 类型
    let is_option_box_dyn_error = type_str.starts_with("Option < Box < dyn");

    // 检查字段名是否为 "source"
    let is_source_field = field
        .ident
        .as_ref()
        .map(|name| name == "source")
        .unwrap_or(false);

    is_source_field && is_option_box_dyn_error
}

/// 确保复杂 source 字段有 #[snafu(source(false))] 属性
fn ensure_source_false_attribute(field: &mut Field) {
    // 检查是否已经有 #[snafu(source(false))] 属性
    let has_source_false = field.attrs.iter().any(|attr| {
        if attr.path().is_ident("snafu")
            && let Meta::List(meta_list) = &attr.meta
        {
            let tokens_str = meta_list.tokens.to_string();
            return tokens_str.contains("source")
                && (tokens_str.contains("false") || tokens_str.contains("( false )"));
        }
        false
    });

    // 如果没有，则添加 #[snafu(source(false))]
    if !has_source_false {
        let source_false_attr: Attribute = syn::parse_quote! {
            #[snafu(source(false))]
        };
        field.attrs.push(source_false_attr);
    }
}

/// 根据配置创建 location 字段
fn create_location_field(config: &LocationConfig) -> Field {
    if !config.serde {
        syn::parse_quote! {
            #[serde(skip)]
            #[snafu(implicit)]
            location: snafu::Location
        }
    } else {
        syn::parse_quote! {
            #[snafu(implicit)]
            location: snafu::Location
        }
    }
}

/// 为枚举生成工厂方法
fn generate_factory_methods(input_enum: &ItemEnum) -> darling::Result<TokenStream> {
    let enum_name = &input_enum.ident;
    let mut methods = Vec::new();

    for variant in &input_enum.variants {
        let variant_name = &variant.ident;

        // 将变体名转换为 snake_case
        let method_name = convert_to_snake_case(&variant_name.to_string());
        let method_ident = syn::Ident::new(&method_name, variant_name.span());

        match &variant.fields {
            Fields::Named(fields_named) => {
                // 检查是否有复杂的 source 字段
                let has_complex_source = fields_named.named.iter().any(should_add_source_false);

                if has_complex_source {
                    // 生成两个方法：基础方法（source = None）和带 source 的方法

                    // 1. 基础方法：source 为 None
                    let (base_params, base_assignments) =
                        analyze_fields_for_source_method(fields_named, true);
                    let base_method = quote! {
                        #[track_caller]
                        pub fn #method_ident(#(#base_params),*) -> Self {
                            #enum_name::#variant_name {
                                #(#base_assignments,)*
                            }
                        }
                    };
                    methods.push(base_method);

                    // 2. 带 source 的方法
                    let source_method_name = format!("{}_with_source", method_name);
                    let source_method_ident =
                        syn::Ident::new(&source_method_name, variant_name.span());
                    let (source_params, source_assignments) =
                        analyze_fields_for_source_method(fields_named, false);

                    let source_method = quote! {
                        #[track_caller]
                        pub fn #source_method_ident(#(#source_params),*) -> Self
                        {
                            #enum_name::#variant_name {
                                #(#source_assignments,)*
                            }
                        }
                    };
                    methods.push(source_method);
                } else {
                    // 分析字段，确定需要的参数
                    let (params, field_assignments) = analyze_fields(fields_named);

                    // 生成基础方法
                    let method = quote! {
                        #[track_caller]
                        pub fn #method_ident(#(#params),*) -> Self {
                            #enum_name::#variant_name {
                                #(#field_assignments,)*
                            }
                        }
                    };

                    methods.push(method);
                }
            }
            _ => continue,
        }
    }

    Ok(quote! {
        impl #enum_name {
            #(#methods)*
        }
    })
}

/// 将 PascalCase 转换为 snake_case
fn convert_to_snake_case(s: &str) -> String {
    let mut result = String::new();
    for (i, ch) in s.chars().enumerate() {
        if ch.is_uppercase() && i > 0 {
            result.push('_');
        }
        result.push(ch.to_lowercase().next().unwrap());
    }
    result
}

/// 分析字段，生成参数和字段赋值
fn analyze_fields(fields: &syn::FieldsNamed) -> (Vec<TokenStream>, Vec<TokenStream>) {
    let mut params = Vec::new();
    let mut assignments = Vec::new();

    for field in &fields.named {
        let field_name = field.ident.as_ref().unwrap();
        let field_type = &field.ty;

        if field_name == "location" {
            assignments.push(quote! { #field_name: snafu::GenerateImplicitData::generate() });
            continue;
        }

        // 普通字段作为参数
        params.push(quote! { #field_name: #field_type });
        assignments.push(quote! { #field_name });
    }

    (params, assignments)
}

/// 分析字段，为带 source 的方法生成参数和字段赋值
fn analyze_fields_for_source_method(
    fields: &syn::FieldsNamed,
    is_base: bool,
) -> (Vec<TokenStream>, Vec<TokenStream>) {
    let mut params = Vec::new();
    let mut assignments = Vec::new();

    for field in &fields.named {
        let field_name = field.ident.as_ref().unwrap();
        let field_type = &field.ty;

        if field_name == "location" {
            assignments.push(quote! { #field_name: snafu::GenerateImplicitData::generate() });
            continue;
        }

        if is_base && should_add_source_false(field) {
            // 复杂 source 字段设为 None，不作为参数
            assignments.push(quote! { #field_name: None });
        } else {
            // 普通字段作为参数
            params.push(quote! { #field_name: #field_type });
            assignments.push(quote! { #field_name });
        }
    }

    (params, assignments)
}

优势总结

1. 减少样板代码：自动生成重复的字段和方法定义
2. 类型安全：在编译时确保正确的类型处理
3. 灵活配置：支持全局和变体级别的配置选项
4. 智能处理：自动识别复杂类型并生成相应的方法
5. 向后兼容：可以与现有的 snafu 代码无缝集成

结论

#[with_err_location] 宏通过自动化错误处理中的重复工作，显著提升了开发效率和代码质量。它不仅减少了样板代码，还通过智能的类型检测和方法生成，提供了更加优雅和类型安全的错误处理解决方案。

无论是简单的错误类型还是复杂的带源错误的场景，这个宏都能提供恰到好处的自动化支持，让开发者能够专注于业务逻辑而不是重复的错误处理代码。