从cargo new跑通第一个 hello world，到能熟练地在项目里加依赖、跑测试，这中间其实隔着一道很有意思的分水岭。很多人对 Cargo 的印象停留在“包管理工具”这六个字上，知道cargo build、cargo run、cargo add这些高频命令，但再往深处走，比如 release profile 怎么调、工作区怎么组织、自己的库怎么发到 crates.io 上，就未必说得清楚了。

我写过一段时间的 Rust 之后有一个很明显的感觉：Cargo 这套工具链的设计，几乎把“构建、测试、发布、依赖管理”这几件事揉成了一个整体，只要你愿意深入一点，它能帮你省掉非常多的工程化琐事。这篇文章我就围绕“进一步认识 Cargo 和 crates.io”这个主题，把我自己在实际项目里用到的进阶操作、踩过的坑和总结下来的经验，系统地梳理一遍。目标读者是对 Rust 已经有了基本了解、想把工程化水平往上提一档的人，读完你至少能自己动手调优构建配置、搭好一个多包工作区，并且把属于自己的 crate 发布到公共仓库。

1. 为什么说 Cargo 不只是“包管理器”

先聊一个认知层面的问题。很多人把 Cargo 类比成其他语言里的包管理器，比如 npm、pip 之类，这个类比有道理，但不够完整。Cargo 同时承担了构建系统、依赖管理器、测试运行器、文档生成器、发布工具这五重角色。换句话说，它把“从代码到可交付产物”这条链路上的大部分环节都覆盖了，这是它区别于很多语言工具链的核心特点。

1.1 Cargo 解决的三个核心矛盾

我在实际项目里体会最深的是它同时处理好了三件事。

第一件事是依赖版本的确定性。Cargo.lock文件把所有直接依赖和间接依赖的精确版本都锁死，保证今天构建和三个月后构建用的是同一套依赖。这一点对应用项目来说价值非常大，因为间接依赖的版本漂移是很多诡异 bug 的根源。第二件事是构建过程的声明式管理。你用Cargo.toml描述项目需要什么、怎么编译、有什么特性，Cargo 负责把它变成一套可复现的构建流程，不需要手写 Makefile 或者 CMakeLists 来维护一堆编译规则。第三件事是发布流程的标准化。cargo publish一条命令就能把库打包上传到 crates.io，并且带有元数据校验、文档构建、版本冲突检查这些保护机制。

1.2 章节背后的进阶主线

“进一步认识”这个定位，意味着你已经越过了“会用”的阶段，开始向“用好”靠拢。对一个用 Cargo 写过几个项目的人来说，下面这几个方向是你迟早要碰到的：构建产物的性能优化（release profile）、多包项目的代码组织（workspace）、把自己写的库分享给别人（publish）、以及把日常开发流程自动化（cargo test / clippy / fmt / doc）。这篇文章的章节顺序也基本按照这条主线展开。

2. 深入 release profile：为构建配置画上准星

如果现在去翻一个老项目的Cargo.toml，我猜大概率看不到任何[profile]段。Cargo 提供了合理的默认配置，这让新手可以完全不用关心编译优化细节。但一旦项目开始走向生产环境，默认配置往往就不够用了。

2.1 release profile 里到底有哪些可控参数

Cargo 的 profile 本质上是一组编译参数预设。默认情况下有dev和release两种，分别对应cargo build和cargo build --release。你可以通过[profile.dev]和[profile.release]来覆盖其中任意参数。下面是我自己常用的一组配置，可以先看一眼：

[profile.release] opt-level = 3 lto = "thin" codegen-units = 1 panic = "abort" strip = "symbols"

逐项解释一下这五个参数的用意。

opt-level控制优化等级，3 是最高优化，编译时间会变长，但运行效率最好。lto（链接时优化）有true和"thin"两种选择，true是完整 LTO，能把所有 crate 的代码放在一起做优化，效果最好但链接时间很长；"thin"是折中方案，优化效果接近完整 LTO，链接时间却明显更短，我通常建议用"thin"。codegen-units这个参数很有意思，默认是 16，意思是编译时把代码分块并行生成，速度更快，但每块之间的优化机会会被割裂。改成 1 之后所有代码交由单个编译单元统一优化，配合 LTO 效果更佳，代价是编译时间直线上升。

panic = "abort"的含义是遇到 panic 直接终止程序，而不是展开调用栈。这样做有两个好处：一是消除了 unwind 相关的运行时开销，二是二进制体积会显著减小。代价是你拿不到 panic 的栈回溯信息。对追求极致性能的服务端项目来说，这个取舍通常是值得的，但如果你在做需要详细排障的应用，建议保持默认的"unwind"。

strip = "symbols"会在链接完成后剔除符号表，这个对减小二进制体积效果立竿见影。Rust 编译器不做 strip 的话，一个简单的程序编译出来可能有几兆大小，加上这个参数能砍掉一大半。

2.2 自定义 profile 的进阶玩法

除了修改默认的 dev 和 release，Cargo 还允许你定义完全自定义的 profile，然后在构建时通过--profile参数指定。比如你可以在Cargo.toml里加一个：

[profile.bench] inherits = "release" lto = true codegen-units = 1

这个benchprofile 继承了 release 的配置，但把 LTO 开满。然后运行cargo build --profile bench就能生成一个专门为基准测试优化的构建版本，不影响常规的--release产物。

可能有人会问，直接用cargo bench不就行了？这个问题的答案在于，cargo bench是给内置 benchmark 用的，但很多时候我们需要对一个完整服务做压测，这时候一个独立的、优化拉满、并且带调试信息的构建版本就非常有用。我在做服务端性能调优时经常这么干，既能保留足够的栈信息，又能得到接近线上环境的运行效率。

注意：如果你开了panic = "abort"，要确认项目里没有依赖任何依赖“panic 捕获”逻辑的库，否则运行时会出现意想不到的行为。

2.3 构建体积与链接时间的实测参考

参数调到什么程度，心里要有数。我拿一个中等规模的项目做过对比，这里给出一个大致参考区间，不同项目会有浮动，但趋势是一致的：

实际选择取决于你的发布频率和运行环境。如果是 CI 里每次提交都要出包，编译时间太长会拖慢迭代速度，这种情况我建议用默认 release 加上strip = "symbols"就好。如果是手工发布正式版本，时间不是瓶颈，那就可以放心上全套。

3. 用 workspace 撑起多包项目的结构

单个 crate 的项目用 Cargo 其实没什么好讲的，结构天然清晰。但当代码量增长、模块增多之后，我强烈建议用 workspace 把项目拆成多个 crate。这不是“高级技巧”，而是从一开始就值得养成的组织习惯。

3.1 什么时候该拆 crates

判断标准不复杂，出现以下任何一个迹象就说明该拆了：

• 项目里出现了src/bin/下有多个可执行文件，并且它们共享大量代码。
• src/lib.rs或src/main.rs已经超过几千行，你开始频繁地在文件顶部来回跳转。
• 项目中有一部分代码有独立复用的可能，或者你明确想把它抽成单独的库对外发布。
• 你想为不同模块配置不同的编译特性或 profile，比如核心算法部分需要开满优化，而 CLI 部分保持快速编译。

把代码拆成多个 crates 之后，每个 crate 的编译单元变小，增量编译效果好很多。在 workspace 里你可能只需要重新编译变更的那个 crate 以及依赖它的 crate，其他部分走缓存。这一点对大型项目的日常开发体验提升非常明显。

3.2 一个实用的 workspace 布局

下面这个结构是我自己在项目中用得比较顺手的模板，代码量不大，但能完整说明 workspace 的组织逻辑：

my_project/ ├── Cargo.toml # workspace 配置 ├── crates/ │ ├── core/ # 核心库：算法、数据模型 │ │ ├── Cargo.toml │ │ └── src/ │ │ └── lib.rs │ ├── cli/ # 命令行入口 │ │ ├── Cargo.toml │ │ └── src/ │ │ └── main.rs │ └── server/ # HTTP 服务 │ ├── Cargo.toml │ └── src/ │ └── main.rs └── .gitignore

根目录的Cargo.toml长这样：

[workspace] resolver = "2" members = [ "crates/core", "crates/cli", "crates/server", ] [workspace.package] version = "0.1.0" edition = "2021" license = "MIT"

用[workspace.package]定义公共元数据之后，子 crate 的Cargo.toml里可以直接继承：

[package] name = "my_core" version.workspace = true edition.workspace = true license.workspace = true

这个version.workspace = true的写法意味着版本号只维护在根目录一处，子 crate 自动同步。保持一致性的同时，也省得改版本的时候到处翻。

3.3 workspace 依赖管理的几个细节

工作区里有个坑，我一开始也踩过：如果两个子 crate 依赖了同一个第三方库的不同版本，Cargo 会把它们视为两个完全不同的库。比如crates/cli依赖serde 1.x，crates/core依赖serde 2.x，那两边使用的类型系统是隔离的，互相传递时会出现类型不匹配的编译错误。解决方案是尽量在根Cargo.toml中统一强调依赖版本，或者用[workspace.dependencies]这个特性定义公共依赖：

[workspace.dependencies] serde = { version = "1.0", features = ["derive"] } tokio = { version = "1.30", features = ["full"] }

子 crate 里就不直接写版本号了：

[dependencies] serde.workspace = true tokio.workspace = true

这样的好处不仅仅是统一版本，也让升级依赖时只需要在根目录改一处。尤其在多包项目里，这个习惯能避免很多版本不一致导致的问题。

注意：cargo add命令在 workspace 根目录执行时，默认会把依赖加到当前 workspace 的根Cargo.toml里。如果[workspace.dependencies]已经定义了该依赖，可以直接使用，无需重复指定版本。

3.4 workspace 的锁文件与目标目录

在 workspace 下执行cargo build，所有 crate 的依赖会共享同一个Cargo.lock文件，位置在根目录。这个设计能保证整个 workspace 内的依赖版本完全一致，不会出现每个子 crate 一套依赖、互相之间对不上版本的情况。

同时，Cargo 默认把编译产物统一放在根目录的target/下。这意味着不同子 crate 的增量编译缓存可以互相复用，对大型多包项目的构建速度帮助很大。如果你发现某个子 crate 目录下莫名其妙出现了一个target/文件夹，那大概率是有人进入了子 crate 目录单独执行了cargo build，在 CI 或者团队协作中可以通过约定来避免这种情况。

4. crates.io 上拉取与发布依赖的完整流程

crates.io 这个公共仓库，我每天都要打交道。从别人那里拉依赖，把自己的代码发上去，两者背后都有一套固定的流程和潜在的坑，这里完整捋一遍。

4.1 拉取依赖：版本约束与执行过程

cargo add命令是目前最常用的添加依赖方式，以serde为例：

cargo add serde --features derive

执行完之后Cargo.toml里会自动多出这一行，并且版本号会带上^符号，表示“兼容此版本范围内的最新版”。语义化版本的逻辑是这样的：^1.0.92表示允许自动升级到1.x.y中不低于1.0.92的最新版本，但不会跨越到2.0.0。这是 Rust 生态默认采用的宽松策略，因为维护库的作者都承诺在0.x -> 0.y、1.x -> 2.x这样的大版本跨越时才允许破坏性变更。

如果你想更精细地控制版本，有这么几种写法：

• =1.0.92：精确锁定，不允许任何自动升级。
• ~1.0.92：只允许补丁版本变化，也就是1.0.x，不允许1.1.x。
• 1.0.*：允许1.0.x任意补丁版本，但不允许1.1.x。
• >=0.8, <2.0：自定义范围。

实际项目中，我很少手动改这些符号，默认的^已经足够安全。Cargo.lock文件会最终决定当前构建用的确切版本，所以即便版本约束允许升级，实际构建始终是可复现的。

这里插一个重要知识点：库（library）项目应该提交Cargo.lock吗？答案与直觉相反，大多数情况下的建议是不要提交。因为库的Cargo.lock锁的是自己在开发时用的那套依赖，但这个文件对最终用户没有意义——用户会用自己项目的锁文件来约束所有依赖。相反，应用（application）项目一定要提交Cargo.lock，因为它保证所有部署环境构建出的二进制产物完全一致。这也是为什么你用cargo new生成的项目，.gitignore会忽略target/但不会忽略Cargo.lock。

4.2 发布前准备工作

自己写的库要发到 crates.io，有几个前置工作不能跳过。

第一步是注册账号并获取 API token。在 crates.io 官网注册账号之后，到账号设置页面生成一个 token，然后在本地执行：

cargo login

它会让你黏贴 token，执行成功之后，token 会被存在你本机的~/.cargo/credentials文件中。这个文件务必保管好，它基本等同于你 crates.io 账号的密码，泄露了别人可以直接以你的名义发布恶意包。

第二步是完善Cargo.toml的元数据。cargo publish之前，Cargo 会检查name、version、description、license这些字段是否存在，缺少任何一个都会直接报错。

name的命名规范是：只能包含字母、数字、-和_，并且在 crates.io 上必须全局唯一。你可以在 crates.io 官网搜索确认一下名字是否被占用，这是个非常常见的发布失败原因。

license字段需要注意格式合法性。常见的开源协议可以直接写字符串，比如"MIT"、"Apache-2.0"。如果你不想选开源协议，可以填"license = \"proprietary\""或者加上license-file指向本地协议文件。Cargo 在发布前会校验你填写的许可证标识符是否是有效值，格式不对会直接拦下来。

第三步是确认README.md和文档注释。crates.io 的页面会自动渲染Cargo.toml同目录下的README.md，所以一个像样的项目说明文档是很有必要的。库文档注释（///）会被自动编译成 rustdoc 文档，并且发布后可以直接在 docs.rs 上查看。

4.3 发布操作与版本更新流程

发布的命令其实只有一条：

cargo publish --dry-run

先执行 dry-run 做本地验证，它会模拟完整的打包、检查和上传流程，如果这一步能顺利通过，再执行真正的：

cargo publish

打包的产物通过后会先上传到 crates.io 的存储系统，然后 crates.io 后台会触发构建验证，确保这个包可以被独立编译。这一步如果依赖了某些只在特定平台上可用的库，可能在这里暴露问题。

版本更新方面，Rust 生态严格遵循语义化版本规则。发新版本时，version字段需要比当前版本更高，并且不能直接重复发布相同版本号。升级流程一般是先用cargo release这类自动化工具，或者手动改Cargo.toml中的version字段，然后执行cargo publish。版本号选择逻辑：修复 bug 发补丁版本0.1.1，新增向后兼容功能发次版本0.2.0，破坏性 API 变更发主版本1.0.0。

4.4 撤销发布的正确姿势

代码发出去之后发现有问题，这是必然会遇到的情况。crates.io 不允许你直接删除一个已发布的版本，除非是发布后 72 小时内的紧急情况，可以通过管理员协助删除。常规操作是执行 yank：

cargo yank --version 0.1.0

这个命令的效果是：标记该版本为不可用，新项目拉取依赖时不会再选到这个版本。但对于已经使用了该版本的项目，Cargo.lock里锁定了它，依然能正常构建和运行。所以 yank 的本质是“阻止新用户使用这个版本”，而不是“从世界上抹掉这个版本”。

yank 一个版本之后，如果你的代码修复了，想重新让用户能用它，执行：

cargo yank --version 0.1.0 --undo

这个操作反过来，取消 yank 标记。需要提醒的是，yank 会直接影响用户对新版本的获取，尽量只在出现严重安全问题时使用，常规 bug 直接发布一个补丁版本更稳妥。

5. Cargo 生态里的日常命令，比你想的更强大

cargo build和cargo run只是基本功，真正提升开发效率的是围绕 Cargo 展开的一系列配套命令。

5.1cargo test：测试、集成测试与文档测试

cargo test默认会并行执行三种测试：单元测试、集成测试和文档测试。文档测试是 Rust 生态里很有意思的设计，///注释中的代码块只要标注了语言，就会被当作可执行代码编译运行。这意味着你在写文档示例的时候，示例本身就已经通过测试，不会出现文档写了一套 API 但实际用法完全错误的尴尬。

集成测试放在tests/目录下，每个文件会单独编译成一个 crate，因此无法访问被测试 crate 内部的私有 API。这个设计保证了集成测试只能通过公开接口来测试，更贴近真实使用场景。

5.2cargo doc：一键生成本地文档

cargo doc --no-deps会生成本项目的文档。如果想在本地直接预览依赖库的完整文档，可以去掉--no-deps。配合cargo doc --open会在浏览器打开文档首页。

我习惯在写库时频繁执行cargo doc检查文档内容是否规范，尤其注意#[must_use]、代码示例这些需要随文档一起维护的内容。

5.3 代码质量三件套：fmt / clippy / expand

cargo fmt自动格式化代码，统一团队风格，这个基本是共识。cargo clippy是一个静态分析工具集合，它跑在 Rust 编译器之上，能发现一大票“合法但不合理”的写法，比如不必要的克隆、冗余的模式匹配、过于复杂的类型签名。我在 CI 里一定会跑cargo clippy -- -D warnings，把 warning 升级为 error，强制保持代码质量。

cargo expand这个命令相对小众一些，它会把宏展开后的代码打印出来。Rust 宏用多了之后，有时候你想确认某个宏到底生成了什么代码，cargo expand就是干这个的。比如你用#[derive(Serialize)]序列化一个结构体，想知道生成的代码长什么样，执行cargo expand就能看到。对排查宏相关的编译错误非常有帮助。

5.4 专门的 Cargo 子命令工具链

Cargo 支持通过cargo install安装子命令扩展，安装后的工具可以直接用cargo 子命令名的方式调用。几个常用的：

• cargo-edit：现在已经内置在 Cargo 主程序里了，cargo add、cargo rm、cargo upgrade都从它演变而来。
• cargo-watch：监控文件变化，自动重新运行命令。开发阶段用cargo watch -x run可以实现保存代码后自动重启服务。
• cargo-audit：扫描依赖库的已知安全漏洞，会读取 Rust 安全公告数据库并给出报告。对生产项目来说，这个工具值得作为 CI 的必要环节。
• cargo-tree：展示依赖树，方便排查“这个包到底为什么被装进来了”以及版本冲突问题。

安装方式：

cargo install cargo-watch cargo-audit cargo-tree

安装路径默认在~/.cargo/bin/，如果 shell 里已经配置了 Cargo 的环境变量，这些命令就能直接使用。

6. build.rs 与构建脚本扩展

聊完日常工作流，再聊一个稍微进阶的话题：构建脚本。Rust 项目的构建过程并非只能依赖.rs文件，Cargo 允许你在项目的根目录放一个build.rs文件，它会在正式编译前被编译并执行，用于动态生成代码、链接系统库、读取环境信息等。

6.1 build.rs 的典型应用场景

最常见的用途是链接系统库。比如你想在项目里使用某个安装在系统里的 C/C++ 库，Rust 本身不知道去哪里找头文件和链接库，build.rs 就可以充当这个桥梁。通过rustc-link-search和rustc-link-lib这两个输出指令告诉 Cargo 链接路径和库名称。

第二个常见用途是生成代码。很多项目需要根据接口定义（比如 protobuf 文件、API 描述）自动生成 Rust 代码。把这些工作放进 build.rs，就能保证每次构建前自动执行生成逻辑，代码不可能过时。

第三个用途是条件编译。比如 build.rs 可以读取环境变量或者执行系统命令，然后将结果写入cargo:rustc-cfg指令，从而动态控制#[cfg(...)]条件编译属性。这在跨平台开发时特别有用。

6.2 一个可运行的 build.rs 示例

假设你想在构建时把 Git 提交哈希写进环境变量，这样程序运行时可以打印自己的版本信息：

use std::env; use std::process::Command; use std::str; fn main() { let output = Command::new("git") .args(["rev-parse", "HEAD"]) .output(); if let Ok(output) = output { if output.status.success() { let git_hash = str::from_utf8(&output.stdout).unwrap().trim(); println!("cargo:rustc-env=GIT_HASH={}", git_hash); println!("cargo:rerun-if-changed=.git/HEAD"); } } if env::var_os("PROFILE").as_deref() == Some("release".as_ref()) { println!("cargo:rustc-cfg=release_build"); } }

这个脚本做了两件事：一是通过cargo:rustc-env将GIT_HASH注入到编译环境中，代码里可以用env!("GIT_HASH")在编译期直接读取；二是通过cargo:rustc-cfg设置了一个条件编译开关，代码里可以用#[cfg(release_build)]做针对发布版本的额外处理。

6.3 构建脚本注意点

构建脚本只要没写好，你的编译过程会莫名其妙地变慢或变怪，这里列出几个常见的坑。

println!输出内容需要遵循cargo:前缀约定。构建脚本的 stdout 里，只有cargo:开头的指令才被 Cargo 解释执行，普通输出会被忽略。很多新手因为写成了普通的println!("rerun-if-changed=...")而加了半天调试输出却什么都没发生。

rerun-if-changed指令决定构建脚本何时重跑。如果没有这一行，Cargo 默认认为只要任何一个项目文件变化了，构建脚本就要重跑，这会导致不必要的重编译。反之，如果你指定了rerun-if-changed=path，Cargo 会更智能地只在关联文件变化时重新执行脚本。这里的路径也可以是目录，不过要注意目录变化触发规则在 Cargo 的不同版本里行为有差异，我是用文件路径的情况更多。

build.rs 编译时用的是主机平台，而不是目标平台。交叉编译的时候，这一点尤其需要留意，尽量避免在构建脚本里执行那些依赖目标平台行为的代码。

另外提醒一点，build.rs 不是万能药。有更复杂的构建需求时，先检查一下有没有现成的 crate 能帮你完成这些事，比如cc这个 crate 封装了 C/C++ 编译过程的很多细节，比手写 build.rs 可靠得多。

7. 常见问题与排查技巧实录

最后这部分，我把 Cargo 使用过程中的典型问题整理成速查表格，这些问题每一个我都碰到过，也总结过对应的排查思路。

7.1 Cargo 目录下的文件与目录

7.2 依赖相关的常见报错

7.3 发布相关的意外状况

7.4 编译与缓存相关的坑

Cargo 的增量编译偶尔会给人一种“改了什么但构建结果没变”的错觉。这种情况大概率不是你写错了，而是增量缓存出了问题。执行：

cargo clean

之后重新完整构建，通常能解决。但是注意，cargo clean会清掉整个 target 目录，全量编译一次的成本要心里有数。如果只是想清理某个 crate 的产物，可以指定包名：

cargo clean -p 你的包名

另外一个常见现象是 feature 组合爆炸。Rust 的 feature 机制允许多个开关组合开启，但组合数量多之后，Cargo 会把所有启用过的 feature 组合都单独缓存在 target 目录里，目录体积很容易膨胀。CI 里可以定期执行cargo clean或者用工具自动清理无用缓存。

7.5 我一直在用的调试与诊断命令

遇到依赖和构建问题先别急着搜，下面的命令可以帮你快速定位：

cargo tree -d # 展示重复依赖，方便排查多版本冲突 cargo tree -i 包名 # 反向查询，看这个包是被谁依赖引入的 cargo metadata # 以 JSON 格式输出整个项目的完整依赖图与构建信息

其中cargo metadata我经常配合脚本使用，比如自动生成依赖清单、CI 里检查非法依赖等，非常灵活。cargo tree -d其实是排查依赖版本冲突时的第一利器，它能直接看到哪些包同时存在多个版本，省去手动翻目录的功夫。

7.6 一个实际问题的排查过程

有一次我的项目突然报了一个奇怪的编译错误，错误信息指向了一个宏展开的中间代码，但我在源码里根本找不到对应的逻辑。我用了这样一套排查流程：

先执行cargo expand定位到宏展开的具体代码，确认问题来自某个第三方库的宏；再把错误信息复制到搜索引擎找到相似案例，确定是版本兼容问题；接着用cargo tree查看该库的版本树，发现有两个依赖同时依赖了不同版本；最后在根Cargo.toml中用[dependencies]统一指定该库版本，问题解决。整个过程十分钟内完成，这三个命令配合使用能解决大部分依赖类疑难杂症。

8. 写在最后的个人心得

Cargo 和 crates.io 这套工具链，是我用过的语言生态里“开箱即用”程度最高的组合之一。它把一个项目从零开始到发布线上服务的整个链路都管理得井井有条，很多时候你只需要描述清楚想干什么，比如加一个依赖、跑一组测试、做一个发布包，Cargo 就能把剩下的事情办好。

但工具再顺手，也有一条底层原则值得记住：理解行为，再依赖工具。我用 Cargo 的过程中，最大的收获不是记住了多少命令，而是把它背后的模型想明白了——release profile 是编译参数的封装，workspace 是 crate 组织方式的约定，lock 文件是版本确定性的保证，build.rs 是构建流程的扩展点。当你用这个视角去看它，一个新命令的出现就不再是陌生的知识点，而是归入这套模型中的一个自然延伸。

最后分享一个我的习惯：给任何项目写Cargo.toml的时候，都会顺手把description、license、repository这些元数据填上。看似是多打几个字，但它会强迫你把项目当做一个真正的“作品”来对待。等到哪一天你决定把自己的库发布到 crates.io，提交的时候就会庆幸自己一开始就养成了这个习惯。