| name | py2rs-review-r3-io-concurrency |
| description | [DRAFT] 第 3 轮审查:消除阻塞 IO 与不必要等待。引入 async、tokio、rayon。允许 IO 层面大改;允许算法逻辑小改以匹配 IO。 |
第 3 轮 · IO 与并发审查(R3)
DRAFT(草稿状态)。是否用 tokio、是否引入 rayon、是否真的需要 async,都可能在实战里被推翻。
脚手架猜想(可能会有)
rs/src/main.rs 的 #[tokio::main] async fn main() 模板
rs/src/ 下一个 http.rs / fs.rs / db.rs 的 async 化示例
Cargo.toml 中 tokio = { version = "*", features = ["full"] } 的初始依赖(实际 feature 会缩)
- 一个基准脚本
scripts/bench_io_async_vs_sync.py —— 跑前后性能对比
reviews/r3-<module>.md 模板 —— 记录并发改造 + 基准数字
实战里也可能完全不需要 async(某些小脚本同步更快)。这里只是一个可能的审查路线。
0. 前置检查(强约束)
**本 skill 必须在 R0 / R1 / R2 均完成之后启动。**必须同时满足:
若任一未满足,本 skill 直接拒绝启动。
1. 本轮要解决的味道
同步 IO ↔ 等待 ↔ 等待 ↔ 等待
Python 版本通常是串行同步的。迁移到 Rust 后,最容易直接获得收益的就是并发与并行能力。
2. 引入的依赖
cargo add tokio --features full
cargo add rayon
cargo add reqwest --features json
3. 审查清单
3.1 识别阻塞点
3.2 async 化
3.3 并发数控制
3.4 日志一致性(R2 的延续)
4. 允许与禁止(本阶段最关键的边界)
- ✅ 允许:IO 路径改造(从同步到异步,或从单线程到并行)
- ✅ 允许:为匹配新 IO 模型做 小幅度 的算法/结构调整(比如把一个遍历的内部类型从
Vec<String> 改到 Stream<Item=String>)
- ❌ 禁止:在没有充分理由的情况下把算法复杂度从 O(n log n) 改成别的(那是 R4)
- ❌ 禁止:引入
Mutex/RwLock 的复杂嵌套(那是 R5 要重新审视的)
5. 必须做的性能对比
本轮结束前至少跑一份基准:
- 改造前:
cargo build --release + 跑一遍 tests/bench/<module>.py,得到基准耗时
- 改造后:再跑一遍,报告相对提升 / 下降
- 若有下降:要么回滚,要么在
reviews/r3-<module>.md 中给出理由(例如“为了稳定性放弃 5% 性能”)
6. 结束时的交付