解读

在国内 Rust 岗位面试中，面试官提出“如何判断破坏性变更”并不是想听你背诵 semver 条文，而是考察三件事：

1. 你是否理解 Rust 的强编译期保证与生态版本约束之间的互动；
2. 你是否能在真实 CI/CD 流程里自动化、可量化地识别破坏；
3. 你是否具备跨团队协作的沟通能力，把技术判断同步给下游用户。
   因此，回答必须围绕“编译器 + 语义 + 工具链 + 流程”四个维度展开，给出可落地的国内工程方案。

知识点

1. Semver 规范：Rust 官方包管理器 Cargo 强制遵循语义化版本，主版本号（MAJOR）变动即视为破坏性变更。
2. Rust 语言级破坏源：
   • 语法：新增关键字（如 2018 edition 的 async）导致旧代码无法编译。
   • 类型系统：移除公开 enum 变体、收窄泛型约束、改动 trait 关联类型。
   • 生命周期：收紧隐式生命周期约束，使借用检查器拒绝曾经通过的代码。
   • 可链接符号：更改 #[no_mangle] 函数签名或 repr(C) 结构体布局，导致下游二进制链接失败。
3. Cargo 与 rustc 的 lints：
   • cargo check 与 cargo build 在编译期即可捕获 90% 的破坏；
   • cargo semver（官方 rfc 工具）可静态 diff 两个版本的公开 API 并标记破坏等级。
4. 国内镜像与合规：
   • 使用清华大学 tuna 镜像加速依赖拉取；
   • 若涉及等保/国密场景，需额外检查 repr(C) 结构体对齐是否影响硬件加密驱动。
5. 自动化流程：
   • 在 GitHub Actions 或阿里云效 flow 中运行 cargo semver --exhaustive；
   • 将结果上传至企业内网 S3 对象存储，供 QA 二次审计。

答案

我采用“三阶过滤模型”来判断破坏性变更，确保零误报、零漏报：

1. 编译器过滤（零成本）
   在 CI 里先跑 cargo +stable check --all-features，再跑 cargo +nightly check --all-features。若旧代码在新版本下编译失败，即可100% 认定存在破坏性变更，无需进一步讨论。

2. 语义过滤（工具辅助）
   若编译通过，再执行 cargo install cargo-semver && cargo semver --json。该工具会对比公开 API 的抽象语法树，输出四类标记：Major、Minor、Patch、Unknown。只要出现 Major 标记，即判定为破坏性变更。
   针对国内网络，我提前在企业私有 registry 缓存索引，避免 crates.io 超时。

3. 业务过滤（人工兜底）
   对于 #[doc(hidden)] 或 unsafe 边界，工具可能误报。此时我会组织30 分钟快速评审：

   • 让 API 作者给出迁移示例；
   • 让测试同学跑一遍下游核心场景集成测试；
   • 若评审通过，允许提升主版本号并写清升级指南；否则回滚。

通过这三阶过滤，我能在10 分钟 CI 流水线内完成破坏性变更的精准判断，并生成中文报告同步到飞书群，确保产品、测试、合规三方无异议后再发布。

拓展思考

1. Edition 升级的特殊性：Rust 2015→2018→2021 并非自动破坏，需显式 edition = "2021"。此时应开启 cargo fix --edition-idioms 自动迁移，并在企业内网 Wiki 维护“Edition 升级踩坑清单”，降低团队心理负担。
2. ABI 稳定性与 FFI：若库被 C++/Go 通过 cdylib 调用，破坏判断不能只看 Rust 语义，还需检查符号可见性与repr(C) 内存布局。可引入 cbindgen 生成头文件并做 diff，若头文件出现不兼容变更，同样视为破坏。
3. 灰度与特性门控：对于超大用户量基础库（如国内某头部云厂商的 Rust SDK），可采用 #[cfg(feature = "unstable")] 先发布灰度 API，收集真实编译遥测数据后再稳定，从而把“破坏性”转化为“可回退”的渐进式迭代。