diff --git a/contents/cargo/reference/deps-overriding.md b/contents/cargo/reference/deps-overriding.md
index d62e29c6..af501f45 100644
--- a/contents/cargo/reference/deps-overriding.md
+++ b/contents/cargo/reference/deps-overriding.md
@@ -4,7 +4,7 @@
 - 你正在同时开发一个包和一个项目，而后者依赖于前者，你希望能在能项目中对正在开发的包进行测试
 - 你引入的一个依赖包在 `master` 分支发布了新的代码，恰好修复了某个 bug，因此你希望能单独对该分支进行下测试
 - 你即将发布一个包的新版本，为了确保新版本正常工作，你需要对其进行集成测试
-- 你为项目的某个依赖包提了一个 PR 并解决了一个重要 bug，在等待合并到 `main` 分支，但是时间不等人，因此你决定先使用自己修改的版本，等未来合并后，再继续使用官方版本
+- 你为项目的某个依赖包提了一个 PR 并解决了一个重要 bug，在等待合并到 `master` 分支，但是时间不等人，因此你决定先使用自己修改的版本，等未来合并后，再继续使用官方版本
 
 下面我们来具体看看类似的问题该如何解决。
 
@@ -97,7 +97,7 @@ uuid = { git = 'https://github.com/uuid-rs/uuid' }
 #### 间接使用 `patch`
 现在假设项目 `A` 的依赖是 `B` 和 `uuid`，而 `B` 的依赖也是 `uuid`，此时我们可以让 `A` 和 `B` 都使用来自 `github` 的 `patch` 版本，配置如下:
 ```toml
-package]
+[package]
 name = "my-binary"
 version = "0.1.0"
 
@@ -164,10 +164,10 @@ uuid = { git = 'https://github.com/uuid-rs/uuid', branch = '2.0.0' }
 ```toml
 [patch.crates-io]
 serde = { git = 'https://github.com/serde-rs/serde' }
-serde2 = { git = 'https://github.com/example/serde', package = 'serde', branch = 'v2' 
+serde2 = { git = 'https://github.com/example/serde', package = 'serde', branch = 'v2' }
 ```
 
-第一行说明，第一个 `patch` 从官方仓库 `main` 分支的最新 `commit` 拉取，而第二则从我们自己的仓库拉取 `v2` 分支，同时将其重命名为 `serde2`。
+第一行说明，第一个 `patch` 从官方仓库 `main` 分支的最新 `commit` 拉取，而第二个则从我们自己的仓库拉取 `v2` 分支，同时将其重命名为 `serde2`。
 
 这样，在代码中就可以分别通过 `serde` 和 `serde2` 引用不同版本的依赖库了。
 
diff --git a/contents/cargo/reference/features/examples.md b/contents/cargo/reference/features/examples.md
index 95cb753b..0ae3766b 100644
--- a/contents/cargo/reference/features/examples.md
+++ b/contents/cargo/reference/features/examples.md
@@ -4,14 +4,14 @@
 ### 最小化构建时间和文件大小
 如果一些包的部分特性不再启用，就可以减少该包占用的大小以及编译时间:
 
-- [`sync`](https://crates.io/crates/syn) 包可以用来解析 Rust 代码，由于它很受欢迎，大量的项目都在引用，因此它给出了[非常清晰的文档](https://docs.rs/syn/1.0.54/syn/#optional-features)关于如何最小化使用它包含的 `features`
+- [`syn`](https://crates.io/crates/syn) 包可以用来解析 Rust 代码，由于它很受欢迎，大量的项目都在引用，因此它给出了[非常清晰的文档](https://docs.rs/syn/1.0.54/syn/#optional-features)关于如何最小化使用它包含的 `features`
 - [`regex`](https://crates.io/crates/regex) 也有关于 features 的[描述文档](https://docs.rs/regex/1.4.2/regex/#crate-features)，例如移除 Unicode 支持的 feature 可以降低最终生成可执行文件的大小
 - [`winapi`](https://crates.io/crates/winapi) 拥有[众多 features](https://github.com/retep998/winapi-rs/blob/0.3.9/Cargo.toml#L25-L431)，这些 `feature` 对用了各种 Windows API，你可以只引入代码中用到的 API 所对应的 feature.
 
 ### 行为扩展
 [`serde_json`](https://crates.io/crates/serde_json) 拥有一个 [`preserve_order` feature](https://github.com/serde-rs/json/blob/v1.0.60/Cargo.toml#L53-L56)，可以用于在序列化时保留 JSON 键值队的顺序。同时，该 feature 还会启用一个可选依赖 [indexmap](https://crates.io/crates/indexmap)。
 
-当这么做时，一定要小心不要破坏了 SemvVer 的版本兼容性，也就是说：启用 feature 后，代码依然要能正常工作。
+当这么做时，一定要小心不要破坏了 SemVer 的版本兼容性，也就是说：启用 feature 后，代码依然要能正常工作。
 
 ### no_std支持
 一些包希望能同时支持 [`no_std`](https://doc.rust-lang.org/stable/reference/names/preludes.html#the-no_std-attribute) 和 `std` 环境，例如该包希望支持嵌入式系统或资源紧张的系统，且又希望能支持其它的平台，此时这种做法是非常有用的，因为标准库 `std` 会大幅增加编译出来的文件的大小，对于资源紧张的系统来说，`no_std` 才是最合适的。
diff --git a/contents/cargo/reference/manifest.md b/contents/cargo/reference/manifest.md
index 032d1c05..00af5947 100644
--- a/contents/cargo/reference/manifest.md
+++ b/contents/cargo/reference/manifest.md
@@ -237,7 +237,7 @@ categories = ["command-line-utilities", "development-tools::cargo-plugins"]
 workspace = "path/to/workspace/root"
 ```
 
-需要注意的是 `Cargo.toml` 清单还有一个 `[workspace` 部分专门用于设置工作空间，若它被设置了，则 `package` 中的 `workspace` 字段将无法被指定。这是因为一个包无法同时满足两个角色：
+需要注意的是 `Cargo.toml` 清单还有一个 `[workspace]` 部分专门用于设置工作空间，若它被设置了，则 `package` 中的 `workspace` 字段将无法被指定。这是因为一个包无法同时满足两个角色：
 
 - 该包是工作空间的根包(root crate)，通过 `[workspace]` 指定)
 - 该包是另一个工作空间的成员，通过 `package.workspace` 指定
@@ -297,7 +297,7 @@ include = ["/src", "COPYRIGHT", "/examples", "!/examples/big_example"]
 - 若项目包含可执行文件或示例代码，则最小化的 `Cargo.lock` 会自动被包含
 - `license-file` 指定的协议文件
 
-> 这两个字段很强大，但是对于生产实践而言，我们还是推荐通过 `.gitignore` 来控制，因为这样协作者更容易看懂。如果大家希望更深入的了解 `include/exclue`，可以参考下官方的 `Cargo` [文档](https://doc.rust-lang.org/stable/cargo/reference/manifest.html?search=#the-exclude-and-include-fields)
+> 这两个字段很强大，但是对于生产实践而言，我们还是推荐通过 `.gitignore` 来控制，因为这样协作者更容易看懂。如果大家希望更深入的了解 `include/exclude`，可以参考下官方的 `Cargo` [文档](https://doc.rust-lang.org/stable/cargo/reference/manifest.html?search=#the-exclude-and-include-fields)
 
 
 #### publish
diff --git a/contents/cargo/reference/profiles.md b/contents/cargo/reference/profiles.md
index ebbba7fd..2547df0e 100644
--- a/contents/cargo/reference/profiles.md
+++ b/contents/cargo/reference/profiles.md
@@ -50,7 +50,7 @@ cargo build --profile release-lto
 - 默认使用 `dev` : `cargo build`, `cargo rustc`, `cargo check`, 和 `cargo run`
 - 默认使用 `test`: `cargo test`
 - 默认使用 `bench`: `cargo bench`
-- 默认使用 `release`： `cargo install`, `cargo build --release`, `cargo build --release`
+- 默认使用 `release`： `cargo install`, `cargo build --release`, `cargo run --release`
 - 使用自定义 profile: `cargo build --profile release-lto`
 
 
diff --git a/contents/cargo/reference/workspaces.md b/contents/cargo/reference/workspaces.md
index 54c3c598..19942caf 100644
--- a/contents/cargo/reference/workspaces.md
+++ b/contents/cargo/reference/workspaces.md
@@ -102,7 +102,7 @@ default-members = ["path/to/member2", "path/to/member3/foo"]
 这样一来， `cargo build` 就不会应用到虚拟清单工作空间的所有成员，而是指定的成员上。
 
 ## workspace.metadata
-与 [package.metadata](https://course.rs/cargo/reference/manifest.html#metadata) 非常类似，`workspace.metadata` 会被 `Cargo` 自动忽略，就算没有被使用也会发出警告。
+与 [package.metadata](https://course.rs/cargo/reference/manifest.html#metadata) 非常类似，`workspace.metadata` 会被 `Cargo` 自动忽略，就算没有被使用也不会发出警告。
 
 这个部分可以用于让工具在 `Cargo.toml` 中存储一些工作空间的配置元信息。例如:
 ```toml