解读

在国内 Rust 技术面试中，“如何写 RFC” 并不是考察候选人能否立刻提交一份正式 RFC，而是考察三点：是否理解 Rust 语言演化流程、是否具备结构化表达能力、能否把模糊需求拆成可验证的技术方案。面试官常通过追问“如果让你给标准库加一个新 trait，你会怎么写 RFC？”来验证候选人是否熟悉 Rust 社区决策机制，并能在高压下把技术思路讲清楚。回答时务必用中文思维组织技术逻辑，避免直接翻译英文模板，同时体现“先问题、后方案、再影响”的递进结构。

知识点

1. RFC 在 Rust 项目中的定位：位于 rust-lang/rfcs 仓库，是语言、标准库、Cargo、编译器四条轨道变更的唯一入口。
2. 生命周期：Issue → Pre-RFC 讨论 → PR 提交 → 指定 Shepherd → FCP → 合并 → Tracking Issue → 稳定化。
3. 模板字段：摘要、动机、设计讲解、详细设计、缺点、替代方案、未解决问题、未来可能性、可量化的稳定性门槛。
4. 国内候选人易踩坑：
   • 只写“我想加语法糖”，却给不出迁移存量代码的自动化工具；
   • 忽略版本控制策略，未说明是否允许 #[cfg(edition_202x)] 隔离；
   • 未评估对 miri、clippy、rust-analyzer 的连锁改动成本。
5. 面试加分项：提前准备两张图（口头描述即可）：一张状态机图说明新语法与旧版解析器的冲突点，一张基准测试柱状图证明零成本抽象承诺。

答案

我给面试官一个可落地的六段式回答，每段都对应 RFC 模板的一个核心章节，同时用中文场景举例：

1. 问题定义
   “在国产信创操作系统里，内核模块需要静态禁用 alloc 但又要支持异步 IO。当前 futures 库强制依赖 alloc，导致内核态无法直接使用。”

2. 动机与业务价值
   “如果内核态也能用 async，龙蜥、OpenEuler 社区就能用同一套 Rust 驱动代码跑在用户态和内核态，预计减少 30% 维护成本。”

3. 设计讲解（高层思路）
   “新增 core::future::Ready<T> 的无 alloc 实现，并引入 #[no_alloc_async] 属性宏，在编译期把 Waker vtable 放到静态段，从而零开销。”

4. 详细设计（关键数据结构）
   “扩展 core::task::Context，加 const fn new_static(waker: &'static Waker) -> Self；同时修改编译器内置 lowering 规则，当检测到 no_alloc_async 函数时，禁止生成动态 Waker。”

5. 缺点与替代方案
   “缺点：需要稳定 const Waker 构造，可能阻塞 1.80 版本发布周期；替代方案：继续用 unsafe{ mem::transmute }，但无法在 MIRI 下通过，失去 Rust 安全卖点。”

6. 稳定化门槛
   “在 next 内核分支跑通 100% RedSleeve 驱动用例，零内存泄漏、零数据竞争，并通过 rustc 测试套件 make check-core 方可进入 FCP。”

说完六段后，主动补充：“如果社区接受，我可以在两周内提交 Pre-RFC PR，并用 GitHub Projects 拆解 23 个子任务，每周同步进度。” 这样既展示结构化思维，又给出可验证的交付节奏，面试官通常到此就打满分。

拓展思考

1. 如果面试官把场景换成**“给 Cargo 加国内镜像智能切换”，如何复用同一套六段式？
   核心是把“设计讲解”换成“基于 TTL 的镜像健康度评分算法”，并给出回退策略**：当 crates-io-index 延迟 >500ms 时自动降级到 tuna/ustc，无需用户改 ~/.cargo/config。
2. 若面试官追问“你的 RFC 被 Shepherd 打回怎么办？”
   标准答案是：“先写 Reference Implementation 锁定技术细节，再用中文博客写科普文章，吸引国内大厂（阿里、字节、华为）工程师背书，重新打开讨论”。这体现社区运营思维，是国内 Rust 职位晋升 Tech Lead 的隐藏考点。