# 双轨网络模型：按动作分轨而非按用户分轨

> **日期**: 2026-05-13
> **模块**: internal-app-platform
> **类型**: 架构权衡

## 背景

internal-app-platform 网络模型几次反复：
1. 第一版：全内网 + VPN（最简单，但居家不便）
2. 用户改：公网 + SSO（居家友好）
3. 暴露矛盾：Gitea 仍在内网 IP，git push 实际过不去
4. 最终决策：**按"动作"而非"用户"分轨**

## 关键洞察

最初我下意识地按"谁在访问"分（员工 / 同事），其实更准确的分法是**按"动作的频率和敏感度"**：

| 动作 | 频率 | 敏感度 | 网络要求 |
|------|-----|------|---------|
| 访问 app URL | 极高（每天多次） | 低（已 SSO 闸门） | 公网 OK |
| git push 部署代码 | 极低（一周几次） | 高（代码即权限）| 走 VPN OK |
| MCP 工具调用（非 push） | 中 | 中 | 公网 OK |

**摩擦应该加在低频+高敏感的动作上**，不要加在高频+低敏感的动作上。

## 反模式

我第一版把"员工"打成一个标签，导致整段 §访问网络模型 都在讲"员工访问 + 部署一起算"。实际员工的"访问行为"和"部署行为"网络要求完全不同。

## 适用范围

任何"既要让用户体验顺畅、又要保护后台资源"的场景都可以用：
- 内部工具（这次）
- 管理后台（普通用户走公网 + SSO，超管操作走 VPN）
- 数据导出（查看走公网，下载大文件走 VPN）

## 实现要点

- 平台侧不感知 VPN 状态，**只在 git push 那一步**用 `git ls-remote` 预探测，不通就让 AI 提示员工连 VPN
- 不要把 VPN 状态做成全局门禁中间件（容易把"高频访问"误拦）
- PoC 验证清单要拆成两个步骤：A. MCP 公网调用 + B. git push 走 VPN（两件事独立失败/独立修复）