diff --git a/boke.md b/boke.md
new file mode 100644
index 0000000..8d030c1
--- /dev/null
+++ b/boke.md
@@ -0,0 +1,266 @@
+image.png
+# 前言
+
+> 计划重新构建一套 `音视频大型会议直播` 系统，底层使用` mediasoup` ，信令业务层使用 `Golang` ，前端使用 `uniapp +
+> mediasoup-client` ，然后就是数据库服务`postgresql+redis`等等，一步一步，逐步来
+
+从“技术选型”迈进到系统工程设计。项目计划可直接作为后续详细设计蓝本的总纲，不是泛泛而谈的 PPT 文案。
+
+下面内容分 7 个部分，可以把它当成「音视频会议系统 0→1 架构说明书」。
+
+----
+
+## 一、项目整体目标与定位
+
+### 🎯 项目目标
+
+#### 构建一套 跨端可用、可扩展、可演进 的实时音视频系统，支持：
+	•	多人音视频会议
+	•	互动直播室
+	•	后期可扩展：录制、转推、跨服务器、超大房间
+
+### 🎯 技术核心思想
+
+	•	控制面与媒体面彻底分离 
+	•	业务系统与实时系统解耦
+
+这是选用 **`Go + mediasoup`** 的最大价值所在。
+
+----
+
+## 二、整体技术架构（总览）
+
+### 技术栈总览
+
+```cpp
+┌────────────────────────────┐
+│        Client 层           │
+│  uniapp + mediasoup-client │
+└───────────▲────────────────┘
+            │ WebSocket / HTTPS
+┌───────────┴────────────────┐
+│        Go 控制层            │
+│  (信令 / 会议 / 鉴权)      │
+└───────────▲────────────────┘
+            │ RPC / HTTP
+┌───────────┴────────────────┐
+│     mediasoup Node 层       │
+│   (媒体控制 API)            │
+└───────────▲────────────────┘
+            │ IPC
+┌───────────┴────────────────┐
+│     mediasoup Worker        │
+│       (C++ SFU)             │
+└────────────────────────────┘
+```
+
+
+---
+
+## 三、各组成部分详细说明（这是核心）
+
+### 1️⃣ 客户端层（uniapp + mediasoup-client）
+
+#### 📌 构成
+	•	uniapp
+	•	UI、页面、交互
+	•	多端统一（H5 / App / 小程序）
+	•	mediasoup-client
+	•	WebRTC 协商
+	•	音视频采集 / 编码 / 发送 / 接收
+
+#### 📌 uniapp与mediasoup-client的职责
+
+![职责	是否负责
+UI 展示	✅
+摄像头 / 麦克风	✅
+WebRTC 连接	✅
+会议规则	❌
+房间管理	❌](https://i-blog.csdnimg.cn/direct/022e41e28c9a47c3be74c77aabaed381.png)
+
+
+#### 📌 mediasoup-client 核心作用一句话
+	•	把“业务信令”翻译成“浏览器能跑的 WebRTC 行为”
+
+#### 📌 与其他模块的连接
+	•	WebSocket ⇄ Go 信令层
+	•	RTP / DTLS ⇄ mediasoup Worker（直连）
+
+---
+
+### 2️⃣ Go 控制层（系统中枢）
+
+这是整个系统的“大脑”
+
+#### 📌 核心职责
+
+##### ✅ 信令系统
+	•	WebSocket 长连接
+	•	消息广播
+	•	状态同步
+
+##### ✅ 会议系统
+	•	房间创建 / 销毁
+	•	用户进房 / 退房
+	•	主持人 / 角色管理
+	•	发言权限控制
+
+##### ✅ 安全与鉴权
+	•	JWT / Token
+	•	防止客户端滥用 mediasoup API
+
+##### ✅ 媒体控制编排
+	•	什么时候创建 Transport
+	•	什么时候 Produce / Consume
+	•	什么时候关闭流
+
+#### 📌 不负责的事情（很重要）
+	•	❌ 不处理 RTP
+	•	❌ 不参与媒体转发
+	•	❌ 不做 WebRTC 协议
+
+#### 📌 与其他模块的连接
+
+![对象	方式
+客户端	WebSocket
+mediasoup Node	HTTP / RPC
+Redis	状态缓存
+PostgreSQL	持久化](https://i-blog.csdnimg.cn/direct/b0b592baa6974635b8af8fbd13053c03.png)
+
+
+
+---
+
+### 3️⃣ mediasoup Node 层（媒体控制适配层）
+
+##### 📌 本质定位
+
+- C++ SFU 的“遥控器”
+
+##### 📌 职责
+	•	管理 Worker
+	•	创建 Router
+	•	创建 WebRtcTransport
+	•	管理 Producer / Consumer
+
+##### 📌 特点
+	•	不懂业务
+	•	不懂用户
+	•	只懂“媒体对象”
+
+##### 📌 为什么单独拆出来？
+	•	C++ Worker 高性能
+	•	Node 层方便控制与扩展
+	•	解耦 Go 与 C++
+
+---
+
+### 4️⃣ mediasoup Worker（真正的 SFU）
+
+##### 📌 这是“发动机”  ---- 负责：
+	•	RTP 转发
+	•	拥塞控制
+	•	带宽自适应
+	•	多人流转发
+
+##### 📌 特点
+	•	极高性能
+	•	完全不关心业务
+	•	媒体一旦开始，不再经过 Go
+
+-----
+
+### 5️⃣ PostgreSQL（强一致数据）
+
+##### 📌 存什么？
+	•	用户
+	•	房间元信息
+	•	会议记录
+	•	权限配置
+
+##### 📌 特点
+	•	强一致
+	•	可审计
+	•	不放“实时状态”
+
+----
+
+### 6️⃣ Redis（实时状态 & 协调）
+
+##### 📌 存什么？
+	•	房间在线用户
+	•	Transport / Producer 映射
+	•	用户状态（mute / speaking）
+	•	跨 Go 实例共享状态
+
+##### 📌 特点
+	•	高速
+	•	非持久
+	•	非常适合会议系统
+
+----
+
+### 7️⃣ 消息中间件（可选但推荐）
+
+##### 📌 什么时候需要？
+	•	多 Go 实例
+	•	跨服务器会议
+	•	录制 / 转码 / AI 分析
+
+##### 📌 用途
+	•	会议事件分发
+	•	异步处理
+	•	解耦系统模块
+
+----
+
+## 四、系统运行时的完整流程（简化版）
+
+```cpp
+1. 用户打开客户端
+2. WebSocket 连接 Go
+3. Go 校验并允许进房
+4. Go 调用 mediasoup 创建资源
+5. 前端 mediasoup-client 建立 WebRTC
+6. 媒体流直达 mediasoup Worker
+7. Go 只负责控制和状态
+```
+
+----
+
+## 五、这样设计的好处（非常关键）
+
+### ✅ 高性能
+	•	媒体流不经过 Go
+	•	SFU 专注转发
+
+### ✅ 高可扩展
+	•	Go 可横向扩展
+	•	Worker 可多进程 / 多机
+
+### ✅ 易演进
+	•	后期加录制、转推、AI
+	•	不影响现有会议
+
+### ✅ 技术边界清晰
+	•	Go 写业务
+	•	JS 写 WebRTC
+	•	C++ 跑媒体
+
+----
+
+## 六、这个方案非常“工程化”的原因
+
+这个方案是“企业级音视频系统”的标准形态
+
+### 这套架构与：
+	•	腾讯会议
+	•	Zoom
+	•	飞书会议
+在思想上都是一致的
+
+---
+
+
+
+