政务系统开发

项目背景

这是数字政府方向的一组多端系统：政务侧与企业侧各自有门户、管理端和移动端，另有一套指挥可视化大屏。两侧共用后端能力，但使用人群、权限模型和数据范围完全不同。项目的特点是形态多、端多、权限复杂——它不是做一个系统，而是在同一方向上并行交付多种形态的端。

客户当时的状态

数字政府方向的项目通常有两种做法：一种是把所有角色塞进一个系统，靠权限配置区分；另一种是按使用人群拆开，各自独立。第一种看着省事，实际会把权限做得极其复杂，界面还要同时兼顾两类完全不同的使用习惯，结果两边都不好用。同时，这一方向天然需要门户、管理端、移动端和大屏多种形态，如果各端各自定义业务口径，数据就会对不上，维护成本也会翻倍。

我们的做法与取舍

第一个取舍是按使用人群拆门户，但共用后端能力。政务侧和企业侧各自有门户与后台，交互和权限各自演进；底层业务能力和接口只维护一套。代价是前端要多做一套，收益是两侧都不会被对方的复杂度拖累。

第二个取舍是把数据范围隔离做成平台能力。政务项目的权限问题不能靠「大家都知道谁能看什么」来解决，必须由系统保证。我们在平台层统一管理功能权限与数据可见范围，多级组织下的隔离是配置出来的，不是约定出来的。

第三个取舍是不把大屏当展示图做。大屏要接多类指标和实时数据，还要在指挥场景下稳定运行——数据接口、刷新机制和容错都得认真设计。这一块如果按「做几张图」的预期去估工作量，上线一定会出问题。

系统怎么承载这条链路

入口层覆盖两侧门户、管理端、移动端与大屏；业务层承载两侧各自的业务逻辑；平台层提供统一的权限体系与多级数据范围隔离；数据层承载指标汇总与大屏数据接口。移动端与 Web 端共用同一套业务接口，不做两套业务逻辑。

交付状态与边界

代码库处于维护状态，最近提交在 2026 年上半年。边界必须讲清楚：政务类项目的客户名称、项目细节与运行数据，公开披露需要客户书面授权——我们没有拿到授权，所以本页只写行业与系统形态，不写客户名称、不写省份。如果项目评审需要核实，可在合规前提下按流程提供材料。另外，平台承载的是线上化与留痕，不替代法定行政程序；政务数据的归集与治理责任在主管部门。

还有一点需要如实说明：底层使用了成熟开源管理框架作为底座，业务层是我们自研的。对外表述统一为「基于成熟开源框架自研业务层」，不会把开源框架说成自研。