修改配置

README.md

@@ -129,6 +129,8 @@ vim .env.deploy-test
 
 > **pc（Electron）依赖安装**：在跑 `06-install-frontend.sh` 前，裸机请先执行 **`00-init-tools.sh`**（见上文「步骤 0」，含 GitHub SSH→HTTPS 重写）。仍报错见下文「pc 前端 yarn install 失败」。`pc` 建议仅用 **Yarn**；可删除 `package-lock.json` 消除混用锁文件警告。
 
+> **`07-start-frontend.sh`**：启动前会读取 `.env.deploy-test`（若存在），文末「访问地址」等处使用 `DEPLOY_TEST_IP`；未设置时默认为 `127.0.0.1`，避免脚本在 `set -u` 下因未定义变量退出。
+
 ---
 
 ## 配置文件（`.env.deploy-test`）
@@ -182,9 +184,11 @@ TENCENT_SDK_SECRET_KEY=xxx
 
 ### 后端服务
 
-| 服务 | 端口 |
-|------|------|
-| openim-server | :10002 (HTTP) / :10001 (WS) |
+| 服务 | 端口 / 说明 |
+|------|-------------|
+| openim-server | :10002（HTTP API）、:10001（MsgGateway WebSocket）— **同一进程上两个监听端口**，不是两个独立后端 |
+| chat-rpc | 对内 RPC（注册到 Etcd，无单独对外 HTTP 端口） |
+| admin-rpc | 同上 |
 | chat-api | :10008 |
 | admin-api | :10009 |
 | meetingmsg | :8000 (WS) |
@@ -192,6 +196,21 @@ TENCENT_SDK_SECRET_KEY=xxx
 | livestream | :8081 |
 | build-server | :8281 |
 
+> **进程数量**：`05-start.sh` 会拉起 **9 个独立操作系统进程**（上表 9 行）。其中 `openim-server` 是 **一个** OpenIM 单二进制，内部包含用户/群组/消息等 RPC 与 API、网关等模块；官方文档或 K8s 部署里常把其中一部分拆成多个 Pod，看起来像「十几个服务」，在本仓库的**单机单进程**模式下合并进同一个 `openim-server`，因此只看到 **1 个 PID**、**2 个对客户端暴露的端口**（10002 + 10001）。
+
+### 架构说明：`openim-server` 内部 RPC 与 `chat` 四进程
+
+#### `openim-server`：单进程里模块之间怎么调 RPC？
+
+- 单二进制在 `main` 里依次启动多个子模块（如 auth、user、group、msg、API、MsgGateway 等）。模块之间**仍然是 gRPC**：各模块在本机 **TCP** 上起 gRPC Server（端口可在配置里固定或由 `autoSetPorts` 分配），客户端通过 **`GetConn(服务名)`** 去连。
+- 服务发现使用 **`discovery/standalone`**（`config.SetStandalone()`）：在**当前进程内**维护「服务名 → 地址」的注册表，**不经过**本机 Docker 里的 **Etcd**。部署里的 **Etcd** 主要给 **chat** 与其它独立进程做发现；与 `openim-server` **内部** RPC 是两套机制。
+
+#### `chat` 为何是 `chat-rpc` / `admin-rpc` / `chat-api` / `admin-api` 四个进程？
+
+- **源码即四个独立 `main` 包**（`chat/cmd/rpc/...`、`chat/cmd/api/...`），与上游 OpenIM Chat 一致，编译为四个二进制，由 `04-build.sh` / `05-start.sh` 分别拉起。
+- **职责拆分**：**RPC**（给其它服务 gRPC 调用）与 **HTTP API**（对外 REST）分开；**业务侧（chat）** 与 **管理侧（admin）** 分开，便于鉴权、独立重启、按负载分别扩容，生产环境也可分机器部署。
+- **能否合并成一个进程（像 `openim-server` 那样）？** **理论上可以**：新增统一入口、在同一进程内启动四套逻辑并处理端口与 Etcd 注册即可。但本仓库 **当前未提供**该单进程模式，需要额外开发与测试；**默认与推荐**仍是 **4 进程** 部署。
+
 ### 前端开发服务器（可选）
 
 | 项目 | 端口 | 说明 |
@@ -316,12 +335,27 @@ TENCENT_SDK_SECRET_KEY=xxx
 cd pc && rm -rf node_modules && yarn install
 ```
 
+### `check-conn.sh`（MongoDB / S3）
+
+按 `.env.deploy-test` 检查远程 MongoDB 与两个 S3 Bucket。
+
+| 项目 | 说明 |
+|------|------|
+| **完整校验** | 安装 **mongosh** 可测认证与库访问；安装 **AWS CLI**（命令 `aws`）可列桶与读写探测。 |
+| **未安装工具时** | MongoDB 可用 **nc** 仅测端口连通；S3 会跳过并打印手动验证命令。 |
+| **安装提示** | 脚本按系统给出命令（macOS 为 `brew`；Debian/Ubuntu 为 `apt-get`；Amazon/RHEL 为 `dnf`/`yum`），不会在 Linux 上误导为 `brew`。 |
+| **可选自动安装** | 以 **root** 执行且设置 `CHECK_CONN_AUTO_INSTALL=1` 时，会尝试用 `apt`/`dnf`/`yum` 安装缺失的 `awscli`、`mongodb-mongosh`；失败仅告警，可按屏幕提示手动安装。 |
+
+```bash
+./deploy-test/check-conn.sh
+CHECK_CONN_AUTO_INSTALL=1 ./deploy-test/check-conn.sh   # root，可选自动安装 CLI
+./deploy-test/check-conn.sh mongo
+./deploy-test/check-conn.sh s3
+```
+
 ### 其他
 
 ```bash
-# 验证 MongoDB / S3 连接
-./deploy-test/check-conn.sh
-
 # 查看 LiveKit 日志（WebRTC 不通时）
 ./deploy-test/logs.sh livekit --last