Cargo 的 rust-version 字段MSRV 声明、解析器联动与支持策略完全指南【免费下载链接】cargoThe Rust package manager项目地址: https://gitcode.com/gh_mirrors/car/cargo导读本文围绕 Cargo 官方文档中rust-versionMinimum Supported Rust Version最低支持的 Rust 版本机制展开系统讲解该字段的声明语法、编译期诊断、cargo add版本选择、依赖解析器resolver联动以及维护者在制定 MSRV 支持策略时的权衡模型。读完本文你将掌握如何正确声明与更新rust-version、如何在 CI 中验证它、如何利用resolver.incompatible-rust-versions与--ignore-rust-version精细控制构建行为并理解 Cargo 内部如 package.rs 与 add.rs是如何落地这一机制的。rust-version字段声明与书写规则rust-version是[package]节中的可选键用于告知 Cargo 你的包所支持的 Rust 工具链版本对应文档见 Therust-versionfield。最基础的写法如下[package] # ... rust-version 1.56书写该字段时有两条硬性语法约束必须是至少含一个版本分量的裸版本号bare version number不能包含 semver 运算符如^1.56、1.56或预发布标识符如1.56.0-alpha.1。此外编译器预发布标识符例如-nightly在检查 Rust 版本时会被忽略。也就是说rust-version表达的是「我承诺支持的最低稳定语义版本」而不是一个范围或一个时间点快照。MSRV该字段自 Rust 1.56 起被 Cargo 尊重Respected as of 1.56。从源码结构看Cargo 将解析结果以可选类型存储在 src/workspace/package.rs 中可以看到rust_version: OptionRustVersion字段与对应的访问器pub fn rust_version(self) - OptionRustVersion并在生成 Summary 时随包元数据一起携带这为后续的诊断、解析器与发布流程提供了统一的数据入口。rust-version的两大用途诊断Diagnostics把「不支持」变成明确错误当你的包在不支持的工具链上被编译时Cargo 会直接以错误的形式报告这一点。这带来的价值是支持预期变得清晰用户不会面对诸如「非法语法」或「标准库缺少某功能」这类含混不清的间接诊断。该检查影响包内所有 Cargo targets包括二进制、示例、测试套件、基准测试benchmark等而不只是库目标。如果用户明知版本不匹配仍想尝试构建可以通过--ignore-rust-version选项显式选择加入opt-in一次不受支持的构建。该选项在 Cargo 的命令层是统一注册的——从 src/bin/cargo/commands/add.rs 等命令文件可以看到.arg_ignore_rust_version()的用法它让build、check、test、add、update等命令共享同一套「忽略 MSRV」语义。[!NOTE] 无论声明在哪个场景rust-version都可以通过--ignore-rust-version选项被临时忽略。开发辅助Development aid版本选择更智能cargo add自动对齐依赖版本cargo add在添加依赖时会自动选择「与你的rust-version兼容的最新版本」作为版本要求。如果最终选中的不是最新版本cargo add会向用户提示让用户自行决定是保持该版本还是更新自己的rust-version。这一行为在源码中体现为honor_rust_version逻辑见 add.rs即是否尊重rust-version由命令行参数与配置共同决定。resolver 联动解析依赖时resolver 可能把 Rust 版本纳入考量详见下文「解析器联动」小节。其他工具也能利用它例如cargo clippy的incompatible_msrvlint 会结合rust-version报告「当前代码用到了高于声明 MSRV 的 API」之类的问题帮助开发者在开发期就守住支持底线。支持预期Support Expectations以下是一般性预期部分包会在自己的文档中说明其未遵循这些预期的情况完整Complete在每一个受支持的 Rust 版本上、在每一个 feature 组合下包的全部功能包括二进制与 API都可用。已验证Verified包的功能在受支持的 Rust 版本上经过验证包括自动化测试。可参考仓库中的 Rust 版本 CI 指南 落地验证流程下文有示例。可修补Patchable在许可证允许的前提下用户可以通过 override 本地依赖 使用你包的一个 fork。此时 Cargo 可能为被 patch 的依赖加载整个 workspace这个 workspace 应当在受支持的 Rust 版本上正常工作——即使 workspace 中其他包支持的 Rust 版本不同。依赖支持Dependency Support为支撑上述各点期望每个依赖的版本要求version-requirement至少匹配一个与你的rust-version兼容的版本。但不要求依赖规格把与你的rust-version不兼容的版本排除在外——保留两者的空间恰好能让你在「需要支持旧 Rust 的用户」与「不需要的用户」之间取得平衡。设置与更新rust-version支持哪些版本取舍三角选择支持的 Rust 版本本质是在三方面成本之间做权衡维护者成本无法使用较新的 Rust 工具链或较新依赖的特性用户收益如果包能用上新工具链特性例如把标准库特性从 polyfill 迁移过去、减少构建时间用户会受益可用性对支持旧 Rust 版本的用户而言包是否仍然可用。[!NOTE] 按 SemVer 惯例修改rust-version被视作一次次要版本不兼容变更minor incompatibility需要遵守相应的版本号提升规则。[!TIP] 建议为「支持哪些 Rust 版本、何时变更」预先定好策略用户才能把自己的策略与你的对照若两者不兼容他们才能判断「放弃一般性改进」与「承担一个不会被修复的阻塞 bug 的风险」哪个更可接受。最简单的策略是始终使用最新 Rust 版本根据风险偏好次简单的做法是继续维护支持旧 Rust 版本的旧 major/minor 版本线。如何选择受支持的 Rust 版本用户通常按以下方式确定自己跟踪的 Rust 版本工具链厂商的支持政策例如 Rust 官方项目或某个 Linux 发行版。注意Rust 官方项目只对最新版本提供 bug 修复与安全更新固定节奏的重新验证计划例如每年第一个版本、每 5 个版本做一次全量复查。同时要意识到用户不会立刻切换到新版 Rust他们需要时间注意到更新并重新验证且彼此不一定遵循同一套节奏。常见的版本策略示例N-2跟踪最新版本但给出 2 个版本的升级宽限窗口每个偶数版本甚至每偶数个版本并给予 2 个版本的升级宽限窗口本日历年度内的每个版本并给予一年升级宽限窗口。[!NOTE] 若要找出「与当前项目现状兼容的最低rust-version」可以使用第三方工具例如cargo-msrv。更新时间线Update timeline当你的策略表明不再需要支持某个 Rust 版本时你可以立即更新rust-version或等到必要时再更新。让rust-version与策略产生漂移drift的利弊利给用户更长的升级宽限窗口弊对「用户跟踪的 Rust 版本」而言太不可预测无法作为对齐依据漂移越久用户越可能推断出一个你并未打算执行的策略进而因预期落空而产生挫败感允许漂移后「什么程度才算足够合理的理由去放弃支持某个版本」会成为一个开放问题讨论过程对相关方都颇为消耗尤其会削弱那些不愿卷入冲突的新人或偶发贡献者——他们可能觉得没资格提出这个问题或担心冲突会危及自己的变更被合并。工作区中的多策略Multiple Policies in a WorkspaceCargo允许在同一个 workspace 内支持多种策略即不同成员包声明不同的rust-version但要注意在不同 Rust 版本下分别验证特定包会变得复杂第三方工具如cargo-hack可以帮忙典型用法见 continuous-integration.md 中的 CI 示例对跨策略共享的依赖必须使用最低公共版本因为 Cargo 会统一 SemVer 兼容版本这可能限制高rust-versionworkspace 成员使用共享依赖的某些特性若要允许用户对 workspace 中某个成员 patch 依赖则 workspace 中每个包都必须能在该 workspace 支持的最老 Rust 版本下被加载当使用resolver.incompatible-rust-versions fallback时一个包的 Rust 版本可能影响为另一个不同 Rust 版本的包选定的依赖版本详见 resolver 章节。一条策略还是多条One or More Policies缓解「支持旧 Rust 版本」负面影响的一种方式是把策略施加到你继续维护的旧 major/minor 版本线上即开发分支与各发布分支分别设定支持的 Rust 版本。只在「必要时」更新开发分支的rust-version有助于减少需要维护的发布分支数量但「什么可以回移植backport到发布分支」是个问题在 minor 版本之间回移植新功能会让下一个可用版本缺少该功能可能被视作破坏性变更从而违反 SemVer回移植本身也有引入 bug 的风险支持旧版本是有成本的成本取决于包内 bug 的风险与影响以及回移植的可接受度。按需创建发布分支、把回移植负担交给社区是平衡这种成本的方式目前依赖管理工具还无法报告「非最新版本仍受支持」用户只能通过文档自行获知这需要包作者在文档中明确说明。一个可参考的完整 Rust 版本支持策略示例开发分支跟踪 Rust 官方的最新稳定版必要时更新变更rust-version时提升 minor 版本号项目支持本日历年度内的每个版本另加一年宽限窗口支持某个受支持 Rust 版本的最后一个 minor 版本将接收社区提供的 bug 修复修复必须回移植到「开发分支与所需受支持 Rust 版本之间」的所有受支持 minor 版本。解析器联动resolver.incompatible-rust-versions为支持「最低支持 Rust 版本」的开发方式resolver 会把依赖版本的 Rust 版本兼容性纳入考量由配置字段resolver.incompatible-rust-versions控制可取值allow把rust-version不兼容的版本当作普通版本一样对待fallback只有当没有其他版本匹配时才考虑rust-version不兼容的版本。以「使用 Rust 1.85 开发、声明rust-version 1.62的包」为例[package] name my-cli rust-version 1.62 [dependencies] clap 4.0 # resolves to 4.0.32在fallback设置下resolver 会优先选择rust-version小于等于你自身 Rust 版本的依赖版本因此选择4.0.32其 Rust 版本为 1.60.0不选4.0.0虽然它也兼容 1.60.0但版本号更低不选4.5.20尽管版本号高得多、且其 1.74.0 与你的 1.85 工具链兼容但它与my-cli声明的 1.62 不兼容。如果某个版本要求根本不含任何与你的rust-version兼容的版本resolver 不会报错而是仍然挑选一个版本即使它可能是次优的。例如[package] name my-cli rust-version 1.62 [dependencies] clap 4.2 # resolves to 4.5.20由于没有匹配 1.62 的clap4.2.x 版本resolver 会退而选择不兼容的4.5.20其 Rust 版本为 1.74。还有一个重要限制resolver 在为某个包挑选依赖版本时并不知道最终会有哪些 workspace 成员传递依赖到该版本因此无法只针对与该项相关的 Rust 版本做精细考量当 workspace 成员rust-version各不相同时resolver 会用启发式方法寻找「足够好」的解即使没有声明rust-version的包也受此影响。这可能导致两种次优结果选得过低成员arust-version 1.62与无 Rust 版本的成员b同时依赖clap 4.2本可使用 4.5.20 的b会因a的 1.62 而整体落到 4.0.32选得过高当a声明clap 4.2、b声明clap 4.5时由于版本统一规则resolver 必须为双方挑选一个共同版本最终可能得到 4.5.20 这样超过a的 MSRV 的版本。resolver.incompatible-rust-versions的默认值随 edition 变化edition 2024要求 Rust 1.84下默认从allow改为fallback见 resolver.md。它还可以通过以下方式被覆盖--ignore-rust-versionCLI 选项把依赖的版本要求设置得高于任何兼容rust-version的版本用cargo update --precise指定精确版本。在 CI 中验证rust-version发布声明了rust-version的包时务必验证该字段的正确性见 Verifyingrust-version。仓库文档推荐第三方工具cargo-msrv与cargo-hack并给出一个 GitHub Actions 示例jobs: msrv: runs-on: ubuntu-latest steps: - uses: actions/checkoutv6 - uses: taiki-e/install-actioncargo-hack - run: cargo hack check --rust-version --workspace --all-targets --ignore-private这一方案在「全面性」与「周转时间」之间做了平衡单平台即可多数项目与平台无关平台相关依赖的验证交给各依赖自身使用cargo check即可贡献者遇到的大多是 API 可用性问题而非行为差异跳过未发布的包假设只有通过 registry 消费该项目的下游才关心rust-version。此外CI 中设置环境变量CARGO_RESOLVER_INCOMPATIBLE_RUST_VERSIONS可以确保 resolver 不会因为项目自身的 Rust 版本而限制所选依赖对应配置见 config.md。小结rust-version是 Cargo 将「最低支持 Rust 版本」从口头承诺升级为工程机制的核心字段它驱动编译期诊断、cargo add的版本选择、resolver 的依赖挑选以及第三方 lint 工具。合理声明它、用 CI 验证它、并用resolver.incompatible-rust-versions与--ignore-rust-version精确控制边界行为是发布高质量 Rust 库的必备技能。相关的源码实现入口可继续阅读 src/workspace/package.rsrust_version的解析与存储、src/workspace/manifest.rsmanifest 解析以及 src/resolver/version_prefs.rs解析器版本偏好官方完整论述见 rust-version.md。【免费下载链接】cargoThe Rust package manager项目地址: https://gitcode.com/gh_mirrors/car/cargo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cargo 的 rust-version 字段：MSRV 声明、解析器联动与支持策略完全指南
Cargo 的 rust-version 字段MSRV 声明、解析器联动与支持策略完全指南【免费下载链接】cargoThe Rust package manager项目地址: https://gitcode.com/gh_mirrors/car/cargo导读本文围绕 Cargo 官方文档中rust-versionMinimum Supported Rust Version最低支持的 Rust 版本机制展开系统讲解该字段的声明语法、编译期诊断、cargo add版本选择、依赖解析器resolver联动以及维护者在制定 MSRV 支持策略时的权衡模型。读完本文你将掌握如何正确声明与更新rust-version、如何在 CI 中验证它、如何利用resolver.incompatible-rust-versions与--ignore-rust-version精细控制构建行为并理解 Cargo 内部如 package.rs 与 add.rs是如何落地这一机制的。rust-version字段声明与书写规则rust-version是[package]节中的可选键用于告知 Cargo 你的包所支持的 Rust 工具链版本对应文档见 Therust-versionfield。最基础的写法如下[package] # ... rust-version 1.56书写该字段时有两条硬性语法约束必须是至少含一个版本分量的裸版本号bare version number不能包含 semver 运算符如^1.56、1.56或预发布标识符如1.56.0-alpha.1。此外编译器预发布标识符例如-nightly在检查 Rust 版本时会被忽略。也就是说rust-version表达的是「我承诺支持的最低稳定语义版本」而不是一个范围或一个时间点快照。MSRV该字段自 Rust 1.56 起被 Cargo 尊重Respected as of 1.56。从源码结构看Cargo 将解析结果以可选类型存储在 src/workspace/package.rs 中可以看到rust_version: OptionRustVersion字段与对应的访问器pub fn rust_version(self) - OptionRustVersion并在生成 Summary 时随包元数据一起携带这为后续的诊断、解析器与发布流程提供了统一的数据入口。rust-version的两大用途诊断Diagnostics把「不支持」变成明确错误当你的包在不支持的工具链上被编译时Cargo 会直接以错误的形式报告这一点。这带来的价值是支持预期变得清晰用户不会面对诸如「非法语法」或「标准库缺少某功能」这类含混不清的间接诊断。该检查影响包内所有 Cargo targets包括二进制、示例、测试套件、基准测试benchmark等而不只是库目标。如果用户明知版本不匹配仍想尝试构建可以通过--ignore-rust-version选项显式选择加入opt-in一次不受支持的构建。该选项在 Cargo 的命令层是统一注册的——从 src/bin/cargo/commands/add.rs 等命令文件可以看到.arg_ignore_rust_version()的用法它让build、check、test、add、update等命令共享同一套「忽略 MSRV」语义。[!NOTE] 无论声明在哪个场景rust-version都可以通过--ignore-rust-version选项被临时忽略。开发辅助Development aid版本选择更智能cargo add自动对齐依赖版本cargo add在添加依赖时会自动选择「与你的rust-version兼容的最新版本」作为版本要求。如果最终选中的不是最新版本cargo add会向用户提示让用户自行决定是保持该版本还是更新自己的rust-version。这一行为在源码中体现为honor_rust_version逻辑见 add.rs即是否尊重rust-version由命令行参数与配置共同决定。resolver 联动解析依赖时resolver 可能把 Rust 版本纳入考量详见下文「解析器联动」小节。其他工具也能利用它例如cargo clippy的incompatible_msrvlint 会结合rust-version报告「当前代码用到了高于声明 MSRV 的 API」之类的问题帮助开发者在开发期就守住支持底线。支持预期Support Expectations以下是一般性预期部分包会在自己的文档中说明其未遵循这些预期的情况完整Complete在每一个受支持的 Rust 版本上、在每一个 feature 组合下包的全部功能包括二进制与 API都可用。已验证Verified包的功能在受支持的 Rust 版本上经过验证包括自动化测试。可参考仓库中的 Rust 版本 CI 指南 落地验证流程下文有示例。可修补Patchable在许可证允许的前提下用户可以通过 override 本地依赖 使用你包的一个 fork。此时 Cargo 可能为被 patch 的依赖加载整个 workspace这个 workspace 应当在受支持的 Rust 版本上正常工作——即使 workspace 中其他包支持的 Rust 版本不同。依赖支持Dependency Support为支撑上述各点期望每个依赖的版本要求version-requirement至少匹配一个与你的rust-version兼容的版本。但不要求依赖规格把与你的rust-version不兼容的版本排除在外——保留两者的空间恰好能让你在「需要支持旧 Rust 的用户」与「不需要的用户」之间取得平衡。设置与更新rust-version支持哪些版本取舍三角选择支持的 Rust 版本本质是在三方面成本之间做权衡维护者成本无法使用较新的 Rust 工具链或较新依赖的特性用户收益如果包能用上新工具链特性例如把标准库特性从 polyfill 迁移过去、减少构建时间用户会受益可用性对支持旧 Rust 版本的用户而言包是否仍然可用。[!NOTE] 按 SemVer 惯例修改rust-version被视作一次次要版本不兼容变更minor incompatibility需要遵守相应的版本号提升规则。[!TIP] 建议为「支持哪些 Rust 版本、何时变更」预先定好策略用户才能把自己的策略与你的对照若两者不兼容他们才能判断「放弃一般性改进」与「承担一个不会被修复的阻塞 bug 的风险」哪个更可接受。最简单的策略是始终使用最新 Rust 版本根据风险偏好次简单的做法是继续维护支持旧 Rust 版本的旧 major/minor 版本线。如何选择受支持的 Rust 版本用户通常按以下方式确定自己跟踪的 Rust 版本工具链厂商的支持政策例如 Rust 官方项目或某个 Linux 发行版。注意Rust 官方项目只对最新版本提供 bug 修复与安全更新固定节奏的重新验证计划例如每年第一个版本、每 5 个版本做一次全量复查。同时要意识到用户不会立刻切换到新版 Rust他们需要时间注意到更新并重新验证且彼此不一定遵循同一套节奏。常见的版本策略示例N-2跟踪最新版本但给出 2 个版本的升级宽限窗口每个偶数版本甚至每偶数个版本并给予 2 个版本的升级宽限窗口本日历年度内的每个版本并给予一年升级宽限窗口。[!NOTE] 若要找出「与当前项目现状兼容的最低rust-version」可以使用第三方工具例如cargo-msrv。更新时间线Update timeline当你的策略表明不再需要支持某个 Rust 版本时你可以立即更新rust-version或等到必要时再更新。让rust-version与策略产生漂移drift的利弊利给用户更长的升级宽限窗口弊对「用户跟踪的 Rust 版本」而言太不可预测无法作为对齐依据漂移越久用户越可能推断出一个你并未打算执行的策略进而因预期落空而产生挫败感允许漂移后「什么程度才算足够合理的理由去放弃支持某个版本」会成为一个开放问题讨论过程对相关方都颇为消耗尤其会削弱那些不愿卷入冲突的新人或偶发贡献者——他们可能觉得没资格提出这个问题或担心冲突会危及自己的变更被合并。工作区中的多策略Multiple Policies in a WorkspaceCargo允许在同一个 workspace 内支持多种策略即不同成员包声明不同的rust-version但要注意在不同 Rust 版本下分别验证特定包会变得复杂第三方工具如cargo-hack可以帮忙典型用法见 continuous-integration.md 中的 CI 示例对跨策略共享的依赖必须使用最低公共版本因为 Cargo 会统一 SemVer 兼容版本这可能限制高rust-versionworkspace 成员使用共享依赖的某些特性若要允许用户对 workspace 中某个成员 patch 依赖则 workspace 中每个包都必须能在该 workspace 支持的最老 Rust 版本下被加载当使用resolver.incompatible-rust-versions fallback时一个包的 Rust 版本可能影响为另一个不同 Rust 版本的包选定的依赖版本详见 resolver 章节。一条策略还是多条One or More Policies缓解「支持旧 Rust 版本」负面影响的一种方式是把策略施加到你继续维护的旧 major/minor 版本线上即开发分支与各发布分支分别设定支持的 Rust 版本。只在「必要时」更新开发分支的rust-version有助于减少需要维护的发布分支数量但「什么可以回移植backport到发布分支」是个问题在 minor 版本之间回移植新功能会让下一个可用版本缺少该功能可能被视作破坏性变更从而违反 SemVer回移植本身也有引入 bug 的风险支持旧版本是有成本的成本取决于包内 bug 的风险与影响以及回移植的可接受度。按需创建发布分支、把回移植负担交给社区是平衡这种成本的方式目前依赖管理工具还无法报告「非最新版本仍受支持」用户只能通过文档自行获知这需要包作者在文档中明确说明。一个可参考的完整 Rust 版本支持策略示例开发分支跟踪 Rust 官方的最新稳定版必要时更新变更rust-version时提升 minor 版本号项目支持本日历年度内的每个版本另加一年宽限窗口支持某个受支持 Rust 版本的最后一个 minor 版本将接收社区提供的 bug 修复修复必须回移植到「开发分支与所需受支持 Rust 版本之间」的所有受支持 minor 版本。解析器联动resolver.incompatible-rust-versions为支持「最低支持 Rust 版本」的开发方式resolver 会把依赖版本的 Rust 版本兼容性纳入考量由配置字段resolver.incompatible-rust-versions控制可取值allow把rust-version不兼容的版本当作普通版本一样对待fallback只有当没有其他版本匹配时才考虑rust-version不兼容的版本。以「使用 Rust 1.85 开发、声明rust-version 1.62的包」为例[package] name my-cli rust-version 1.62 [dependencies] clap 4.0 # resolves to 4.0.32在fallback设置下resolver 会优先选择rust-version小于等于你自身 Rust 版本的依赖版本因此选择4.0.32其 Rust 版本为 1.60.0不选4.0.0虽然它也兼容 1.60.0但版本号更低不选4.5.20尽管版本号高得多、且其 1.74.0 与你的 1.85 工具链兼容但它与my-cli声明的 1.62 不兼容。如果某个版本要求根本不含任何与你的rust-version兼容的版本resolver 不会报错而是仍然挑选一个版本即使它可能是次优的。例如[package] name my-cli rust-version 1.62 [dependencies] clap 4.2 # resolves to 4.5.20由于没有匹配 1.62 的clap4.2.x 版本resolver 会退而选择不兼容的4.5.20其 Rust 版本为 1.74。还有一个重要限制resolver 在为某个包挑选依赖版本时并不知道最终会有哪些 workspace 成员传递依赖到该版本因此无法只针对与该项相关的 Rust 版本做精细考量当 workspace 成员rust-version各不相同时resolver 会用启发式方法寻找「足够好」的解即使没有声明rust-version的包也受此影响。这可能导致两种次优结果选得过低成员arust-version 1.62与无 Rust 版本的成员b同时依赖clap 4.2本可使用 4.5.20 的b会因a的 1.62 而整体落到 4.0.32选得过高当a声明clap 4.2、b声明clap 4.5时由于版本统一规则resolver 必须为双方挑选一个共同版本最终可能得到 4.5.20 这样超过a的 MSRV 的版本。resolver.incompatible-rust-versions的默认值随 edition 变化edition 2024要求 Rust 1.84下默认从allow改为fallback见 resolver.md。它还可以通过以下方式被覆盖--ignore-rust-versionCLI 选项把依赖的版本要求设置得高于任何兼容rust-version的版本用cargo update --precise指定精确版本。在 CI 中验证rust-version发布声明了rust-version的包时务必验证该字段的正确性见 Verifyingrust-version。仓库文档推荐第三方工具cargo-msrv与cargo-hack并给出一个 GitHub Actions 示例jobs: msrv: runs-on: ubuntu-latest steps: - uses: actions/checkoutv6 - uses: taiki-e/install-actioncargo-hack - run: cargo hack check --rust-version --workspace --all-targets --ignore-private这一方案在「全面性」与「周转时间」之间做了平衡单平台即可多数项目与平台无关平台相关依赖的验证交给各依赖自身使用cargo check即可贡献者遇到的大多是 API 可用性问题而非行为差异跳过未发布的包假设只有通过 registry 消费该项目的下游才关心rust-version。此外CI 中设置环境变量CARGO_RESOLVER_INCOMPATIBLE_RUST_VERSIONS可以确保 resolver 不会因为项目自身的 Rust 版本而限制所选依赖对应配置见 config.md。小结rust-version是 Cargo 将「最低支持 Rust 版本」从口头承诺升级为工程机制的核心字段它驱动编译期诊断、cargo add的版本选择、resolver 的依赖挑选以及第三方 lint 工具。合理声明它、用 CI 验证它、并用resolver.incompatible-rust-versions与--ignore-rust-version精确控制边界行为是发布高质量 Rust 库的必备技能。相关的源码实现入口可继续阅读 src/workspace/package.rsrust_version的解析与存储、src/workspace/manifest.rsmanifest 解析以及 src/resolver/version_prefs.rs解析器版本偏好官方完整论述见 rust-version.md。【免费下载链接】cargoThe Rust package manager项目地址: https://gitcode.com/gh_mirrors/car/cargo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考