交付出件箱

← 返回出件箱

渠道机构地理分布数据驾驶舱

建设调研报告

版本 v3.0
日期 2026-08-15
密级 内部
编制 技术调研组
适用 管理层决策评审

版本沿革

阅读须知：本报告的证据边界

本报告所有技术判断均来自对现有系统代码的逐项检索，关键结论在附录 A 给出具体出处，可逐条复核。

为避免误导决策，先声明哪些内容可信、哪些待验证：

凡涉及数量、比例、金额的地方，本报告一律不提供未经实测的数字。 需要实测的部分已整理为独立的《数据摸底 SQL》交付件，由具备权限的同事执行后回填。

0. 管理层摘要

0.1 一句话结论

这个项目值得做，且比最初设想的价值更大——但它的成败不取决于地图画得好不好看，取决于两件数据基础工作能不能补上。

0.2 三个关键发现

发现一：能看的不只是"机构在哪"，还有"钱从哪来"

最初的需求是把机构位置和登录情况画到地图上。调研中发现，系统的结算模块里已经存有完整的经营数据：每一笔服务订单的金额、每一次到账确认、每个渠道的收益分成、按账期的结算单——全都在库里，且与机构、渠道是强关联的。

这意味着这块屏可以从"运维监控屏"直接升级为"经营驾驶舱"：左上角挂的不只是"今天多少人登录"，而是总销售额、本月业绩、各省排名、各渠道贡献。

对管理层的意义：同样一次投入，交付的不是一个IT监控工具，而是一个经营决策看板。

发现二：所有"地域维度"的价值，都卡在同一个数据缺口上

系统从建立至今没有采集过机构的地理位置。没有省市字段，没有行政区划字典；机构地址在入驻表单里是选填项，审核环节不校验。

这一个缺口，同时卡住了四件事：

• 地图上的机构点位（无坐标）
• 各省份活跃度着色（无省份归属）
• 各地区销售排名（有金额，但不知道算哪个省的）
• 区域管理员权限（不知道哪些机构属于哪个辖区）

换个角度看，这也是好消息：补地址这一件事，一次性解锁四项能力。它的投入产出比，比最初评估的高得多。

发现三：三个"销售额"，必须先定一个

系统里"销售额"有三种不同口径，数字互不相同：

这三个数在任何时点都不会相等。 大屏必须明确主口径，否则会出现"大屏说本月 100 万、财务报表说 80 万"的局面——管理层对数据的信任一旦崩塌，这块屏就没人看了。

此外还有一个容易踩的坑：公司的结算账期是半月制（1-15 日为上半月，16 日至月末为下半月），不是自然月。大屏若按自然月统计"本月销售额"，会与结算单对不上。

0.3 投入与产出

0.4 请管理层决策的三件事

1. 销售额以哪个口径为准（详见 §3.1）——不定这个，指标做不了；
2. 区域怎么划分（分几个大区、各含哪些省）——不定这个，区域权限无法开工；
3. 地址补录由谁在什么时间完成——这是全项目工期的关键路径。

0.5 建议立即执行的一件事

跑一次数据摸底（6 条只读查询，约 1 分钟）。

结果直接决定项目排期是 8 周还是 12 周。在此之前的任何排期都是估算。

1. 项目建设背景与建设目的

1.1 业务背景

公司目前采用"渠道创建 → 机构入驻 → 机构账号独立登录"的三级管理模式：渠道由平台创建并负责拓展维护机构，机构提交入驻资料并签约后开通，机构下的席位账号独立登录使用系统，按席位售卖。

这套模式在扩张期运转正常，但管理侧的观测手段没有跟上：

看不到"在哪里"。 系统从未采集地域信息，无法回答"我们在哪些省有机构""哪个区域覆盖薄弱""某渠道的机构集中在哪"。

看不到"谁在用"。 登录记录完整落库，但只能逐条翻表格查询，无法一眼判断系统整体活跃程度，也无法察觉某区域机构的集体沉默。

看不到"钱的分布"。 经营数据（订单、到账、收益分成）虽然完整，但只能在结算模块里按账期、按渠道逐张单据查看，没有任何一个视图能同时回答"这个月卖了多少、哪个省卖得好、哪个渠道贡献大"。

发现问题到处置问题之间是断的。 即便发现异常账号，处置动作要切换到其他管理页面完成，中间隔着多次跳转查找。

1.2 技术现状（决定项目难易）

调研确认了六项事实：

有利条件

① 登录行为已完整落库，且记录真实公网 IP。
认证审计表完整记录每次登录的账号、IP、终端与精确时间，网关与应用的代理配置配套，记录的是用户真实公网地址而非机房内部地址。实时上屏不需要新增任何埋点。

② 渠道、机构、签约、登录、经营数据同处一个物理数据库。
结算系统虽已拆分为独立服务，但生产部署与核心系统同库共存（通过独立数据库账号做权限隔离）。跨模块关联可用一条 SQL 完成，不需要跨服务接口编排。

③ 经营数据结构完整、时间维度齐全。
服务订单（含金额、类型、席位数、状态、时间）、到账确认（含确认金额与确认时间）、收益快照（含实收、渠道分成、账期）、结算单（含账期总额、状态）四张表构成完整链路，且订单表已有"机构+时间"的复合索引。

④ 渠道级数据隔离已有生产级实现。
结算模块中，渠道账号访问自己的收益账本时，系统从数据库反查其所属渠道（不信任客户端声明）并据此过滤数据。这是一套已在生产运行的行级数据权限实现，大屏可直接沿用这一模式。

⚠️ 此处修正 v2.0 报告的一处判断。 v2.0 称"系统完全没有数据行级权限基础"，该判断对核心系统成立，但忽略了结算模块已有的渠道隔离实现。修正后的结论是：渠道管理员权限可复用现有模式，只有区域管理员需从零建设。 这降低了权限阶段的实施风险。

不利条件

⑤ 系统没有任何地理维度数据。
无省市字段，无行政区划字典。机构地址两个来源：门店分享名片的选点位置（业务不强制）、入驻签约地址（表单选填，审核只校验营业执照、门头照、视光师资质、设备照四类文件，不校验地址）。

⑥ 系统没有"在线状态"概念。
登录采用无状态令牌，登录后不打卡、不心跳、退出不落库。系统能回答"该账号今天上午十点登录过"，无法回答"该账号此刻是否在线"。

1.3 建设目的

按业务价值排序：

1. 让经营状况一屏可见 —— 销售额、地区业绩、渠道贡献，管理层不必等报表；
2. 让机构分布从抽象概念变成事实 —— 全国分布、区域密度、空白市场一目了然；
3. 让"谁在用系统"实时可感 —— 登录即上屏，活跃度直观；
4. 让发现异常到处置异常缩短到一次点击；
5. 让不同层级管理者看到与其职责匹配的数据；
6. 让异常主动找人，而不是等人去找。

2. 大屏整体布局设计：一条故事线

2.1 设计原则：不堆图表，讲故事

大屏最常见的失败方式，是把十几个图表平铺在屏幕上——每个图表单独看都对，合起来看不出结论。领导站在屏幕前三十秒，得不出任何判断，第二次就不会再来看。

本方案按"总览 → 分布 → 贡献 → 趋势 → 风险"的顺序组织，让视线自然流动，三十秒得出结论。

2.2 布局方案

┌───────────────────────────────────────────────────────────────────────────┐
│  渠道机构经营驾驶舱                    2026-08-15 周五 14:32   [投屏模式]    │
├──────────────────┬────────────────────────────────┬───────────────────────┤
│ ① 核心指标（左上） │      ② 中国地图（中央主区）        │  ③ 排行榜（右上）      │
│                  │                                │                       │
│  累计销售额        │      ●  ●                      │  省份业绩 TOP 10       │
│  ¥ 12,345,678    │        ●   ●●                  │  ▓▓▓▓▓▓▓ 广东  ¥xxx   │
│                  │      ●●  ●                     │  ▓▓▓▓▓ 江苏  ¥xxx     │
│  本月销售额  ↑12% │         ●●●                    │  ▓▓▓ 浙江  ¥xxx       │
│  ¥ 1,234,567     │        ●  ●                    │  ─────────────────    │
│                  │                                │  渠道贡献 TOP 10       │
│  今日活跃机构  86 │   ● 在线  ● 今日活跃            │  ▓▓▓▓▓▓ 渠道A  ¥xxx   │
│  渠道总数      12 │   ● 近期  ● 沉默               │  ▓▓▓▓ 渠道B  ¥xxx     │
│  机构总数     328 │                                │                       │
│  未定位        41 │   [全国] [华东] [华南] ...      │  [切换：业绩/机构数]   │
├──────────────────┴────────────────────────────────┼───────────────────────┤
│ ④ 活跃与业绩趋势（左下）                            │ ⑤ 异常提醒（右下上半）  │
│                                                    │  🔴 多地登录 3 起      │
│    登录次数 ╱╲    ╱╲                               │  🟠 非工作时间 7 次    │
│           ╱  ╲╱╲╱  ╲╱╲                            │  🟡 频繁重连 2 家      │
│    活跃机构 ─────────────                          │  ────────────────     │
│                                                    │ ⑥ 入驻/拓展进度（右下） │
│    近 30 天  [7日|30日|90日]                       │  机构A ▓▓▓▓░░ 资料待审 │
│                                                    │  机构B ▓▓▓▓▓▓ 已开通   │
├────────────────────────────────────────────────────┴───────────────────────┤
│ 💡 今日关键洞察：今日全国活跃机构 86 家，较昨日上升 5%，华东区贡献最大；        │
│    发现 3 起多地登录异常，建议关注。本月销售额已达上月同期的 112%。            │
└────────────────────────────────────────────────────────────────────────────┘

2.3 视线动线说明

设计要点：左上是视觉黄金位，放最重要的钱；中央面积最大，放最需要探索的地图；右侧竖排适合排行；底部横条适合趋势与结论。异常提醒放右下，是因为它需要被看到但不该抢戏——正常情况下这块应该是安静的。

2.4 与最初需求的差异说明

需求原文中"左上：全国总览核心指标（总销售额、今日活跃机构数、渠道总数等）"已完整落地。此处仅补充两项：

1. 增加"未定位机构数" —— 放在核心指标区，与机构总数并列。理由见 §8.2，这是数据诚实性的底线要求；
2. 底部增加"今日关键洞察"通栏 —— 需求中要求放在"角落"，本方案改为底部通栏。理由：这是全屏唯一给出结论的区域，放角落容易被忽略，通栏能确保被看到，且不占用主要视觉面积。

3. 核心业务指标体系（老板视角）

本章逐项说明每个指标的数据来源、是否现成、图表选型与选型理由。

3.1 销售额类指标

3.1.1 必须先解决的口径问题

系统中存在三个可称为"销售额"的数据，数值互不相同：

建议方案：主口径用 B（确认到账），副口径展示 A（订单应收）。

理由：
- 老板最关心"钱到账没有"，到账金额是真实经营成果；
- 同时展示应收，可反映"已签未收"的规模，这本身是有价值的管理信息；
- C 口径与渠道结算强绑定，更适合放在渠道贡献榜（见 §3.3），而不是总销售额。

大屏呈现建议：主数字显示到账金额，下方小字标注"应收 ¥xxx，待收 ¥xxx"。一个指标讲清三件事。

3.1.2 账期问题（极易踩坑）

公司结算账期是半月制：每月 1-15 日为上半月，16 日至月末为下半月。这是系统中已固化的规则。

风险：大屏若按自然月统计"本月销售额"，与财务的结算单口径不一致，数字对不上。

建议：大屏默认按自然月展示（符合管理层直觉），但在指标旁的口径说明中明确标注"按自然月统计，与半月账期结算单口径不同"，并提供切换到账期视图的选项。

3.1.3 指标清单

3.2 各地区销售排名

说明：本指标是"补地址"这项工作最有价值的产出之一。地址一旦补齐，销售的地理分布立即可用，无需额外开发。

3.3 各渠道销售贡献排名

重要提示：系统已有渠道收益的聚合实现（用于结算单）。大屏必须复用该逻辑，不得另写一套，否则会出现大屏与结算单数字不一致的情况。

3.4 机构活跃趋势

3.5 项目/任务进度（甘特图需求）

需要如实说明的一点

需求中希望用甘特图展示"机构入驻进度、渠道拓展进度"。调研结果如下：

系统已有的：机构入驻的完整状态流转（9 个状态）及各节点的实际发生时间（提交时间、审核时间、开通时间、服务起止时间）；服务订单的 8 个状态及创建时间。

系统没有的：计划完成时间。真正的甘特图需要"计划工期 vs 实际工期"的对比，而系统只记录了实际发生的时间点，从未记录过"计划什么时候完成"。

两个方案

建议选 A，并配合一个入驻漏斗图（提交资料 → 审核通过 → 已付款 → 已开通，各环节数量与转化率）。漏斗图能立刻暴露"卡在哪个环节"，这是渠道管理的核心抓手。

若业务坚持要甘特图，需先明确各环节的标准时长（如"资料审核 2 个工作日内完成"），补录后即可实现。

3.6 异常提醒数据

3.7 指标汇总表

结论：九项指标中，六项数据完全现成，两项卡在地址补录，一项需业务补充规则。

4. 交互设计：联动下钻

4.1 设计目标

大屏不止"可看"，还要"可查"。从看到异常到定位问题，应在三次点击内完成。

4.2 三条联动链路

链路一：点省份 → 全屏聚焦该省

点击地图"广东省"
   ├→ 地图：广东省高亮放大，其余省份变暗，展开显示该省机构点位
   ├→ 右上排行榜：从"省份业绩榜"自动切换为"广东省内城市业绩榜"
   ├→ 右上渠道榜：过滤为"在广东有机构的渠道"排名
   ├→ 左上核心指标：全部切换为广东省口径，标题追加"· 广东省"
   ├→ 左下趋势图：切换为广东省的活跃与业绩趋势
   └→ 顶部出现面包屑「全国 > 广东省」，点击可返回

关键设计：切换省份时，所有指标卡片的标题必须同步变化（如"本月销售额 · 广东省"）。若标题不变而数字变了，会造成严重误读。

链路二：点渠道 → 该渠道机构高亮

点击右上"渠道 A"
   ├→ 地图：该渠道名下机构点位高亮放大，其他机构降至 20% 透明度
   ├→ 左上核心指标：切换为该渠道口径
   ├→ 左下趋势图：切换为该渠道的业绩与活跃趋势
   └→ 顶部面包屑「全国 > 渠道 A」

业务价值：渠道经理汇报时，一次点击就能看到自己负责渠道的全国分布与业绩，不必单独出报表。

链路三：点异常告警 → 直达处置

点击"多地登录 · XX视光中心"
   ├→ 地图自动定位到该机构并高亮
   ├→ 弹出机构详情面板：
   │    · 机构基础信息、归属渠道
   │    · 本次异常详情（两地 IP、归属地、时间间隔）
   │    · 近期登录记录
   └→ 面板底部：处置按钮区（仅操作模式下可见，见 §9）

业务价值：这是"发现问题到解决问题"链路最短的一条，是大屏区别于静态报表的核心价值。

4.3 交互实现约定

5. 智能提示：今日关键洞察

5.1 设计定位

大屏最大的价值不是展示数据，而是给出结论。老板不该自己从图表里推导判断。

在屏幕底部通栏，自动生成 1~2 句话的当日结论。

5.2 生成规则（基于阈值判断，不涉及复杂算法）

5.3 呈现原则

1. 每次最多显示两句 —— 超过两句就不是洞察，是报告；
2. 先说好消息还是坏消息，取决于严重程度 —— 有红色级异常时，异常优先；
3. 必须可点击 —— 点击洞察中提到的对象（如"华东区""渠道 A"），大屏自动下钻到对应视图；
4. 句式固定，数字动态 —— 用模板生成，不引入不可控的文本生成，避免出现语义不通或结论错误的句子；
5. 无异常时也要有话说 —— 例如"今日运行平稳，无异常事件"，避免空白区域让人以为系统坏了。

5.4 明确不做的

不做趋势预测、不做原因归因、不做行动建议的自动生成。这类结论需要业务上下文，规则引擎给不出可靠答案，给错了比不给更糟。

6. 视觉设计规范（远距离观看）

6.1 字号规范

6.2 配色规范

主色控制在 4 种以内：

硬性约束：
1. 红色是稀缺资源。 正常状态一律不用红色，否则真出问题时无法引起注意；
2. 机构点位四状态用同一色系的明度变化（在线最亮 → 沉默最暗），而非四种不同颜色，避免颜色数量失控；
3. 深色背景下文字对比度须满足无障碍标准，确保远距离和侧向观看的可读性；
4. 不依赖颜色单独传递信息 —— 状态除颜色外还需有形状或文字标识，兼顾色觉障碍人群。

6.3 动效规范

理由：大屏是常年运行的，任何持续动效都会增加渲染负担并导致卡顿；3D 图表在远距离观看下会因透视产生数值误判（前面的柱子看起来比实际更大）——这是数据可视化的大忌。

6.4 地图点位密度控制

这是必须的设计，不是可选项。 若全国视野直接铺所有机构点位，密集区域（如珠三角、长三角）会糊成一片，既看不清也拖慢渲染。

7. 详细业务需求拆解

7.1 地图可视化需求

核心卡点：机构位置从哪来

两个现有来源均不可靠（见 §1.2）。建议三层兜底取值：

1. 有签约地址 → 解析成省市与坐标（业务语义最正式）；
2. 无签约地址但有门店名片坐标 → 直接采用；
3. 两者皆无 → 进入"未定位机构"清单，在大屏单独计数并明示。

原则：绝不允许把未定位机构静默丢弃。

地图上的"位置"代表什么

7.2 机构详情查询需求

判定：详情面板九成以上是现成数据，只需查询组装。v3 版本新增了经营信息，使详情面板从"运维视角"升级为"客户视角"——点开一家机构，既看得到它在不在线，也看得到它贡献了多少业绩。

在线状态口径建议

系统无心跳机制，无法精确回答"此刻是否在线"。建议用活跃度四级替代：

优点：零新增埋点，纯查询实现，口径可解释可审计。

7.3 账号安全处置需求

强制下线的技术真相

系统现有两套"下线"机制，均不能直接满足需求：

机制一：令牌黑名单。 用户主动退出时把其令牌加入黑名单。
局限：管理员踢人时，服务端并不持有对方的令牌（无状态令牌不落库），此机制用不上。

机制二：席位设备绑定。 席位账号的令牌携带设备标识，每次请求都与数据库记录比对，不一致即拒绝。
这是现成的能力：对机构席位账号，只需修改数据库中的设备标识，该账号所有请求立即失效——即时生效，几乎零成本。

对管理员、机构管理员、渠道账号则需新建机制：按账号记录失效时间戳，令牌校验时比对其签发时间。

⚠️ 最易遗漏的一点：访问令牌 30 分钟过期，但续期凭证最长可达一年。若只废止访问令牌，被踢用户 30 分钟后会自动续上——等于没踢。强制下线必须同时废止续期凭证。

7.4 配套数据统计需求

见 §3 完整指标体系。此处强调一条：

所有指标口径必须与现有系统保持一致。 系统现有的机构洞察功能已有一套活跃度口径，结算模块已有一套渠道收益聚合逻辑。大屏必须复用，不得另写。 否则会出现同一指标在两个页面显示不同数字的情况，管理层对数据的信任会瞬间归零。

7.5 权限管控需求

现状（v3 修正版）

现有权限体系为"角色 → 菜单开关"结构，控制"能否进入某页面"。

但结算模块已实现了渠道级的数据行级隔离：渠道账号访问收益账本时，系统从数据库反查其所属渠道（不信任客户端声明），并据此过滤数据；账号停用或换绑后下一次请求即失效。

逐角色拆解

需新建的能力

1. 区域体系：区域定义、区域与省份映射、管理员与区域绑定；
2. 统一数据范围过滤层：所有大屏接口统一按"当前登录者可见范围"过滤；
3. 角色扩展：新增区域管理员角色并接入现有菜单权限体系。

一条安全红线

数据范围过滤必须在后端接口层强制执行，不能靠前端隐藏。

前端隐藏只是"看不见"，接口照样返回全量数据。渠道之间存在竞争关系，渠道 A 看到渠道 B 的机构名单与业绩，属于严重的商业信息泄露。 验收时必须专项测试：用渠道账号直接调用接口，验证返回数据确实被过滤。

处置类接口同样需要范围校验，不能只在查询接口做过滤——否则会出现"看不到但能操作"的越权漏洞。

7.6 异常提醒需求

关于"频繁掉线"

系统目前物理上无法统计掉线。 没有心跳机制，也不记录会话终止——系统只知道"何时登录"，不知道"何时断开"，因此"掉线"事件在数据层不存在。

建议选 A，且大屏上必须如实标注为"频繁重连"而非"掉线"。指标名称与实际口径必须一致，这是数据可信度的底线。

告警送达方式

系统现有的统一错误上报接口目前是占位实现，只写日志、不落表、不推送。已具备的推送通道有短信与微信订阅消息。

建议本期只做"大屏内提醒 + 落库可查"，不做外部推送。 外部推送涉及告警规则配置、免打扰策略、误报处理，属独立的运营监控课题，混入本项目会显著拉长工期。

8. 数据口径统一与可信度保障

本章是全报告中最不该被跳过的一章。大屏失败的最常见原因不是技术，是"老板发现数字对不上，从此不再相信它"。

8.1 大屏只做展示层，不做计算层

硬性原则：大屏不新增任何统计口径。

若某指标现有系统没有，先定义、后使用，并同步到相关报表，绝不允许大屏独有一套算法。

8.2 未定位机构必须如实显示

大屏核心指标区必须包含"未定位机构数"，与机构总数并列展示。

理由：若全国 328 家机构中有 41 家没有地址，地图上只能显示 287 个点。如果不明示这 41 家的存在，管理层会误以为"我们只有 287 家机构"，进而做出错误的市场判断。

这一条没有商量余地。宁可屏幕上难看，不可让数据说谎。

同理适用于：
- 金额统计中若有订单缺少金额，须标注"其中 X 笔金额待确认"；
- 渠道排名中若有机构未关联渠道，须单列"未归属渠道"项。

8.3 每个指标都要能自证口径

每个指标卡片右上角设置一个小问号图标，鼠标悬停（或触屏点击）显示该指标的统计口径说明。

示例：

本月销售额
口径：本自然月内财务确认到账的金额合计
数据来源：到账确认记录
更新频率：每 15 秒
注意：与半月账期结算单口径不同

这个设计的真实作用，是在老板问"这数怎么和财务报表对不上"时，当场就能自证，而不是会后再查三天。这是保护项目本身的机制。

8.4 数据时效性必须可见

屏幕右上角常驻显示"数据更新于 HH:MM:SS"，并在数据超过预期未更新时（如连续两个周期未刷新）显示醒目提示。

理由：大屏最危险的故障不是崩溃——崩溃看得见；而是静默停止更新，屏幕上还挂着昨天的数字，所有人以为是实时的。

9. 操作安全设计：看得见、控得住

9.1 双模式设计

切换规则：
- 投屏 → 操作：需重新输入当前登录账号的密码；
- 操作模式闲置超过设定时长（建议 5 分钟）自动退回投屏模式；
- 操作模式下屏幕边框显示警示色，让所有人都知道"现在这块屏是能动手的"。

设计理由：大屏常年挂着，若处置按钮长期可见，任何路过的人都可能误操作停掉客户账号。看板与操作台合一，必须有物理性的模式隔离。

9.2 处置操作规范

关于状态立即回显：这一条容易被忽略但极其重要。若管理员点了禁用、系统提示成功、但屏幕上点位还是亮的，人会本能地怀疑"到底成功没有"，并可能重复操作。操作与反馈必须闭环。

9.3 IP 脱敏规则

理由：归属地信息足以支撑业务判断（判断是否异地登录），完整 IP 只在深度排查时需要。默认最小化展示，是隐私合规的基本原则。

9.4 多人同时操作的冲突防护

10. 整体功能架构设计

10.1 总体架构

┌────────────────────────────────────────────────────────────────┐
│                    数据驾驶舱大屏（全屏页面）                       │
│  ┌─────────┬────────────────────────┬─────────────────────┐   │
│  │ ① 指标模块│      ② 地图模块          │  ③ 排行模块          │   │
│  │ 销售/活跃 │   分布/点亮/聚合/下钻     │  省份榜/渠道榜        │   │
│  ├─────────┴────────────────────────┼─────────────────────┤   │
│  │ ④ 趋势模块                         │ ⑤ 异常模块           │   │
│  │ 登录趋势/业绩趋势                    │ ⑥ 进度模块           │   │
│  ├────────────────────────────────────┴─────────────────────┤   │
│  │ ⑦ 智能洞察模块（底部通栏）                                   │   │
│  └──────────────────────────────────────────────────────────┘   │
│         ↓ 点击点位/告警          ⑧ 详情弹窗模块                    │
│                                 └→ ⑨ 处置模块（受控·仅操作模式）    │
└────────────────────────────────────────────────────────────────┘
                              ↕
┌────────────────────────────────────────────────────────────────┐
│              ⑩ 权限模块（贯穿全部请求 · 后端强制）                   │
│     菜单准入（已有） + 数据范围过滤（渠道可复用 / 区域需新建）          │
└────────────────────────────────────────────────────────────────┘
                              ↕
┌────────────────────────────────────────────────────────────────┐
│                          后端服务层                              │
│  大屏查询 │ 经营聚合 │ 处置服务 │ IP归属地 │ 异常检测 │ ⑪ 日志审计   │
└────────────────────────────────────────────────────────────────┘
                              ↕
┌────────────────────────────────────────────────────────────────┐
│               数据层（同一数据库 · 现有表为主）                     │
│  机构│渠道│签约档案│服务订单│到账确认│收益快照│结算单               │
│  登录审计│行为流水│操作审计   ＋ 机构地理表(新) ＋ 区域体系表(新)     │
└────────────────────────────────────────────────────────────────┘

10.2 模块设计要点

11. 技术选型建议

11.1 前端地图

建议 ECharts 方案，核心理由是合规与可控，而非成本。

需注意：现有前端图表库不支持地理投影，必须新增地图库依赖——这是本项目唯一需要新增的前端依赖。

11.2 IP 归属地解析（已实测）

采用离线 IP 归属地库，本机实测结果：

• 精度：省 + 市 + 运营商
• 性能：8 次查询 1.55 毫秒
• 合规：本地文件查询，登录 IP 不发送第三方
• ⚠️ 短板：现成库文件为 2022 年版本，需在上线前更新
• 附带价值：能识别内网地址，可作为部署健康探针

11.3 后端服务

• 沿用现有技术栈，不引入新框架；
• 大屏查询接口独立分组，便于权限与限流管理；
• 处置接口复用现有账号管理能力，不重复建设；
• 经营指标聚合复用结算模块现有逻辑；
• 新增：数据范围过滤依赖、IP 归属地服务（结果缓存）、异常检测服务、洞察生成服务。

11.4 数据库

• 沿用现有数据库，不引入新组件；
• 新增两张小表：机构地理信息表、区域体系表；
• 必要的索引优化：登录审计表现有索引为单列，而大屏查询均为"最近 N 分钟的成功登录"组合条件，需增加组合索引；
• 经营数据的订单表已有"机构+时间"复合索引，可直接支撑趋势查询；
• 是否需要预聚合表：建议先不做。先用实时查询 + 短时缓存，实测有压力再引入，避免过早优化引入数据一致性问题。

11.5 实时通信

系统内已有 WebSocket 与 SSE 两种实时技术的先例，但本项目建议均不采用，使用定时轮询。

业务侧的"实时"指十几秒内可见，而非毫秒级。 轮询完全满足且最稳。

12. 移动端轻量版

12.1 定位

老板不在办公室时，也要能掌握全局。

移动端不是大屏的等比缩小——地图在手机上既看不清也点不准。移动端应回答三个问题：今天怎么样？有没有事？要不要管？

12.2 功能范围

关于是否支持移动端处置：建议不支持。 理由是移动端环境不可控（可能在地铁、餐厅），高危操作缺乏审慎条件；且移动端二次鉴权体验差。移动端定位是"感知"，处置回到电脑端完成。

若业务坚持需要，建议仅开放"强制下线"一项（该操作可逆、风险最低），禁用与重置密码仍限电脑端。

12.3 实现方式建议

建议做响应式网页版，作为大屏项目的一个交付项，而非独立项目。预计增加 3~4 人日。

12.4 移动端专属设计

1. 单列纵向排布，从上到下：洞察 → 核心指标 → 异常 → 排行 → 趋势；
2. 异常提醒置顶（与大屏不同）—— 手机上查看多为"确认有没有事"，异常优先级最高；
3. 数字仍需大字号，移动端阅读距离近但屏幕小，建议核心数字占屏宽的 1/3 以上；
4. 支持下拉刷新，不做自动轮询（省电）。

13. 系统部署模式

13.1 现状

系统已部署于云端服务器，容器化编排，数据库、缓存、后端、前端各自独立，由网关统一对外提供加密服务。当前已是云端部署。

需注意：服务器资源配置偏紧，各容器均设有内存上限。这与 §15.4 的刷新压力评估直接相关。

13.2 模式对比

结论：采用云端部署。 若需固定大屏展示位，配一台专用终端常开浏览器即可，无需改变部署架构。

13.3 大屏常驻的技术细节

访问令牌 30 分钟过期。 大屏挂一整夜，次日清晨将出现空白或错误提示。

必须实现静默续期与断线重连提示。 这一条容易遗漏，须写入实施清单并在验收时专项检查（建议验收方式：大屏连续运行 24 小时后检查是否仍正常刷新）。

14. 分阶段落地实施计划

工作量为经验估算，非实测，按单人投入计算，不含需求评审与验收往返时间。

14.1 阶段划分

14.2 关键说明

1. P0 可立即启动，不依赖任何业务决策；
2. 地址补录必须与 P0 并行启动 —— 这是唯一一件技术加班也快不了的事，需业务侧安排人力。若等 P2 完成才发现无数据，整体延期 2~4 周；
3. P1 需在业务确定销售额口径后启动 —— 口径未定则指标无法实现；
4. P5 是风险最高的一段（动权限底座）。若业务可接受"一期仅总管理员使用"，P5 可后置，整体提前约 1.5 周；此时 P4 的处置能力应仅对总管理员开放；
5. P7 可与 P5/P6 并行，不占关键路径。

14.3 建议时间安排

第 1 周    │ P0 数据地基 ─────────────┐
          │ 【业务侧】地址补录 ────────┼──── 持续进行
第 2 周    │ P1 经营指标层 ───────────┘
第 3-4 周  │ P2 大屏主体
第 5 周    │ P3 交互与洞察
第 6 周    │ P4 账号处置
第 7-8 周  │ P5 分级权限          ┐
          │ P7 移动端（并行）      ┘
第 9 周    │ P6 异常提醒
第 10 周   │ 整体验收 + 24 小时常驻测试

14.4 建议的里程碑演示节点

建议在 M2 节点安排一次管理层评审。 此时大屏已可投屏，能获得真实反馈，且后续三个阶段仍有充分调整空间。

15. 潜在风险及应对办法

15.1 数据对接风险

15.2 地图定位精度风险

15.3 权限安全风险

15.4 实时刷新压力风险

15.5 多人操作冲突风险

15.6 登录 IP 隐私合规风险

16. 预期业务价值

16.1 管理效率

16.2 经营决策

• 渠道管理：各渠道的业绩贡献、机构数量、地域集中度、活跃程度一屏对比，为渠道考核与资源倾斜提供事实依据；
• 市场拓展：空白省份、薄弱区域一目了然；结合地区业绩排名，可判断"哪里有市场但我们没覆盖"；
• 业绩管理：本月进度与上月同期对比实时可见，不必等月末结算才知道快慢；
• 客户成功：区域性活跃度下滑可被及时发现，从被动等反馈变为主动干预。

16.3 风险控制

• 多地登录、异地登录等账号共享嫌疑主动暴露，直接服务于按席位售卖的商业模式；
• 非工作时间登录纳入观测，异常使用行为可追溯；
• 所有处置操作留痕（含前后快照），责任可追溯；
• 入驻流程卡点可视化，减少"资料交了没人审"的流失。

16.4 数据资产沉淀（易被低估的长期价值）

本项目最持久的价值，可能不是那块屏幕，而是它促使我们把机构地理数据补齐并纳入常态维护。

这份数据一旦建立，可复用于：

• 区域化运营分析与考核
• 渠道区域保护策略
• 市场活动的地域投放
• 客户地域画像与选址参考
• 未来任何需要"按区域看"的需求

这是一次性投入、长期复用的基础数据资产。

16.5 价值实现的三个前提

以下三条不满足，上述价值将大打折扣：

1. 地理数据必须补到位 —— 覆盖率决定这块屏的可信度。一张只有三成机构的地图，管理层看两次就不会再看；
2. 指标口径必须与现有报表统一 —— 同一指标两个页面两个数字，数据可信度瞬间归零；
3. 权限隔离必须真实有效 —— 渠道之间的数据隔离一旦出问题，是商业事故，不是技术缺陷。

附录 A · 证据索引

附录 B · 待业务确认事项

附录 C · 数据摸底清单

以下查询必须在具备权限的环境执行，结果回填后本报告的数据侧论证方为完整。全部为只读查询，不修改任何数据，执行约 1 分钟。

完整可执行脚本与结果解读说明见配套交付件《数据摸底 SQL》。

核心判据：

本报告为调研结论，不含任何已实施的代码改动。数据层结论待摸底查询执行后回填。调研环境未连接生产数据库，报告中不提供任何未经实测的数据指标。