企业官网建设流程全解析

简介：这是一份电子政务OA系统建设方案范文，面向政务信息化规划人员、系统集成工程师及项目管理者，用于指导办公自动化系统的顶层设计、国产化适配、功能规划与实施落地。资源为单个doc文档，压缩包约6MB，内容结构完整，目录层级清晰，已有68人学习浏览，可直接作为同类项目方案撰写的参考模板。文档从总则切入，明确建设背景、目标、范围与原则，并给出国产化适配改造及升级路径，涉及成熟体系架构、灵活部署、安全防护与数据迁移；基础支撑平台部分则详述了工作流引擎、表单引擎、统一用户/权限管理、消息与门户引擎等核心组件，应用系统功能特点突出全面国产化支持、高可用性、单点登录、分级授权、智能工作流及WPS无缝集成。基本功能部分覆盖统一门户登录、公文交换、移动办公、会议室管理、督查督办等模块，并对收发文、签报、委托办理等流程做了说明，可直接借鉴其功能架构与流程设计，适用于电子政务OA项目的方案编制、汇报材料整理或招投标文档参考。

1. 电子政务OA系统建设方案：从“建一个系统”到“重构一条业务链”

电子政务OA系统建设方案，表面上是部署一套办公自动化软件，实际上是在把“纸面流转”的办事逻辑重新翻译成数字化的工作流。很多人忽略了这条底层逻辑，导致系统第一版上线即停滞——软件本身跑得通，干部却继续用纸质流程，最后 OA 变成“电子文件夹”。方案真正的落地点，是先梳理清楚单位内的公文类型、审批规则、附件生命周期、历史数据血缘，再做技术选型。这篇笔记面向政务信息化从业者和集成商项目经理，从架构分层、流程建模、迁移对接、踩坑复盘到上线验收，按一条可复现的链路展开。

2. 部署架构与基础设施选型：电子政务OA的承载层决定上限

2.1 网络边界与部署模式：内网、外网、混合模式怎么选

电子政务 OA 系统的部署模式不是凭习惯定的，而是跟着数据敏感度分级走的。一个单位内部的办公数据，至少有四个级别：普通通知公告、一般性会议纪要、组织人事相关信息、财务合同审批信息。这四类数据放在同一个访问边界内，后期安全评估会非常被动。

常见做法是分成两个工作区：日常办公区承载普通公文、会议、日程、内部邮件；受限办公区承载组织人事、财务审批、合同台账。两个区域之间通过前置机或者人工导出的方式单向交换文件，禁止数据库层面直接互通。建设方案的第一步就是把这张网络边界图画出来，因为后续的服务器采购、中间件选型、子系统的拆分方式，全部由这张图决定。

某项目在第一版为了省事，把全部功能部署在同一台物理机上，上线三个月后要拆环境，涉及域名、证书、数据库连接、定时任务调度全部重改，前后折腾了六周。这个返工成本在设计阶段就能避免。我的习惯是方案里先给出边界图和数据流向图，再写技术架构，评审时别人挑不出逻辑漏洞。

部署模式本身没有绝对优劣，核心是组织自身的运维能力和数据隔离需求是否匹配。人力不足的单位不一定非要微服务，单体应用按模块拆目录，配合数据库分库，也能达到后期拆分的目的。

2.2 参考拓扑：接入层、应用层、数据层三层分离

一套中等规模的电子政务 OA 系统，我一般建议按三层拓扑规划。接入层负责 SSL 终结、反向代理、限流和静态资源分离；应用层跑流程引擎、业务接口和定时任务；数据层放关系型数据库、缓存和对象存储。三层之间通过网络策略隔离，应用层只能访问数据层的指定端口，接入层只能访问应用层的 80/443 端口。

upstream oa_app_cluster { least_conn; server 10.10.20.11:8080 weight=5 max_fails=3 fail_timeout=30s; server 10.10.20.12:8080 weight=5 max_fails=3 fail_timeout=30s; } server { listen 443 ssl; server_name oa-internal.example.local; ssl_certificate /etc/nginx/certs/oa.crt; ssl_certificate_key /etc/nginx/certs/oa.key; client_max_body_size 200m; location /api/ { proxy_pass http://oa_app_cluster; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_read_timeout 120s; } location / { proxy_pass http://oa_app_cluster; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

这段配置里值得关注的参数有两个。least_conn让负载均衡按当前连接数分配请求，比默认轮询更适合 OA 这类“部分接口耗时长、部分接口秒回”的混合业务；max_fails=3 fail_timeout=30s表示节点在 30 秒内失败 3 次会被摘除，防止单节点假死时请求持续打到异常实例上。

client_max_body_size 200m是很多政务 OA 容易漏掉的参数。公文附件经常是几十兆的扫描件，默认 1m 的上限会让上传直接报 413。这个值要根据实际附件大小分布来定，我见过一个单位平均附件 40 兆，设置 100m 依然有用户传不进文件，最后统一提到 200m 才消停。

2.3 硬件与中间件参数：按真实并发数估算，不按“感觉”

硬件估算是最容易出玄学的地方。一套服务 500 名干部使用的 OA，按同时在线约 20%、活跃操作约 30% 计算，真实并发活跃用户大约 30 人，但登录瞬间和月底审批集中期会冲到 150 人以上。硬件配置不能按平均值给，要考虑峰值带宽。

中间件参数同样要写进方案。数据库连接池用 HikariCP 的常见配置里，maximum-pool-size建议设为数据库实例max_connections的 40% 左右，留出余量给管理端、备份任务和报表任务。Redis 端的maxmemory要设置真实上限，并开启allkeys-lru淘汰策略，否则缓存写满会直接触发内存溢出故障。

Tomcat 线程池容易踩坑。默认配置下线程上限往往偏低，而 OA 系统里经常出现“一个公文被退回后同时通知 30 个相关人”的消息风暴，线程池瞬间被打满。建议在方案里写明maxThreads初始值 200、minSpareThreads为 20，再按压测结果调整，不要写死。

3. 公文流转与审批流建模：把业务规则变成可维护的配置

3.1 公文对象建模：收文、发文、签报三类对象分开设计

很多建设方案的失误在于把“收文、发文、签报”塞进同一张业务表，靠类型字段区分。表面上省了表数量，实际运行时三类对象的字段差异极大：收文有来文单位、来文文号、密级，发文有签发领导、主送机关、抄送机关，签报则更接近内部请示。字段堆在同一张表里，大量列空置，索引效率低，查询逻辑里堆满if type ==分支。

我建议拆成三张主表，共享一张附件表和一张流程任务表。主表只放本类型特有的业务字段，通用字段如标题、拟办意见、当前状态统一放基础字段中。

CREATE TABLE doc_main ( doc_id VARCHAR(32) PRIMARY KEY COMMENT '公文ID', doc_type TINYINT NOT NULL COMMENT '1收文 2发文 3签报', title VARCHAR(255) NOT NULL, secret_level TINYINT DEFAULT 0 COMMENT '0公开 1内部 2秘密 3机密', state VARCHAR(32) NOT NULL COMMENT '当前状态机节点编码', creator_uid VARCHAR(32) NOT NULL, org_id VARCHAR(32) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_type_state (doc_type, state), KEY idx_org_time (org_id, created_at) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE wf_task ( task_id BIGINT PRIMARY KEY AUTO_INCREMENT, doc_id VARCHAR(32) NOT NULL, node_key VARCHAR(64) NOT NULL COMMENT '流程节点标识', assignee_uid VARCHAR(32) NULL COMMENT '处理人用户ID', assignee_dept VARCHAR(32) NULL COMMENT '处理部门编码', task_state TINYINT NOT NULL DEFAULT 0 COMMENT '0待办 1同意 2驳回 3转办 4撤回', received_at DATETIME NULL, finished_at DATETIME NULL, comment TEXT NULL, KEY idx_doc (doc_id), KEY idx_assignee_state (assignee_uid, task_state) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这两张表的设计逻辑是“文档数据”和“流转数据”分离。doc_main记录一份公文当前的事实状态，wf_task记录流转过程的每一个动作节点。后期做效能分析时，比如统计一个处室平均审批耗时，直接查wf_task按节点聚合即可，不需要回表查公文内容。

特别注意state字段不要用数字类型。线上流程节点经常要增删，如果用数字编码，每加一个节点就得重新定义数字含义。用字符串编码“register”“approve”“archive”后续可读性和可维护性都会好很多。

3.2 审批流引擎的配置：会签、或签、转办与退回拆开处理

流程引擎的配置化程度，直接决定后续版本迭代成本。一个成熟的方案会把审批流程写成结构化配置，而不是 Java 代码里的 if-else。常见的做法是定义一套流程 JSON，由引擎解析执行。

{ "processKey": "doc_receive_flow", "nodes": [ { "key": "start", "type": "start", "next": "register" }, { "key": "register", "type": "manual", "assigneeRole": "doc_admin", "next": "proposal" }, { "key": "proposal", "type": "manual", "assigneeRole": "office_director", "next": "leader_approve" }, { "key": "leader_approve", "type": "manual", "assigneeMethod": "pickByDeptLeader", "next": "countersign", "rejectTo": "proposal" }, { "key": "countersign", "type": "parallel", "assigneeDeptList": ["dept_a", "dept_b", "dept_c"], "mode": "all", "timeoutHours": 48, "next": "final_approve" }, { "key": "final_approve", "type": "manual", "assigneeRole": "deputy_head", "next": "archive", "rejectTo": "leader_approve" }, { "key": "archive", "type": "system", "action": "autoArchive", "end": true } ] }

这份配置里有两个必须理解清楚的点。rejectTo指退回目标节点，它可以退回上一级，也可以跨级退回，由流程管理员配置；mode: "all"表示会签所有人都同意才能进入下一节点，如果改成"any"就是或签，任一部门通过即可。

实际业务里，退回路径往往比审批路径更复杂。退回后修改完重新提交，是重新走全流程还是从退回节点继续？这个规则必须在配置层面约定清楚，并在引擎里固化。最常见的方案是：退回后修改重新提交，从退回节点开始重新流转，已通过的节点不再重复审批。

超时提醒也要在配置里体现。电子政务场景中，文件积压是常态，节点级超时策略按 24 小时、48 小时分档，生成待办催办消息。这个逻辑如果放在代码里硬编码，每次调整催办时间都要发版。

3.3 电子签章与附件生命周期：静态文件与流程动作分开存

附件管理是最容易被方案忽略、上线后问题最多的部分。常见错误是附件直接存应用服务器本地磁盘，路径写进数据库一个file_path字段。这个方案在单机时代勉强能用，一旦集群部署或多节点扩容，用户上传的文件落在 A 节点，访问请求转发到 B 节点就找不到文件。

正确的做法是引入对象存储组件，所有附件统一上传至对象存储，数据库只保存对象 key 和摘要信息。政务场景里还要考虑附件版本问题：同一份公文被修改后重新上传，旧版本不能直接覆盖，需要保存历史版本，保证审批链上看到的附件与当时审批时点一致。

电子签章的关键不在图片合成，而在完整性校验。每次签章动作建议生成一条签名记录，内容包括被签文件的摘要值、签章人、签章时间、证书序列号，并存入独立的审计表。后续核验时重新计算文件摘要，与记录比对，不一致即可判定文件被改动。

CREATE TABLE seal_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, doc_id VARCHAR(32) NOT NULL, file_key VARCHAR(128) NOT NULL COMMENT '对象存储中的文件标识', file_hash CHAR(64) NOT NULL COMMENT '文件SHA-256摘要', seal_uid VARCHAR(32) NOT NULL COMMENT '签章人', seal_time DATETIME NOT NULL, cert_sn VARCHAR(128) NOT NULL COMMENT '签章证书序列号', verify_state TINYINT DEFAULT 0 COMMENT '0未核验 1通过 2不通过' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

签章和公文主数据分离存储，将来做归档移交时，单独导出seal_log表和对象存储对应文件即可，不需要干扰线上业务表结构。

4. 数据迁移与统一身份对接：电子政务OA上线前的两大工程

4.1 历史数据迁移：结构化数据、文件数据、纸质档案三种处理方式

电子政务 OA 上线前，历史数据迁移往往是被低估的环节。旧系统里的结构化数据（已办结公文记录、人员信息、审批意见）相对好办，难的是非结构化文件和散落在个人电脑里的“事实上存根”。

结构化数据迁移的核心是字段映射和数据清洗。老系统的主键体系必须重建，否则业务表关联会跟着旧 ID 走。常用做法是写一个映射表，把旧 ID 和新 ID 的对应关系存下来，供关联查询使用。

文件类数据迁移最容易踩坑。旧系统附件路径五花八门：有的存在 FTP，有的在应用服务器本地目录，有的甚至带了绝对路径写进数据库。迁移时要先写脚本扫描所有路径，再按新规则重新命名放入对象存储，最后回填file_key字段。遗漏任何一个目录，都会造成“表单在、附件丢”的上线事故。

纸质档案不建议全量扫描上传。扫描一批 A4 文件，按单面 300dpi 估算，一份 20 页的档案生成约 40 兆图片，一个部门几百卷档案就是 TB 级存储。务实做法是只数字化近三年高频调阅的案卷，其余继续走线下档案室。

4.2 统一身份认证对接：单点登录与组织架构同步一起做

电子政务 OA 系统通常不是单位里的唯一系统，旁边往往还有邮件系统、会议系统、项目管理平台。如果每个系统各建一套账号密码，管理员光维护账号就要耗费大量精力，更麻烦的是人员入职离职后权限没有及时同步。

标准做法是接入单位已有的统一身份认证平台。如果组织还没有这个平台，实施 OA 时可以顺势建议建设单位侧的统一身份服务，把 LDAP 作为用户数据源，OA 通过 CAS 或 OIDC 协议对接。

<!-- Spring Security 配置片段示例 --> <security:http pattern="/cas/**" entry-point-ref="casEntryPoint"> <security:custom-filter position="CAS_FILTER" ref="casFilter"/> </security:http> <bean id="casFilter" class="org.springframework.security.cas.web.CasAuthenticationFilter"> <property name="serviceProperties" ref="serviceProperties"/> <property name="authenticationManager" ref="authenticationManager"/> </bean> <bean id="serviceProperties" class="org.springframework.security.cas.ServiceProperties"> <property name="service" value="https://oa-internal.example.local/login/cas"/> <property name="sendRenew" value="false"/> </bean>

这段配置对应 CAS 客户端接入方式。sendRenew=false表示不强制用户在认证服务器上重新输入密码，避免明明已经登录过 OA，跳转认证中心还要再输一次密码的体验。

组织架构同步比认证更让人头疼。单位内部部门调整频繁，人员借调、挂职、离退休都会影响权限分配。建议方案里明确每日凌晨全量同步一次部门树和人员状态，白天提供实时增量同步接口。同步内容包括职级、部门归属、岗位角色，这些字段直接影响后续流程节点的处理人解析。

4.3 割接当天的双轨运行与回退方案：不做回退计划就是拿生产开玩笑

割接上线不是“新系统上线，老系统关机”这么简单。政务场景里，一个审批环节可能横跨数周，上线当天仍有大量在途公文未办结，这些数据不能简单丢弃，也不能强制让用户在新系统重新走一遍。

双轨运行是常见做法。新系统上线后，老系统保留只读状态运行两周，用户可以查看历史数据和在途业务，新产生的审批一律在新系统办理。两周后领导确认在途业务已收敛，再关闭老系统写入口。

# 回退决策的触发条件 # 1. 新系统连续 30 分钟内登录失败率超过 20% # 2. 流程引擎出现节点丢失，且无法通过补数脚本恢复 # 3. 附件上传成功率低于 95%，且排障超过 2 小时 # 满足任一条件，启动回退流程，将数据库和文件回滚到割接前快照

回退方案的代价也不小，数据库回滚意味着双轨期间产生的新数据全部丢失。所以更稳妥的策略是保留老系统写权限直到新系统稳定运行一周，而不是直接切到只读。这个窗口期的确定，要由业务负责人和信息部门负责人共同签字确认，方案里要把这条决策链写清楚。

5. 电子政务OA建设避坑指南：从翻车现场提炼的五个教训

5.1 审批流逻辑硬编码在代码里，业务规则一变就要发版

现象：系统上线两个月后，单位调整了领导审批权限，“副职先批、正职后批”变成“正职先批”，实施方修改代码、重新打包、申请窗口重启，前后用了三天，期间所有审批单暂停办理。单位领导质疑系统灵活性，项目验收被搁置。

原因：流程引擎在设计阶段没有配置化，“审批人如何确定”“退回走哪条路径”这类规则直接写在 Java 业务代码里。代码逻辑没问题，但规则一变就要动代码，改完还要回归测试。

解决：流程定义全部外置为配置数据，业务人员可维护审批节点顺序和退回路径，开发只负责引擎本身。后续规则调整时，流程管理员在后台改配置并发布新版本流程即可，应用无需重启。这条在建设方案里应明确写成架构约束，而不是口头建议。

5.2 附件散落在应用服务器磁盘，扩容时文件“消失了”

现象：系统从单机迁移到双节点集群后，用户反映历史公文的附件有一部分打不开。排查发现上传请求经负载均衡分到了不同的应用节点，文件只落在了处理请求的那台服务器本地，另一台节点上查无此文件。

原因：初版方案为了快速上线，附件直接写入服务器本地目录，没有引入统一对象存储。单机阶段没暴露问题，一旦水平扩展，文件访问路径随即断裂。

解决：附件统一迁移到对象存储服务，应用节点只保留上传下载的临时目录。数据库附件字段从本地路径改造为对象 key，并在迁移校验时比对本地文件数量与对象存储数量，确保全部搬运完成。改造顺序应该是先迁移文件，再改应用读写逻辑，最后切流量。

5.3 权限模型只做了功能权限，漏掉了数据权限

现象：某处室工作人员登录后，通过搜索功能可以查出其他处室合同审批的正文内容。功能菜单已经做了权限控制，但数据行权限完全没有过滤。

原因：菜单权限只控制“能不能进入这个功能模块”，数据权限控制“进入之后能看到哪些数据”。在 OA 场景里，数据权限通常按组织维度划分：本人数据、本部门数据、本分管领域数据、全单位数据。方案设计时漏掉了后者，等于只上了一道锁。

解决：所有业务表查询入口强制携带数据权限条件，后台通过 AOP 统一拦截，根据当前用户角色动态拼接部门过滤条件。敏感字段再加密存储，查询接口对无权限用户不返回字段内容，避免通过接口越权读取。

5.4 移动端把 PC 网页直接缩放来用，领导体验极差

现象：单位领导在手机上点开待办审批，页面整体缩小，文字挤成一线，想点“同意”按钮先要把页面放大，再滑动寻找按钮位置。多次误触后领导放弃使用手机端，待办积压问题依旧没有解决。

原因：移动端适配做成了响应式缩放，PC 页面模板原样渲染，没有按移动场景重构。OA 移动端的核心诉求非常聚焦：快速查看待办、处理审批、查看附件、转办。功能列表要比 PC 端短得多，交互要按单手操作设计。

解决：单独开发移动端页面，以“待办列表——审批详情——同意/驳回”为主链路由。附件在线预览优先加载 PDF 转换版本，而不是让用户下载原文件到手机再打开。后续增加语音转文字填写意见，能显著提升领导侧的接受度。

5.5 会话管理和线程池未做峰值验证，登录高峰直接卡死

现象：上线第一天早上 8 点，全员同时登录系统，出现页面白屏、登录请求超时，部分用户登录成功后操作又报 500。信息部门临时重启应用，恢复十分钟后再次拥堵。

原因：应用服务器默认线程池上限太低，数据库连接池配置偏小，会话数据放在应用本地内存导致负载均衡节点间“掉线”。集中登录时新建会话请求并发进来，线程池和连接池同时打满，整个系统进入假死状态。

解决：上线前做并发压测，模拟全员登录峰值。至少调整三个参数：应用线程池上限调至 200 并预留扩展空间；数据库连接池按活跃用户比例调整；会话集中存储到 Redis，让任一应用节点都能接续已登录用户状态。压测通过后再割接。

6. 上线后的压测验收与抽查方法：让建设方案经得起业务验证

6.1 压测验收：登录、审批、附件下载三个链路分别定指标

验收不能只测接口通不通，要按业务链路分开压。普通 OA 的三大热点链路是登录认证、审批单提交、附件下载。登录链路阻塞影响所有用户；审批提交涉及流程引擎节点流转，最吃线程池；附件下载则直接考验带宽和对象存储吞吐。

# 登录链路压测示例 wrk -t8 -c200 -d120s --latency --script=auth.lua \ https://oa-internal.example.local/api/login

常见验收标准是：200 并发下登录接口 TPS 不低于 100，P99 延迟小于 2 秒，错误率为 0；审批提交接口 TPS 不低于 50，且流程状态流转无丢失；附件下载在 50 并发下单文件平均耗时小于 3 秒。压测结果要和方案里的参数预估做对照，偏差超过 30% 就要排查瓶颈。

6.2 数据一致性抽查：迁移验收不能只看“总数对得上”

数据迁移的验收，很多项目只看“行数一致”就宣布完成，这是典型的自欺欺人。行数一致只能证明记录数量相同，字段级内容是否完整、业务状态是否能延续，需要分层校验。

第一层核对行数与主键唯一性，第二层抽样比对关键字段值，第三层按业务规则逻辑校验，比如“已办结的公文中行政发文必须有最终签发领导字段”。抽查样本量建议不低于总量的 2%，并且要刻意覆盖边界数据：最早期数据、含特殊字符数据、附件缺失数据。

6.3 发布后的观察期习惯：前两周每天看一次这个数

系统上线后的前两周，我养成了一个习惯：每天早上去数据库查一次待办积压最深的三个流程节点。这个数据远比“用户登录数”更能反映系统真实运行状态——流程节点积压往往意味着审批人没收到待办、通知组件出问题或节点路由配置方向错了。

-- 统计当前未完成审批单的数量分布 SELECT node_key, COUNT(*) AS pending_cnt FROM wf_task WHERE task_state = 0 GROUP BY node_key ORDER BY pending_cnt DESC LIMIT 10;

这个查询每天执行一次，连续两周。如果某一节点积压数据持续上涨，说明该节点的处理人解析规则有问题，或者通知消息没发出去。通过这个习惯，我先后在三个不同项目里提前发现了流程引擎配置问题，避开了“领导追问为什么文件还没批下来”的尴尬处境。

回看这些年做过的电子政务 OA 建设方案，真正让项目成功的往往不是高深的算法或华丽的前端，而是那些在架构图上很容易被忽略的细节：附件存哪里、流程规则怎么改、历史数据怎么迁、并发到达时系统会不会崩。把这些细节在方案阶段就钉死，实施过程会顺畅得多。希望这篇笔记里的做法能帮你少走一段弯路。

本文还有配套的精品资源，点击获取