Rust 1.100.0真正值得关注的，不是又增加了多少个语言特性，而是它开始把“安全”从编译器能力，推进成整个软件供应链的治理能力。
2026年11月12日，Rust 1.100.0发布。官方更新横跨语言、编译器、平台支持、标准库、Cargo与Rustdoc，看上去像一次常规版本迭代，实际集中处理了三个长期问题，实验性语义如何兑现为稳定承诺，编译器如何把潜在错误更早暴露出来，依赖管理如何从“能构建”进一步走向“可控制”。
其中最醒目的变化，是never type，也就是永不返回的类型“!”终于稳定。这个特性并非新语法突然出现，而是Rust类型系统长期设计的一次收尾。与此同时，Rust 1.100.0稳定了自定义分配器核心API，引入Cargo自身的lint系统，并加入依赖最低发布年龄配置。语言和工具链在同一个版本里同时变得更严格，也更可配置。
最老的实验特性，终于成为稳定语义
“!”代表一个不会正常返回的计算。程序触发panic后不会继续执行，进入无限循环的函数不会返回，调用process::exit后控制流也不会回到调用点。过去Rust已经能够在不少场景推断出这种类型，但它长期处于不稳定状态，开发者无法把它当作普通类型在所有场景中稳定使用。
Rust官方博客称，这次稳定化经历了10年和5次失败尝试。困难不在于为符号“!”补上一个语法入口，而在于它会触及类型推断、trait实现、泛型参数和旧版本代码之间的边界。Rust 1.100.0还把Infallible改为“!”的类型别名，并将所有edition的never type fallback从()改为“!”。这意味着少数依赖隐式回退的旧代码，可能得到不同的类型推断结果。
对新项目而言，开发者可以更直接地表达“不可能成功返回”的接口。对维护旧项目的人而言，稳定语义意味着编译器可以用更一致的规则检查整个生态。收益不会表现为一张新的性能曲线，而会表现为更少的占位错误类型、更清楚的控制流，以及更可靠的泛型抽象。
Rust 1.100.0还稳定了extern "custom"。这项变化为特殊调用约定和外部接口场景提供了稳定的表达方式。对于系统软件、嵌入式平台和需要连接非标准ABI的工程，开发者可以据此重新评估原本依赖实验特性或其他绕行方案的接口设计。它不等于自动消除ABI风险，但减少了稳定工具链在表达这类需求时的限制。
Lint正在成为Rust的第二层类型系统
如果说never type是在修补语言语义的地基，那么Rust 1.100.0中的lint变化，则是在扩大编译器的可解释性。重复的#[repr(...)]属性现在会触发检查；对drop_in_place的调用，dropping_references、dropping_copy_types和undropped_manually_drops等lint也覆盖得更完整；repr(packed)类型中的repr(align)字段错误，则转为默认拒绝的aligned_fields_in_packed lint。
这些变化共同指向一个事实，Rust不满足于只阻止已经确定的内存错误，也在持续识别那些“代码能编译，但很可能不是作者本意”的写法。重复表示属性可能意味着配置冲突，丢弃引用或Copy类型可能意味着开发者误以为资源已经被释放，而packed与align的组合则涉及布局和对齐风险。把这些问题转化为可控制的lint，能够让项目团队在错误、警告和允许之间做出明确选择。
这也是Rust工程体验正在发生的变化。规则被命名、分级并暴露给项目配置后，编译器不再只是一个固定的判卷器，而更像一套可编排的质量系统。项目可以根据自身约束决定哪些问题必须阻断构建，哪些问题只需要提醒，哪些历史代码可以暂时保留。
unfulfilled_lint_expectations对dead_code场景的调整，体现了诊断边界的精细化。一个父级代码已经覆盖诊断时，子级的#[expect(dead_code)]不再被错误地视为未满足。对大型项目来说，静态检查的价值不仅是发现问题，也在于避免噪声。误报过多，团队会关闭规则；边界更准确，lint才更可能进入日常生产流程。
Cargo开始治理依赖，而不只是解析依赖
Rust 1.100.0最具工程意味的变化，可能发生在Cargo而不是rustc。新版本引入Cargo自身的lint系统，部分Cargo警告可以在[lints.cargo]表中统一控制。其中包括cargo::unused_dependencies，用来发现没有被任何Cargo target使用的依赖。
未使用依赖不只是整洁问题。Cargo官方文档指出，这类依赖会拖慢编译时间。它还会扩大项目的依赖图和维护面，让团队更难判断一个包究竟为何存在。Cargo现在可以对依赖声明本身发出结构化诊断，意味着“依赖是否存在”与“依赖是否有必要存在”开始被分开处理。
更值得注意的是minimum publish age，也就是依赖冷却期配置。开启后，依赖解析器会忽略发布不久的新版本，除非该版本已经存在于Cargo.lock中。它不能替代安全审计，也不能保证某个包绝对安全，但可以为新版本进入构建流程增加一个时间门槛，让维护者不必在发布瞬间自动跟进。
这项能力改变了依赖管理的默认取向。最新版本与适合立即进入生产，并不是同一个概念。对于个人项目，冷却期可能只是可选配置；对于基础设施和安全敏感系统，它则可以成为升级流程中的一道风险闸门。代价也很明确，项目可能错过紧急修复或重要功能，因此冷却时间需要结合自身更新策略设置。
cargo install在新版本中默认使用.crate压缩包里已有的锁文件，--locked在这一场景下变成无操作。官方变更的重点，是让安装过程沿用发布包提供的锁定信息，而不是在安装阶段重新依赖默认解析行为。它减少了安装流程中的一个不确定来源，但不应被理解成对所有构建环境的绝对可复现保证。
自定义分配器与构建目录，重新划定工具链边界
标准库方面，Rust 1.100.0稳定了自定义分配器核心API。通过稳定的Allocator trait，库作者可以让Vec和Box等标准类型使用自定义分配器。分配策略由标准库内部细节变成可组合接口，对确实需要特殊内存区域或分配策略的系统软件、嵌入式程序和高性能服务具有现实价值。
这不意味着所有程序都应该自定义分配器。稳定API的意义在于，有明确需求的团队不必长期停留在nightly工具链，而不需要这项能力的应用仍然可以使用默认分配器。成熟的基础设施不会把复杂性强加给所有用户，而是把复杂能力放到清晰的接口后面。
Rust 1.100.0还改变了Cargo中间构建产物的目录布局。官方提醒，检查构建目录的工具不应依赖旧目录结构，而应使用Cargo的JSON消息定位构建产物。这个提醒的分量不在于目录换了位置，而在于它再次划定了工具链的公共边界，内部布局可以变化，正式输出接口才是工具作者应依赖的对象。
对于IDE、构建缓存、打包系统和持续集成平台，这意味着需要检查是否存在通过猜测目录读取产物的脚本。迁移会带来成本，但通过机器可读消息定位产物，比把内部目录约定当成稳定API更容易长期维护。
Rust 1.100.0的真正信号，是可治理性
把这些改动放在一起看，Rust 1.100.0并不是一次围绕单一卖点的版本发布。never type解决语言表达和类型推断的长期债务，lint变化提高编译期反馈的精度，custom allocator扩展底层工程能力，Cargo lint与minimum publish age则把治理边界推向依赖供应链。
这套组合透露出Rust下一阶段的竞争重点。早期Rust最容易被记住的标签是内存安全，随后是性能和零成本抽象。如今，决定它能否进入更大规模组织的，可能是另一种能力，能否让团队把风险、构建、依赖和升级策略写进工具链，而不是依赖每个工程师的个人经验。
软件工程的风险早已不只来自一行不安全的指针操作，也来自依赖树中一个不必要的包、一次没有冷却期的自动升级、一个依赖内部目录结构的构建脚本。Rust 1.100.0没有宣称一次性解决这些问题，但它把更多控制面板交给了开发者。
当然，控制面板越多，维护者的责任也越大。never type稳定化可能暴露少量旧代码的类型推断差异；Cargo lint需要团队建立适合自身项目的告警策略；minimum publish age会在安全与更新速度之间制造新的权衡；构建目录变化也要求工具作者迁移到正式接口。升级并非按下按钮就结束，而是一次对工程假设的重新检查。
对Rust用户来说，最实际的动作不是追逐所有新特性，而是重新审视三类代码，依赖管理是否有明确的更新和冷却策略，CI是否把Cargo与rustc诊断纳入统一规则，构建工具是否依赖未经承诺的目录结构。Rust 1.100.0的价值，只有在这些配置进入日常流程后才会显现。
Rust 1.100.0把一门语言的长期实验，变成了一套更完整的生产纪律。未来真正稀缺的，不是“能不能写出安全代码”，而是能不能让安全、可复现和可审计，自动成为每次构建的默认结果。
快报