> For the complete documentation index, see [llms.txt](https://gitbook-open-v2-preview.gitbook.workers.dev/url/gitbook.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gitbook-open-v2-preview.gitbook.workers.dev/url/gitbook.com/docs/documentation/zh/collaboration/member-management/permissions-and-inheritance.md).
# 权限与继承
GitBook 具有灵活的权限模型，可让你根据需要对权限拥有尽可能多或尽可能少的控制。GitBook 中的权限模型是一种 [**基于角色的**](/url/gitbook.com/docs/documentation/zh/collaboration/member-management/roles.md#roles-in-gitbook)**、级联式的** 模型。这意味着你先设置默认值，然后在内容的任何层级决定是否继承这些默认值。
你可以在四个层级设置权限： **组织**, **站点**, **集合**，以及 **空间**.
### 组织默认角色
当你向组织添加成员时，你会设置 [他们的默认角色](/url/gitbook.com/docs/documentation/zh/collaboration/member-management/roles.md)。此角色适用于任何从组织默认设置继承权限的内容。
### 权限如何级联
GitBook 中的权限按 **优先级**解析，而不是按所有层级中的最高角色解析。
对于处于继承模式的空间，GitBook 按以下顺序解析访问权限：
* **空间** — 空间上的直接成员和团队覆盖
* **站点** — 来自父站点的权限
* **集合** — 来自父集合的权限（如果存在）
* **组织** — 为每个成员设置的默认角色
这意味着，针对处于继承模式的链接空间，站点权限会覆盖组织默认设置和父集合默认设置。直接的空间级覆盖仍然优先于其他一切。
以下是两个实际运作示例：
示例 1
某成员在组织层级拥有创建者角色。一个链接空间处于继承模式，而父站点将该成员设置为评论者。该成员在该空间中获得评论者权限，因为站点优先于组织默认设置。
示例 2
某集合将一个空间设置为读者，而父站点将其设置为评论者。该空间使用评论者，因为在继承模式下，站点权限优先于父集合。如果你随后给某个成员在该空间中直接赋予创建者访问权限，那么该直接覆盖对该成员生效。
{% hint style="info" %}
**注意：** 站点权限仅适用于处于继承模式的空间。如果某个空间已配置自己的权限——也就是说它不在继承模式下——那么这些权限会优先，站点级权限不会影响它。
{% endhint %}
### 管理继承
每次创建集合或空间时，你都可以设置所需的继承类型。为某个内容设置继承时，你有三种大致选项：
### 继承
将继承设置为 **继承** 会使该空间或集合继承 **父级内容中分配的角色**。对于顶级空间或集合，这个父级是组织，因此它们会继承组织默认角色。对于集合中的空间或子集合，父级将是该内容所在的集合。
当一个空间链接到站点并保持在继承模式下时，GitBook 按以下顺序解析访问权限：直接空间覆盖，然后是父站点，然后是父集合，最后是组织。站点权限优先于组织和集合默认值，但不会改变直接的空间级覆盖。
### 特定角色访问
在设置集合或空间的权限继承时，选择特定角色会 **重置** 组织默认角色，并将每个 **非管理员** 分配到该集合或空间中的该角色。例如，如果你将继承设置为 **读者**，那么组织中的每个人都将对该空间或集合拥有只读访问权限，而不管其默认角色是什么。
对该集合或空间的直接成员或团队访问仍然可以覆盖此继承设置。如果你在空间本身上设置了特定角色，那么该空间就不再使用继承模式，因此站点权限不会影响它。
### 无访问权限
你也可以在空间或集合层级完全撤销任何非管理员组织成员的访问权限。这会向除管理员和创建该空间或集合的人之外的所有人隐藏内容。
{% hint style="info" %}
任何新创建的空间或集合的默认继承选项是 **继承**。这意味着每当创建某个内容时，它默认会继承其父级的权限。
{% endhint %}
### 设置内容特定权限
一旦你决定了空间或集合的权限继承方式，就可以通过授予团队或成员 **直接访问权限**.
### 为团队授予直接访问权限
你可以将团队直接添加到某个集合或空间，并赋予其特定角色。这样该团队中的任何人都会获得对该内容的指定访问权限。
{% hint style="info" %}
团队访问是确保合适的人访问合适内容的绝佳方式；无论何时有人被添加到团队或从团队中移除，他们都会分别获得或失去该内容上设置的权限。
{% endhint %}
### 为成员授予直接访问权限
与团队类似，你也可以直接授予成员访问权限。这是管理权限最细粒度的方式。当为单个成员授予对某个集合或空间的直接访问权限时，你会覆盖他们可能拥有的任何继承权限。若你需要对协作者进行非常具体的控制，直接成员访问权限非常有用。
在空间层级拥有直接访问权限的成员会完全从继承模式中移除。他们的角色会被明确设置，并且不受组织、站点或集合层级权限的影响。
### 持续管理权限
虽然一开始这看起来可能相当复杂，但 GitBook 的权限模型在你需要时能提供控制，不需要时则不会妨碍你。对许多团队来说， **一次设置，后续无忧** 的权限管理方式就已足够。对其他团队，尤其是更大的组织而言，这种对访问和工作流的控制程度是必不可少的。
#### 设置后不再操心
如果你只是想让同事快速加入并和你一起编辑内容，那么你甚至可能根本不需要查看权限。邀请成员，设置他们的默认角色，你创建的任何内容都会默认继承这些角色。无需钻研细节！
#### 对访问和工作流的控制
对于大型组织、将组织拆分为多个独立集合的团队，或需要对工作流进行非常细粒度控制的团队来说；深入细节正是所需。通过组合使用继承、覆盖、直接团队访问和直接用户访问，你可以创建让你保持掌控的工作流和访问模型。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://gitbook-open-v2-preview.gitbook.workers.dev/url/gitbook.com/docs/documentation/zh/collaboration/member-management/permissions-and-inheritance.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.