1. 1.5 设计哲学：框架提供能力，业务决定时机
框架边界过大或过小都会拖累业务：前者替业务做过多默认假设，后者又缺少可组合的基础能力。zhenyi 上尽量遵循：框架侧重「是否具备某种能力」与「如何安全调用」；业务侧决定「是否在此时、以此方式使用」。
1.1. 1.5.1 为何强调这一边界
若框架写死业务规则，跨场景时容易僵化，例如：
| 框架若强绑定 | 常见问题 |
|---|---|
| 登录后必须立即绑定某种 Id | 角色 ID、设备 ID、内部账号体系各异 |
| 固定会话生命周期 | 各产品对「会话」定义不同 |
| 固定路由维度 | 有的按用户，有的按房间、租户、设备等 |
可扩展性往往来自少做不可逆的业务断言，多留可组合的原子能力。
1.2. 1.5.2 示例：连接上的标识绑定
- 框架提供：在连接对象上 设置 / 读取 业务侧标识的能力（具体 API 见仓库）。
- 业务决定：在登录成功、换绑、登出等哪一时刻读写；使用何种 Id 体系亦由业务定义。
// 示意：能力存在，调用时机由业务代码决定
channel.SetAuthId(userId)
channel.GetAuthId()
即：提供挂钩点，不代替业务编排生命周期。
1.3. 1.5.3 原则在其它能力上的体现（概括）
| 领域 | 框架侧常见职责 | 业务侧常见职责 |
|---|---|---|
| 认证与连接标识 | 提供 Set/Get 等接口 | 决定何时绑定、解绑、用何种 Id |
| 会话与映射 | 提供表或结构能力 | 定义会话边界与清理策略 |
| 本进程路由 | 提供可替换的本地路由实现 | 注册路由、选择目标实例 |
| 远程与分片 | 提供策略与发现扩展点 | 注册元数据、配置选址规则 |
1.4. 1.5.4 本节要点
通用性来自清晰的能力边界：基础设施便于复用，业务决策权留在应用层。阅读后续网关、路由、热更新等章节时，可把「框架默认提供了什么」与「仍须业务拍板的部分」分开看，会减少误用与二次封装成本。