为什么执行cargo check后立即运行cargo build会重编译部分依赖？

核心触发原因 #

• 编译产物类型不匹配
  cargo check的核心作用是做语法、类型校验，仅会生成依赖的元数据文件（.rmeta），不会生成可用于链接的完整库文件。你当前项目配置的crate-type包含cdylib，编译cdylib要求依赖开启位置无关代码（PIC）等额外编译选项，cargo check阶段不会触发该类编译配置，到build阶段需要生成可链接的动态库时，就需要重新编译所有参与动态链接的依赖，这也是仅部分依赖重编的核心原因。
• 命令参数/Profile不一致
  如果你两次执行命令时使用了不同的profile（比如一次默认dev、一次加了--release），或者指定了不同的target（比如check用默认主机架构，build指定wasm32-unknown-unknown，这是NEAR合约项目的常见操作），编译配置的差异会直接导致缓存失效，触发依赖重编。你当前Cargo.toml中对release profile做了大量自定义修改（opt-level设为z、开启LTO、调整codegen-units等），和默认dev profile差异极大，如果跨profile执行命令必然出现重编。
• 文件系统时间戳异常
  如果项目的target目录存放在云同步盘、共享目录下，或者有其他进程修改了target目录内文件的修改时间，会导致Cargo判定缓存失效，触发不必要的重编。

解决方法 #

• 保持两次执行命令的参数完全一致：如果是编译NEAR合约，统一添加target和release参数，比如先执行cargo check --target wasm32-unknown-unknown --release，后续执行cargo build --target wasm32-unknown-unknown --release即可复用缓存。
• 不要将target目录放在自动同步的云盘目录下，避免时间戳被意外修改。
• 如果不需要频繁执行check，可以直接用cargo build的增量缓存，后续执行check也可以复用build生成的缓存。

内容的提问来源于stack exchange，提问作者DeLorean88