被飞书和火山引擎账号体系整崩溃了？一个程序员彻底讲清楚背后的设计逻辑

很多程序员第一次接入 飞书开放平台 或 火山引擎 API 时，都会经历一个非常崩溃的过程。

你只是想：

写个程序调用 API。

结果打开文档后发现：

Tenant
App
User
Access Token
App Token
Tenant Token
User Token
子账号
主账号
IAM权限

一堆概念扑面而来。

很多人第一反应是：

为什么账号体系这么复杂？

但当你理解背后的设计逻辑之后，你会发现一件事：

飞书、火山引擎、AWS、阿里云、腾讯云，本质上用的是同一套账号架构模型。

今天这篇文章，就从 程序员视角彻底拆解这套系统设计。

一、为什么云平台账号体系这么复杂

很多开发者都有一个误区：

网站账号 = 用户账号

但云平台完全不同。

云平台面对的不是个人用户，而是：

企业组织。

例如一家公司可能有：

1000 个员工
20 个开发项目
50 个开发者
10 个管理员
100 个应用

如果只有一个账号体系：

系统会立刻混乱。

所以大厂统一采用 多层账号架构。

基本结构是：

sql 复制代码

组织（Tenant）
 ├── 用户（User）
 ├── 应用（App）
 └── 权限（Permission）

这套模型几乎是 所有 SaaS 和云平台的标准设计。

二、飞书账号体系到底是什么结构

飞书其实是一个 企业 SaaS 平台。

它的核心模型是：

sql 复制代码

企业（Tenant）
   │
   ├── 用户（User）
   │
   └── 应用（App）

1 企业 Tenant

企业就是 租户空间。

例如：

字节跳动
腾讯
阿里
你的公司

每个企业都有独立的数据空间。

企业里包含：

用户
群
文档
应用
数据

这就是飞书 API 里的：

复制代码

Tenant Access Token

它代表：

企业级访问凭证。

2 用户 User

用户就是企业员工。

例如：

张三
李四
王五

用户登录飞书后，会获得：

sql 复制代码

User Access Token

可以调用：

用户信息
日程
文档
群消息

3 应用 App

开发者创建的程序。

例如：

飞书机器人
自动审批系统
自动报表系统
OA 系统

每个应用都会生成：

复制代码

App ID
App Secret

用来换取：

复制代码

App Access Token

飞书账号体系架构图

飞书本质上是一个 典型的多租户 SaaS 架构。

核心是：

sql 复制代码

Tenant
   │
   ├── User
   │
   └── App

三、飞书 Token 为什么这么多

很多人第一次看飞书 API 文档时会崩溃。

因为 Token 有很多种：

App Access Token
Tenant Access Token
User Access Token

但其实逻辑很简单。

1 App Token

应用级 Token。

使用场景：

复制代码

机器人发消息
应用调用API

2 Tenant Token

企业级 Token。

使用场景：

复制代码

获取员工列表
企业组织结构

3 User Token

用户授权 Token。

使用场景：

复制代码

获取用户日程
操作用户文档

总结一句话：

ini 复制代码

App Token   = 应用权限
Tenant Token = 企业权限
User Token   = 用户权限

四、飞书 API 授权流程

理解授权流程非常重要。

基本流程是：

markdown 复制代码

应用创建
     ↓
申请API权限
     ↓
管理员授权
     ↓
用户授权
     ↓
获取Token
     ↓
调用API

飞书授权流程图

这就是典型的：

OAuth 授权模型。

五、火山引擎账号体系

火山引擎其实是 云平台架构。

和飞书不同。

它的结构是：

复制代码

主账号
   │
   ├── 子账号
   │
   └── 云资源

1 主账号

主账号就是企业账号。

例如：

复制代码

公司注册的火山云账号

拥有：

所有资源
所有权限
计费权限

2 子账号

子账号用于：

复制代码

团队协作

例如：

开发
运维
数据团队
财务

每个人权限不同。

火山引擎 IAM 权限体系

核心结构：

复制代码

主账号
   │
   ├── 用户
   │
   ├── 角色
   │
   └── 权限策略

这和 AWS / 阿里云 完全一样。

六、飞书和火山账号为什么不统一

很多人会问：

飞书和火山引擎为什么不能用同一账号体系？

原因是：

定位完全不同。

平台	定位
飞书	企业协作平台
火山引擎	云计算平台

飞书更像：

复制代码

企业操作系统

火山引擎更像：

复制代码

云基础设施

所以账号体系必须不同。

七、开发者最常踩的坑

我总结了几个常见问题。

1 Token 用错

例如：

sql 复制代码

Tenant Token
去调 User API

直接报错。

2 Token 过期

飞书 Token 一般：

复制代码

2小时过期

必须刷新。

3 权限没申请

很多 API 报错其实是：

复制代码

权限未开通

4 子账号权限不足

在火山引擎中：

复制代码

子账号默认没有权限

必须绑定策略。

八、大厂账号体系的统一设计

如果总结飞书和火山引擎。

其实核心模型只有一句话：

sql 复制代码

Tenant + User + App + Permission

结构如下：

sql 复制代码

企业（Tenant）
   │
   ├── 用户（User）
   │
   ├── 应用（App）
   │
   └── 权限（Permission）

这种架构可以支持：

SaaS
云平台
开放平台
API生态

九、为什么所有大厂都这么设计

原因只有三个。

1 多租户隔离

不同企业数据隔离。

2 权限控制

不同角色不同权限。

3 应用生态

支持第三方开发。

十、总结

很多程序员第一次接触飞书或火山引擎时会觉得：

账号体系太复杂。

但实际上：

这是 大型 SaaS 平台的标准架构。

理解这套模型之后：

你会发现：

飞书
钉钉
AWS
阿里云
腾讯云

本质上都是：

复制代码

租户 + 用户 + 应用 + 权限

理解这个设计逻辑之后：

很多 API 文档就会变得 非常清晰。