# 权限与继承

GitBook 具有灵活的权限模型，让你可以根据需要对权限进行尽可能多或尽可能少的控制。GitBook 中的权限模型是一个 [**基于角色的**](/docs/documentation/zh/collaboration/member-management/roles.md#roles-in-gitbook)**、级联的** 模型。这意味着你先设置默认值，然后在内容的任意层级决定是否继承这些默认值。

你可以在四个层级设置权限： **组织**, **站点**, **集合**，以及 **空间**.

### 组织默认角色

当你向组织添加成员时，你会设置 [他们的默认角色](/docs/documentation/zh/collaboration/member-management/roles.md)。此角色适用于任何从组织默认值继承权限的内容。

### 权限如何级联

GitBook 中的权限从上到下流经四个层级：

* **组织** — 为每位成员设置的默认角色
* **站点** — 在文档站点上设置的权限，适用于所有处于继承模式的关联空间
* **集合** — 在集合上设置的权限，适用于其中的所有空间
* **空间** — 基础层级，可直接在此设置权限

当一个空间处于继承模式时，每位成员都会被分配其在所有适用层级中拥有的 **最高角色** 。例如，如果某成员在组织层级是创建者，但在站点层级是评论者，那么他们在该空间中仍保留创建者权限。

下面有两个实际运作示例：

<details>

<summary><strong>示例 1</strong></summary>

某成员在组织层级拥有创建者角色。一个空间处于继承模式，某人将站点权限设置为评论者。该创建者在该空间中仍保留创建者权限，因为创建者高于评论者。组织中的其他人也会保留其现有角色——评论者除外，评论者会被提升为评论者，因为评论者高于阅读者。

</details>

<details>

<summary><strong>示例 2</strong></summary>

某集合具有阅读者权限，其中有五位成员被明确设置为创建者。该集合内的一个空间处于继承模式，某人将站点权限设置为评论者。组织中的每个人在该空间中都会升级为评论者，因为评论者高于该集合的阅读者权限。那五位指定的创建者会保留其创建者权限，因为创建者高于评论者。

</details>

{% hint style="info" %}
**注意：** 站点权限仅适用于处于继承模式的空间。如果某个空间已配置自己的权限——也就是说它不处于继承模式——那么这些权限将优先生效，站点级权限不会影响它。
{% endhint %}

### 管理继承

每当你创建一个集合或空间时，都可以设置所需的继承类型。在为某个内容设置继承时，你有三种大致选择：

### 继承

将继承设置为 **继承** 会让该空间或集合继承 **父级内容**中分配的角色。对于顶级空间或集合来说，父级是组织，因此它们会继承组织默认角色。对于集合内的空间或子集合来说，父级将是该内容所在的集合。

当空间链接到某个站点时，站点权限也会计入继承角色。每位成员都会获得其在组织角色、站点权限以及任何集合级权限中拥有的最高角色。

### 特定角色访问

在设置集合或空间的权限继承时选择某个特定角色，将会 **重置** 组织默认角色，并将所有 **非管理员** 分配为该集合或空间中的该角色。例如，如果你将继承设置为 **阅读者**，组织中的每个人都将对该空间或集合拥有只读访问权限，无论其默认角色是什么。

请注意，最高角色原则在这里仍然适用——如果某成员在其他层级（例如直接在空间上或通过团队覆盖）设置了更高的角色，他们将保留该更高角色。

### 无访问权限

你也可以在空间或集合层级完全撤销任何非管理员组织成员的访问权限。这会对除管理员以及创建该空间或集合的人之外的所有人隐藏该内容。

{% hint style="info" %}
任何新创建的空间或集合的默认继承选项是 **继承**。这意味着每当创建一项内容时，它默认都会从其父级继承权限。
{% endhint %}

### 设置内容特定权限

一旦你为你的空间或集合决定了权限继承方式，就可以通过向团队或成员授予 **直接访问权限**.

### 向团队授予直接访问权限

你可以直接将一个团队添加到某个集合或空间，并指定一个角色。这将为该团队中的任何人提供对该内容的指定访问权限。

{% hint style="info" %}
团队访问是一种确保合适的人能够访问合适内容的好方法；每当有人被加入或移出某个团队时，他们将分别获得或失去为该内容设置的权限。
{% endhint %}

### 向成员授予直接访问权限

与团队类似，你也可以向成员授予直接访问权限。这是管理权限最细致的方式。当向单个成员授予集合或空间的直接访问权限时，你会覆盖其可能拥有的任何继承权限。如果你需要对协作者进行非常具体的控制，直接成员访问非常适合。

在空间层级拥有直接访问权限的成员会完全从继承模式中移除。他们的角色会被明确设定，不受组织、站点或集合层级权限的影响。

### 持续管理权限

虽然一开始这可能看起来相当复杂，但 GitBook 的权限模型在你需要时会给你控制权，而在你不需要时则不会打扰你。对许多团队来说， **设置后即可忘记** 的权限管理方式就足够了。对其他团队，尤其是大型组织而言，这种对访问和工作流的控制程度至关重要。

#### 设置后即可忘记

如果你只是想让团队成员快速加入并与您一起编辑内容，那么你甚至可能永远都不需要查看权限。邀请大家，设置他们的默认角色，你创建的任何内容默认都会继承这些角色。无需深入细节！

#### 对访问和工作流的控制

对于大型组织、将组织划分为多个独立集合的团队，或需要对工作流进行极细粒度控制的团队来说，深入细节正是所需要的。通过结合继承、覆盖、团队直接访问和用户直接访问，你可以创建既能满足流程又能让你保持控制的工作流和访问模型。


---

# Agent Instructions: 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.com/docs/documentation/zh/collaboration/member-management/permissions-and-inheritance.md?ask=<question>
```

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.
