# 方案计划文档管理系统技术方案 > 文档版本：v1.0 > 编制日期：2026-08-12 > 密级：内部 > 适用范围：方案计划文档管理系统（DMS）研制与交付 --- ## 1. 研制背景 方案计划类文档（含主方案、子方案、配套资料）历来是各级单位的核心知识资产，其内容不仅承载具体业务决策与战术技术安排，往往还涉及组织层级、人员编组、装备资源、保密要求等敏感信息。长期以来，这类文档主要依赖办公自动化系统、共享目录或单机档案柜进行管理，普遍存在三类突出问题。其一，存储分散、版本混乱：同一份方案在不同人员、不同终端、不同时期存在多个副本，难以及时定位“现行有效版本”，更难以追溯变更过程。其二，权限粗放、密级管控薄弱：传统基于目录或共享权限的管理模型只能做组织级粒度的访问控制，无法针对单份文档、单一主体、单一操作（查看、下载、编辑、删除、授权）进行细粒度授权，更无法与文档密级、用户密级联合判断，存在敏感信息越权扩散风险。其三，检索能力低下：大部分系统仅能按文件名或关键字匹配，无法对正文内容、概述、标签进行联合检索，无法基于语义进行智能匹配，更无法在命中正文时给出上下文片段，导致“明明有却搜不到”的现象频发。 随着各级单位对信息化、智能化办公能力提出更高要求，方案计划类文档的“集中存储、分类组织、密级管控、细粒度授权、智能检索、在线预览、操作审计”已经成为基础能力而非加分项。同时，方案类文档经常以PDF、DOC、DOCX三种主要格式流转，且军事场景下整个系统运行在严格物理隔离的专用网络中，所有能力必须完全依托本地资源完成，必须依靠本地化的转换与渲染链路完成预览与正文提取，必须依靠本地化的分片与向量化链路完成智能检索与语义匹配。这就要求新系统在功能完备的同时，具备可离线、低依赖、适配国产化平台、支持多机集群部署的形态，能够在银河麒麟操作系统下以服务器集群方式部署运行，服务于机关与一线分队的协同办公。 基于上述背景，本项目立项研制“方案计划文档管理系统”（下称“本系统”），面向各级军事机关、部队及野外作业分队等场景，提供一套完整的方案文档全生命周期管理平台。系统以“主方案—子方案—配套资料”三类对象为核心业务实体，以分类树、标签、密级为检索与管控主轴，以“令牌时效与会话版本联动失效”机制和“基于访问控制列表的细粒度授权”为安全底座，以离线文档转换引擎与可切换的前端预览渲染器为内容呈现保障，以文档分片、向量化与多字段合并检索为知识挖掘能力，以多机集群部署与主备热备为可靠运行形态，最终为各级用装单位提供一套“集群部署、管控到位、追溯清晰、智能检索”的方案文档管理工具。 ## 2. 指导思想 本系统的研制遵循“安全为先、可用为本、可审计、可离线、可演进”五项核心指导思想，所有架构决策、技术选型与实现取舍均围绕这五条主线展开。 **安全为先**意味着所有与权限、密级、文件读写相关的判定必须由服务端做出且仅由服务端做出，前端只承担呈现与请求发起职责，不允许将任何权限标识、密级判断、操作开关作为可信任输入回传至后端。系统在鉴权链条上严格遵循“登录态校验 → 用户有效性 → 文档有效性 → 密级比对 → 系统管理员特权 → 可见范围 → 操作权限”七级判定，前一级未通过即整体拒绝，不进入下一级。所有写操作必须携带乐观锁版本号，所有敏感操作必须留下与业务事务原子提交的审计记录，所有错误响应必须避免泄露绝对路径、文件摘要、SQL文本、堆栈信息等内部细节。 **可用为本**意味着系统面向真实指挥办公场景设计，而非面向演示或招标。系统必须支持PDF、DOC、DOCX三类主流格式的在线预览，且在严格物理隔离的专用网络中能通过本地转换引擎完成格式转换；必须支持基于关键字的多字段合并检索与基于向量化的语义检索，并在命中正文时给出上下文片段；必须支持基于“主方案—子方案—配套资料”三档业务对象的层级浏览、基于分类树的导航浏览、基于标签多选OR的过滤浏览；必须支持左右分栏的查看对话框，让用户在查看预览的同时阅读提取出的正文段落；必须支持银河麒麟服务器上的多机集群部署，由机关普通用户通过浏览器访问即可开展日常办公。 **可审计**意味着系统中发生的每一次有意义的行为——登录、登出、查看、下载、上传、编辑、删除、权限变更、挂载、解绑、恢复——都必须留下不可篡改、不可删除、可追溯的审计记录，且审计记录与业务变更必须在同一事务中原子提交，避免“业务成功但审计丢失”。审计日志需保留操作发生时的快照（用户名、真实姓名、组织名、目标名称），即便用户改名、组织调整或文档删除，历史日志仍然可读、可解释。 **可离线**意味着系统在严格物理隔离的专用网络中也能完整运行。系统不依赖任何在线Office服务、在线PDF渲染服务、外部认证服务、在线大模型服务，所有能力均在专用网络内部完成：文档转换、正文提取、分片与向量化、检索匹配均依托本地资源完成。系统采用集群部署形态，前端构建产物、后端服务、向量化服务、数据库主备、数据备份均运行于专用网络内的服务器集群之上，便于在专用网络内统一部署、运维与升级。 **可演进**意味着系统在功能边界、数据模型、技术栈三个维度均预留扩展空间。功能上，正文检索已具备关键字多字段合并与向量化语义匹配两条链路，数据规模增长后可平滑切换到专用全文检索引擎或专用向量数据库；数据模型上，为后续批量导入、跨库federate等高级能力保留扩展空间；技术栈上，采用主流且长期维护的开源框架，避免引入小众或停止维护的依赖。系统采用分层与模块化设计，新功能的引入以新增模块、新增迁移、新增路由为主，尽量避免对既有业务模型的破坏性改造。 除上述五条指导思想外，研制过程还遵循若干工程纪律：所有对外接口遵循统一响应结构（业务状态码、消息、业务负载、请求追踪标识），前端不得仅依赖HTTP状态判断业务成功；所有写接口必须支持并发冲突识别（乐观锁）；所有数据库迁移脚本按版本号线性递增且不允许修改历史迁移；所有时间字段以毫秒精度存储协调世界时（UTC）、对外以ISO 8601标准格式呈现；所有数据库字符集统一为支持完整Unicode的字符集，存储引擎统一为支持事务与外键的主流引擎。这些工程纪律是指导思想在代码层面的具体落地，构成了系统质量与可维护性的基础。 --- ## 3. 方案设计 ### 3.1系统结构及组成 本系统在逻辑上采用“前端展现层、后端业务层、数据存储层、智能检索与向量化服务”四层粗粒度结构。前端展现层负责交互呈现、表单校验与请求编排，由浏览器加载的单页应用承担；后端业务层负责业务逻辑、权限判定、文件读写、文档转换与正文提取，由无状态的应用服务承担；数据存储层负责结构化业务数据与原始文件的可靠存储，由关系型数据库主备集群与本地文件存储共同承担；智能检索与向量化服务作为独立部署的辅助服务，承担文档分片、向量化计算与语义匹配能力，供应用服务按主备方式调用。各层之间通过明确的边界解耦：前端只通过加密通道调用后端业务层的应用接口，不直接访问数据库与文件目录；后端业务层通过受控的数据访问层操作数据库，通过受控的存储抽象读写文件目录，通过受控的客户端调用向量化服务；数据库主备集群对应用服务暴露统一的数据源，应用服务无需感知主备切换细节。 在物理部署形态上，本系统采用5台服务器的集群部署方案，全部运行于严格物理隔离的专用网络内的银河麒麟服务器之上。第一台部署应用服务包、向量化服务（主）、负载均衡器（主），其中应用服务包内置数据备份功能，按计划将本机数据备份至第三台；第二台部署应用服务包、向量化服务（备）、负载均衡器（备），应用服务包同样内置数据备份功能，按计划将本机数据备份至第三台；第三台部署应用服务包，同时作为第一台与第二台数据备份的目标设备，集中存储备份文件；第四台部署数据库主库；第五台部署数据库备库。该部署形态的核心要点如下：其一，第一、二、三台组成无状态的应用服务集群，三台机器上运行的应用服务包完全同构、对外提供并行访问能力，任一节点故障不影响整体可用；其二，第一台作为主负载均衡器、是日常服务访问入口，为防止单点故障，第二台部署备用负载均衡器作为备用访问入口，主负载均衡器故障时用户浏览器需切换IP至第二台继续访问；其三，第一台部署主向量化服务，所有应用服务节点调用该服务完成文档向量化，为防止第一台故障，第二台部署备用向量化服务，各应用服务节点在配置中同时登记主备向量化服务地址，主向量化服务不可达时自动切换至备用；其四，第三台作为集中备份目标，是防止两台数据库同时损坏的第三重保险，备份策略遵循“3-2-1”原则——至少3份副本、至少2种存储介质、至少1份异地副本，按每周日凌晨执行全量备份、每日凌晨执行增量备份的节奏生成，备份目录以只追加不覆盖方式写入，防止应用层数据被误删或恶意删除后波及备份本身；其五，第四、五台组成数据库主备集群，采用热备方式、同步双写，主库故障时可在系统管理员审批与主备切换脚本配合下切换至备库继续提供服务。 在逻辑分层上，后端应用服务内部进一步划分为“接入层（应用层接口）— 业务层（领域服务）— 数据层（实体模型与持久化）— 基础设施层（存储抽象、转换抽象、安全上下文）— 横切层（响应封装、分页、错误码、时间范围、请求上下文）”五个子层。接入层只负责接收请求、校验入参格式、调用业务层、组装响应，不直接访问数据库；业务层承载所有“在某一业务动作中需要发生的事”，例如“创建一份主方案”涉及到的字段校验、文件落盘、摘要计算、密级比对、权限初始化、审计写入、正文提取、分片与向量化、索引更新等所有步骤均被聚合到一个服务方法中，且该方法在数据库事务内原子提交；数据层定义了用户、组织、分类、文档、配套资料挂载关系、权限、审计日志、文档分片、文档向量等核心实体表以及若干辅助表，所有外键约束、唯一约束、检查约束、索引均在模型层显式声明；基础设施层封装了文件命名策略、目录布局、摘要缓存、外部转换引擎调用方式、向量化服务调用方式、令牌签发与校验等“与外部资源或加密算法交互”的细节；横切层提供了响应包装器、分页协议、错误码映射、时间范围解析、操作枚举等被多业务复用的工具类。这种分层使得“新增一个业务实体”的成本被控制在“新增一个模型、新增一个迁移、新增一个服务、新增一组路由”的可预期工作量内，不会侵入既有模块。 在组成清单上，本系统交付的软件资产包括：后端业务与基础设施源码、前端源码（按业务特性划分为若干特性模块）、数据库迁移脚本（按版本号线性递增）、前端构建产物、PDF预览渲染器（嵌入前端构建产物）、向量化服务源码与部署包、集群部署与运维脚本（数据库初始化、正文回填、向量回填、备份执行、主备切换）、以及本技术方案文档与配套的用户手册。所有组件的版本、来源、修改记录均在配置管理与版本控制中留痕，可追溯、可复现。 ### 3.2工作原理 系统的工作原理可以从“请求-响应主链路”、“鉴权判定链”、“文件存储与预览链路”、“正文提取与向量化链路”、“检索匹配链路”五条主线分别说明，这五条主线共同覆盖了系统日常运行中绝大多数有意义的内部行为。 请求-响应主链路描述了一次典型的“用户在前端发起一次操作 → 负载均衡器分发 → 后端应用服务完成处理 → 前端展示结果”的全过程。用户在浏览器中登录后，前端拿到一段访问令牌与一段“保持登录”长效令牌，将访问令牌缓存在内存中（不写入本地存储或Cookie，防止XSS与CSRF携带），并在后续每一次调用后端接口时通过鉴权头部经负载均衡器发送至应用服务集群中的某一节点。后端在请求预处理阶段拦截该头部，解码还原出“用户标识+用户密级+组织标识+角色集合+会话版本号”，并将这些信息注入到当前请求上下文中，供下游业务方法直接读取而无需重复解码。业务方法在被调用时，先从请求上下文中取出当前用户，再执行业务逻辑、读写数据库主库、写审计记录，最后通过响应包装器返回统一结构的响应。前端在收到响应后，先校验业务状态字段是否表示成功，再读取业务负载渲染界面；遇到失败响应时，前端根据错误码与消息决定是提示用户、跳转登录、还是触发乐观锁冲突的二次确认流程。 鉴权判定链是本系统安全设计的核心，所有受保护资源在被访问前都必须完整通过七级判定，前一级未通过即整体拒绝，不进入下一级。第一级是登录态校验：访问令牌必须存在、必须未被篡改、必须未过期；第二级是用户有效性：用户记录必须存在、未被逻辑禁用、会话版本号必须与令牌中的版本号一致（一旦系统管理员强制下线或修改了用户的密级或角色，该用户的令牌立即失效）；第三级是文档有效性：被访问的文档记录必须存在、未被销毁；第四级是密级比对：用户的密级必须大于或等于文档的密级，例如“秘密级用户”不能查看“机密级文档”；第五级是系统管理员特权：如果当前用户是系统管理员，则直接放行，不再走后续的可见范围与操作权限判定，以便系统管理员进行全局运维；第六级是可见范围判定：根据文档的可见范围类型（“全员可见”、“按组织”、“按用户”三类），判断当前用户是否在允许集合内；第七级是操作权限判定：根据该用户或其所在组织对该文档的访问控制授权记录，判断是否具有本次操作所必需的具体权限（查看、下载、编辑、删除、授权）。这七级判定全部在后端应用服务内完成，前端不参与任何判定，也不持有任何判定结果作为可信任输入。 文件存储与预览链路描述了一份上传件从落地到可被在线预览的全部内部行为。用户在前端选择一份本地文件并提交上传时，前端在单次表单请求中同时携带文件本体与元数据（标题、密级、分类、可见范围、标签等）提交至后端。后端在落盘的同时计算文件摘要，并以此摘要为键查询预览缓存，如果命中缓存且缓存对应的PDF仍存在，则直接复用缓存的PDF，避免重复转换；如果未命中，则按需触发转换：对于PDF，原文件即为预览源；对于DOCX，先尝试用文档解析库提取正文，同时调用外部转换引擎将其转换为PDF；对于DOC，必须经过外部转换引擎转换为PDF后才能预览。转换完成后，预览PDF的相对路径被写入预览缓存，下次同一份文件再次上传或被其他文档引用时直接命中缓存。前端在收到预览响应后，根据系统预置的策略选择深度渲染器或浏览器原生嵌入两种方式之一。 正文提取与向量化链路是系统知识挖掘能力的核心，覆盖“上传时提取、分片与向量化、存量回填”三个阶段。在上传时，系统根据文件类型分别采用不同的正文提取路径：对PDF直接调用文档解析库，对DOCX调用结构化文档解析库，对DOC则先经过外部转换引擎转为PDF后再调用文档解析库；提取出的文本被去空白、按段落归一化、写入文档记录的正文存储字段，同时被裁剪拼接为更短的检索专用字段以支撑关键字模糊匹配检索。随后系统按固定字数与段落边界对正文进行分片，将每片文本连同文档标识、片序号、所属段落范围写入文档分片表；接着将每片文本送至向量化服务，得到该片文本的向量表示，连同片标识一并写入文档向量表。在存量回填阶段，运维人员通过系统提供的回填工具对历史已上传但尚未提取正文、尚未生成向量的文档批量重跑提取与向量化流程，使旧数据也具备智能检索能力。 检索匹配链路覆盖“用户发起检索 → 双路召回 → 合并排序 → 命中呈现”四个阶段。用户在前端输入关键词或自然语言问句后，后端启动双路召回：第一路是关键字多字段合并检索，在检索专用字段上执行模糊匹配查询，同时联合主方案、子方案、配套资料三档对象的标题、概述、标签字段做多字段合并检索；第二路是语义检索，先将用户的问句送至向量化服务得到查询向量，再在文档向量表上按相似度检索出Top-N片文本，按所属文档聚合得到候选文档集合。两路结果按既定权重合并、去重、排序后分页返回。命中正文时，后端进一步在正文存储字段中定位关键词或匹配片段首次出现的位置，截取前后各若干字符作为上下文片段返回给前端。前端在表格行的下方延展一行“正文”片段，使用高亮组件把关键词在片段中可视化标红，让用户在不打开文件的情况下就能判断这是否就是他要找的内容。 ### 3.3软件组成及设计 本系统的软件按业务功能域划分为“方案管理、分类与标签管理、部门与用户管理、权限管理、日志审计、安全保密”六个一级功能模块，外加支撑六个业务模块运行的“基础设施与运维脚本”以及前端展现层。每个功能模块由“接入层路由、领域服务、数据层模型、基础设施依赖”四部分构成，模块之间通过领域服务显式调用、不共享数据层细节，遵循“先校验、再判定权限、再执行业务、再写审计、最后提交事务”的固定顺序，确保业务与审计的原子性。 方案管理模块是系统的核心，承担主方案、子方案、配套资料三类业务对象的增删改查与向量化能力。增删改查方面，模块提供“创建主方案、创建子方案、创建配套资料、查询列表、查询详情、更新元数据、更新文件、挂载子方案、挂载配套资料、解绑子方案、解绑配套资料、销毁文档”等接口，所有写操作均在数据库事务内原子完成“字段校验、密级合法性校验、文件落盘、摘要计算、预览生成、正文提取、审计写入”等步骤。向量化方面，模块在文档创建与更新后异步触发“正文分片、调用向量化服务、写入文档分片表与文档向量表”流程，使每一份新入库或新修订的文档在数秒内即具备语义检索能力。模块还提供“按主方案聚合查询其全部子方案与配套资料”的层级查询接口，供前端在主方案详情页一站式展示。 分类与标签管理模块承担分类树与标签字典的全生命周期管理。分类树采用“自引用父节点”的邻接表模型存储，模块提供“新增分类、移动分类、删除分类、级联查询子树、按分类导航浏览”等接口，并对“父节点与名称”建立了唯一约束防止同名分类并列，对“父节点链路”进行循环引用校验防止环路。标签字典为系统提供一份统一的标签清单，模块提供“新增标签、删除标签、按标签多选OR过滤浏览、按标签聚合统计”等接口，标签作为分类树之外的轻量补充维度，方便普通用户按任务属性快速过滤文档。 部门与用户管理模块承担组织树与用户记录的全生命周期管理。组织树同样采用邻接表模型存储，模块提供“新增组织、移动组织、删除组织、级联查询子树”等接口。用户记录承载账号、密码哈希、密级、组织归属、状态、会话版本号等字段，模块提供“新增用户、修改用户、启停用户、重置密码、强制下线、修改密级、修改角色”等接口。其中“会话版本号”是会话失效机制的关键，每次对用户执行强制下线、修改密级、修改角色等敏感操作时该值自增，使该用户已签发的所有令牌立即失效。 权限管理模块承担基于访问控制列表的细粒度授权能力。模块提供“按文档查询已授权主体、按主体查询已授权文档、授予查看/下载/编辑/删除/授权五类权限的任意组合、撤销授权”等接口，每条授权记录以“主体类型、主体标识、文档标识、五个权限位标记”的形式存储，并对该四元组建立唯一约束防止重复授权。模块还提供“是否允许某主体对某文档执行某操作”的判定接口，供鉴权判定链的第七级调用；判定时先查“主体直接持有的授权”、再查“主体所在组织持有的授权”，将两者的并集作为最终权限集合。 日志审计模块承担所有有意义操作的不可篡改记录。模块对外提供“按时间范围、操作类型、操作人、目标对象类型等多维度组合筛选审计记录、按条件导出审计报表”等查询接口，对内提供“审计写入”接口供其他业务模块在事务内调用。每条审计记录包含操作类型、操作时间（毫秒精度）、操作人标识/用户名/真实姓名、操作人所在组织名、目标对象类型/标识/名称、操作前后快照（部分敏感操作）、来源IP、请求追踪标识等字段。审计记录一旦写入即不可修改、不可删除，仅在系统执行文档销毁等极少数情况下随销毁流程写入一条不可逆的“销毁”记录。 安全保密模块承担身份认证、会话管理、密级管控、传输加密、存储隔离、敏感信息收敛等横切性安全能力，是其他五个业务模块的安全底座。身份认证采用密码加令牌的双因子机制，密码经Argon2id哈希存储，登录后签发访问令牌与“保持登录”长效令牌；会话管理通过“会话版本号”实现令牌主动失效；密级管控对每一份文档与每一个用户赋予密级属性，鉴权判定链的第四级强制执行密级比对；传输加密在生产部署中强制启用加密通道；存储隔离对原始文件、预览缓存、日志、数据库文件按物理目录隔离；敏感信息收敛对所有可能泄露内部细节的对外响应统一脱敏。 数据层是上述六个功能模块共同依赖的持久化基础，定义了用户、组织、分类、文档、文档分片、文档向量、配套资料挂载关系、权限、审计日志等核心实体表。文档表是系统的核心实体表，承载主方案与子方案两类业务对象，通过文档类型字段区分，同时承载可见范围类型、可见范围数据、密级、分类归属、父方案指向、根方案指向、原始文件名、存储相对路径、文件扩展名、文件大小、文件摘要、正文内容、检索专用文本、概述、标签、文档状态、版本号、创建人、创建时间、更新时间等业务字段。文档分片表与文档向量表是支撑智能检索的两张辅助表，分别记录“每片文本的所属文档、片序号、文本内容”与“每片文本的向量表示”。所有表均使用主流存储引擎与支持完整Unicode的字符集，所有时间字段统一以毫秒精度存储协调世界时（UTC），所有外键约束显式声明级联策略。 前端展现层采用主流的构建工具与组件框架，配合TypeScript与Tailwind CSS v4等技术，按“特性模块化”组织代码，特性目录按上述六个业务功能域同构划分，分别承担文件预览、文档检索、新建编辑、挂载关系、权限管理、审计看板等界面。全局布局目录承载登录态管理、路由分发、顶部导航与全局通知；通用能力目录承载API客户端、统一响应解析、乐观锁冲突识别、错误码映射、高亮渲染组件、向量检索结果展示组件等横切能力。所有API调用统一通过API客户端发起，API客户端在内部完成“附带鉴权头部 → 检查响应结构 → 检查业务状态 → 自动刷新过期令牌 → 转换为前端业务异常”五步流程，业务层调用方只需关心成功后的业务负载与失败后的异常，不必处理底层细节。 软件组成上的另一条主线是“基础设施与运维脚本”。系统附带若干运维脚本：示例数据脚本用于在初次部署时生成示例组织、用户、分类与文档，便于现场快速演示；分类与文档批量导入脚本用于按预置清单批量导入分类与文档；正文回填脚本用于对历史已上传但未提取正文的文档批量重跑提取流程；向量回填脚本用于对历史已上传但尚未生成向量的文档批量重跑分片与向量化流程；备份执行脚本用于在第三台备份服务器上按“3-2-1”原则与只追加不覆盖规则执行每周全量与每日增量备份；主备切换脚本用于在故障情况下完成应用服务、向量化服务、数据库主备之间的受控切换，切换前自动校验审计哈希链完整性。这些脚本配合集群部署方案使用，构成“集群部署、存量可补、故障可切、误删可复”的运维能力闭环。 ### 3.4接口及协议 本系统所有对外接口均以REST风格组织，请求与响应统一使用JSON编码，字符集统一为UTF-8。所有接口遵循“统一响应结构、统一错误码、统一分页协议、统一时间格式、统一鉴权头部”五项约定，前端由此获得一致的错误处理、加载态、重试策略与刷新策略，不必为每个接口单独编写防御性代码。 统一响应结构由响应包装器统一生成。成功响应包含业务状态、消息、业务负载、请求追踪标识四个字段，业务状态以约定的成功标识字符串表示操作成功、消息为人类可读的中文提示、业务负载承载具体数据、请求追踪标识为每次请求的唯一标识（同时被写入审计日志，便于前后端联调与问题追溯）。失败响应包含业务状态、消息、错误细节三个字段，业务状态以业务域命名的错误标识字符串表示（例如“参数无效”、“令牌失效”、“密级不足”、“权限不足”、“资源不存在”等），消息为人类可读的中文提示，错误细节为可选的附加说明（例如字段级校验错误清单）。HTTP状态码仅反映“传输层与应用层握手是否成功”，业务成败完全由响应体内的业务状态决定，前端在任何情况下都必须先读取业务状态字段、不得仅依赖HTTP状态判断业务成功。 统一错误码按业务域命名，覆盖通用错误、鉴权错误、权限错误、业务冲突、资源不存在、外部依赖错误等类别。通用错误包含参数缺失、参数格式错误、请求体解析失败等；鉴权错误包含未登录、令牌过期、令牌无效、会话版本不一致等；权限错误包含无操作权限、密级不足、不在可见范围等；业务冲突包含乐观锁冲突、唯一约束冲突、状态机非法迁移等；资源不存在包含用户、组织、分类、文档、配套资料、权限记录不存在等；外部依赖错误包含文件读写失败、转换失败、摘要计算失败等。每个错误码对应一条标准化的中文消息，前端在收到失败响应时可以根据错误码决定是显示友好提示、跳转登录、触发二次确认还是直接抛出。 统一分页协议规定：所有列表型接口接受页码（从1开始）与每页条数（默认值与上限由系统约定）两个查询参数，响应中的业务负载统一为“记录列表、总数、当前页、每页条数、总页数”五个字段。前端由此可以直接复用同一份分页组件，无需为不同接口编写适配器。 统一时间格式规定：所有时间字段在数据库中以毫秒精度存储协调世界时（UTC），在对外响应中以ISO 8601标准格式呈现（如“年-月-日T时:分:秒.毫秒Z”形式，末尾Z后缀代表协调世界时），在前端展示时由前端按用户本地时区格式化。这种“数据库UTC、接口UTC、前端本地化”的三段式策略保证了多终端、多时区场景下时间的一致性，避免了“服务器时间与客户端时间不一致”导致的审计歧义。 统一鉴权头部规定：除健康检查、登录等少数无登录态要求的接口外，所有接口必须携带鉴权头部，头部中携带登录后获得的访问令牌；后端在校验失败时返回鉴权类错误码，前端收到鉴权类错误码后自动触发令牌刷新流程，刷新失败时跳转登录页。前端将访问令牌缓存在内存变量中（页面刷新即丢失），长效令牌以HttpOnly且SameSite严格的Cookie形式下发，避免被JavaScript读取，从而同时抵御XSS与CSRF。 在写操作上，系统统一引入“乐观锁”机制。乐观锁要求所有写操作在请求体中携带当前记录的版本号，后端在执行更新时附加“版本号必须与当前持久化版本号一致”的条件，若影响行数为零则返回乐观锁冲突错误码，前端弹出“该数据已被他人修改，是否刷新后重试”的二次确认。这一机制保障了“在不引入分布式锁的前提下，多用户并发操作同一份数据时的正确性”。 在文件上传与下载协议上，系统采用“单次表单提交、流式下载”的策略。上传时前端在一次表单请求中同时携带文件本体与元数据（标题、密级、分类、可见范围、标签等），后端在事务内完成文件落盘、摘要计算、预览生成、正文提取、审计写入、记录创建等步骤，事务提交后异步触发分片与向量化流程，最终返回新建文档的标识。下载统一通过下载接口触发，后端设置正确的响应头与媒体类型，并以流式响应返回，避免大文件全量加载进内存。在线预览统一通过预览接口触发，后端返回预览源的相对路径与版本号，前端按系统预置的策略选择深度渲染器或浏览器原生嵌入两种方式之一。 在检索接口协议上，系统提供关键字检索与语义检索两类接口，并支持合并调用。关键字检索接口接收关键词、分类、密级、时间范围、标签、页码等查询参数，按多字段模糊匹配合并检索；语义检索接口接收自然语言问句、过滤条件、Top-N等参数，后端先将问句送至向量化服务得到查询向量，再在文档向量表上按相似度检索出候选文档集合；合并检索接口接收上述两类参数并按既定权重合并排序后分页返回。三类接口的响应结构除常规分页字段外，还在每条命中记录上附带“正文片段”字段，承载关键词或匹配片段在正文中的上下文片段，供前端在高亮组件中可视化呈现。 --- ## 4. 使用流程设计 系统的使用流程围绕“普通用户、系统管理员”两类典型角色，以及“主方案、子方案、配套资料”三类业务对象展开，覆盖从首次部署到日常运行的全生命周期。普通用户承担方案文档的日常创建、上传、检索、查看、下载与挂载等业务操作；系统管理员在承担上述业务操作之外，还负责组织树建模、用户与密级管理、分类与标签字典初始化、权限授予、审计看板监督以及各类运维管理操作。整个使用流程在设计上遵循“日常操作高频简单、敏感操作低频可控、所有操作可追溯”的原则，使得非技术用户可以在五分钟内学会日常使用，而系统管理员则可以通过细粒度授权与审计看板对全员行为进行有效监督。 系统初始化阶段由系统管理员或部署工程师完成。部署工程师按集群部署方案在五台银河麒麟服务器上分别完成数据库主备、应用服务、向量化服务、负载均衡器的部署与启动，将主负载均衡器的访问IP下发给全体用户；系统启动后自动完成数据库主备同步初始化、初始迁移、根分类与初始系统管理员的创建，并向前端返回登录页。系统管理员使用初始账号登录后，第一时间修改密码并完善个人密级，随后依次完成“组织树建模、用户录入与密级分配、分类树建模、标签字典初始化、示例数据清理”五项准备工作。组织树建模按“战区、部队、分队”或“单位、部门、科室”的层级逐级录入，每一级组织可以挂载多个用户，组织是后续“按组织”可见范围判定的基础。用户录入要求填写用户名、真实姓名、所属组织、密级、初始角色，其中密级字段一旦设定后只能由系统管理员在审批留痕后上调，不允许随意下调，避免“降密级逃避审计”的风险。分类树建模按业务域逐级展开，例如“年度方案、2026年度、综合管理类、……、具体子类”，每一份文档必须归属到某个叶子分类，分类是后续按分类导航浏览的基础。 主方案的创建与流转是系统最核心的日常操作。普通用户在前端“主方案管理”页面点击“新建主方案”按钮后，系统弹出多标签页对话框，要求依次填写基本信息（标题、概述、密级、分类、可见范围、标签）、上传主方案文件（PDF、DOC、DOCX）、补充元数据（编制单位、编制时间、文号、关键词）。在用户点击“提交”后，前端先完成本地表单校验（必填项、字符长度、文件大小、文件格式），再将表单数据与文件流一同提交至后端。后端在事务内依次完成“字段再次校验、密级合法性校验（不允许创建密级高于当前用户密级的主方案）、文件落盘、文件摘要计算、预览生成（命中缓存则跳过转换）、正文提取、审计记录写入、事务提交”七个步骤；事务提交后异步触发分片与向量化流程，将正文按固定字数与段落边界切片、调用向量化服务计算向量表示并写入文档分片表与文档向量表，整个流程对用户表现为一次“提交、等待数秒、返回成功”，向量化在后台并行完成，不阻塞用户操作。返回成功后，主方案即对授权范围内的其他用户可见，并出现在审计看板的“上传”分类中。 子方案与配套资料的挂载流程设计为“先有主方案、后挂子件”，使主方案成为业务上的“锚点”。对于子方案，普通用户进入主方案详情页后，点击“挂载子方案”按钮，在弹出的对话框中选择已存在的子方案文档（或当场新建），后端在文档表上将子方案的父方案指向主方案的标识，并写入一条“挂载”审计记录；解绑时反向操作，将父方案指向置空并写入“解绑”审计记录。对于配套资料，普通用户进入主方案详情页后，点击“挂载配套资料”按钮，在弹出的对话框中选择已存在的配套资料文档（或当场新建），后端在挂载关系表上插入一条记录，记录挂载动作、挂载时间、关联的主方案与配套资料；解绑时将该条记录标记为软删除，但不物理删除该记录，便于事后追溯“曾经挂载过哪些资料”。 检索与查看流程是用户日常使用频率最高的操作。用户在主页面的检索工具栏输入关键词或自然语言问句后，前端将查询内容连同当前页码、分类筛选、时间范围筛选、密级筛选、标签筛选等参数一同提交至后端合并检索接口。后端并行启动两条召回链路：第一条是关键字多字段合并检索，在主方案、子方案、配套资料三档对象的标题、概述、标签、检索专用文本字段上执行模糊匹配合并查询；第二条是语义检索，将用户的问句送至向量化服务得到查询向量，再在文档向量表上按相似度检索出候选文档集合。两路结果按既定权重合并、去重、排序后分页返回；命中正文时，后端进一步在正文存储字段中定位关键词或匹配片段首次出现的位置，截取前后各若干字符作为上下文片段一并返回。前端在表格中渲染检索结果时，对于命中正文的结果行，在该行下方延展一行“正文”片段，使用高亮组件把关键词在片段中可视化标红。用户点击“查看”按钮后，前端弹出预览对话框，左侧展示文件预览，右侧展示提取文本（按空行分段、显示段号与字数），让用户在不下载文件的情况下完整阅读。用户点击“下载”按钮时，前端调用下载接口触发浏览器的原生下载行为，后端在审计日志中记录“下载”操作。 权限管理流程由文档所有者或系统管理员发起。文档所有者在该文档的“权限管理”页面可以看到当前已授权的主体列表（其他用户或组织），可以为新主体授予“查看、下载、编辑、删除、授权”五类权限中的任意组合，也可以撤销已授予的权限。每一次授权与撤销均写入审计日志。授权行为本身也受权限判定链约束——只有持有“授权”权限的主体才能为他人授权，避免越权扩散。同时，所有授权操作均不能突破“密级比对”的天花板：低密级用户无法通过授权获得对高密级文档的访问能力，即便文档所有者尝试这样做，系统也会在第四级密级比对时拒绝。 文档销毁流程设计为“二次确认、不可逆销毁”，避免误删造成不可恢复的损失。普通用户在前端点击“删除”按钮时，系统弹出二次确认对话框，要求普通用户再次输入操作理由并确认；若确认为最终销毁，则在事务内删除数据库记录、删除对应的文件、删除预览缓存、删除文档分片与文档向量记录、写入“销毁”审计记录，操作不可逆，且销毁前再次要求普通用户输入登录密码。所有销毁操作均写入审计日志，构成完整的数据生命周期可追溯链条。 审计与监督流程由系统管理员承担。系统管理员进入审计看板后，可以按时间范围、操作类型、操作人、目标对象类型等维度组合筛选审计记录，并支持导出为通用电子表格供外部归档。审计看板展示的内容包括但不限于：登录与登出、查看与下载、上传与编辑、删除与销毁、授权与撤销、挂载与解绑、密码修改、用户启停、密级变更等。所有审计记录均不可修改、不可删除，记录中包含的“操作人用户名、真实姓名、组织名、目标对象名称”等字段均为操作发生时的快照，即便事后用户改名、组织调整或文档被销毁，历史日志仍然可读、可解释。 ## 5. 安全保密措施设计 安全保密是本系统的核心设计目标，所有安全措施均围绕“分层防御、纵深防御、最小特权、可审计、可恢复”五项原则展开，构建从传输层到应用层再到数据层的完整防护体系。系统不依赖任何单一防护手段，而是通过身份认证、敏感操作二次认证、会话管理、密级管控、可见范围、细粒度授权、操作审计、哈希链防篡改、传输加密、存储隔离、应用层信封加密、敏感信息脱敏、错误信息收敛等多层机制叠加，形成“任何单一防线被突破都不会直接导致敏感信息泄露”的纵深格局。 在身份认证层面，系统采用密码加令牌的双因子机制，并对敏感操作叠加二次认证。用户在登录时提交用户名与密码，后端使用Argon2id算法（专门抵御GPU与ASIC暴力破解、且在抗碰撞变体上更稳健的现代密码哈希算法）对密码进行校验，校验通过后签发访问令牌与“保持登录”长效令牌。访问令牌用于日常接口调用，有效期较短（约数小时级别）；“保持登录”长效令牌仅在访问令牌过期时用于换取新的访问令牌，有效期较长（约数天级别）。所有令牌均使用现代签名算法签发，签名密钥存储在后端进程的受控配置中、不落盘、不出进程。登录失败时系统不区分“用户名不存在”与“密码错误”，统一返回“账号或密码错误”，避免账号枚举攻击。连续登录失败达到阈值时账号被自动锁定一段时间，同时写入审计日志。在常规登录态之上，系统对敏感操作叠加二次认证：文档销毁、用户密级调整、用户角色变更、权限批量授予与撤销、备份恢复、主备切换等高权限或不可逆操作执行前，要求操作人再次输入登录密码并由后端使用Argon2id重新校验、限定二次认证会话时间窗口，避免“会话被劫持后即可执行敏感操作”的风险。 在会话管理层面，系统通过“会话版本号”字段实现“令牌主动失效”能力。每个用户在用户表上有一个会话版本号字段，每次签发访问令牌时该值被编码到令牌负载中；后端在校验令牌时不仅校验签名与有效期，还校验令牌中的会话版本号与数据库中的当前值是否一致，不一致即拒绝。当系统管理员对某用户执行强制下线、修改密级、修改角色、重置密码等敏感操作时，系统在事务内将该用户的会话版本号自增，使该用户已签发的所有令牌立即失效。这种机制保证了“系统管理员对某用户做出权限调整后，该用户在数秒内即被强制重新登录”，避免“权限已被撤销但用户仍能继续操作”的安全窗口。 在密级管控层面，系统对每一份文档与每一个用户均赋予密级属性，密级按“公开、内部、秘密、机密、绝密”五档（具体档位可按需扩展）由低到高排列。用户密级由系统管理员在创建用户时设定，且只能由系统管理员在审批留痕后调整；文档密级由文档创建者在创建时设定，且不得高于创建者自身的密级。系统在鉴权判定链的第四级执行密级比对：用户的密级必须大于或等于文档的密级才能进行任何操作；密级比对失败时返回“密级不足”错误码，前端展示“您的密级不足以访问该文档”。这一比对发生在所有其他业务判定之前，与可见范围、授权记录共同构成“密级是天花板、可见范围是边界、授权是细粒度”的三层授权模型。 在细粒度授权层面，系统实现了基于访问控制列表的“主体、资源、操作”三元组授权模型。主体可以是单个用户，也可以是一个组织（组织内的所有用户自动继承该授权）；资源是某一份具体的文档；操作细分为查看、下载、编辑、删除、授权五类，可以任意组合。授权记录在权限表中以“主体类型、主体标识、文档标识、五个权限位标记”的形式存储，并对该四元组建立唯一约束，防止重复授权。鉴权时，系统先查“主体直接持有的授权”，再查“主体所在组织持有的授权”，将两者的并集作为该主体的最终权限集合。授权行为本身也受权限判定链约束——只有持有“授权”权限的主体才能为他人授权，避免越权扩散。 在操作审计层面，系统对所有有意义的写操作（以及部分敏感读操作，如查看机密文档、下载配套资料）均写入审计日志。审计记录在事务内与业务变更原子提交，保证“业务成功则审计成功、业务失败则审计不产生”。每条审计记录包含操作类型、操作时间（毫秒精度）、操作人标识/用户名/真实姓名、操作人所在组织名、目标对象类型/标识/名称、操作前快照（部分敏感操作）、操作后快照（部分敏感操作）、来源IP、请求追踪标识、备注、前一条记录的哈希摘要、本条记录的哈希摘要等字段。审计记录之间以哈希链方式串联：每条记录在写入时同时计算其内容哈希并将上一条记录的哈希摘要一并纳入输入，使任何一条记录被事后篡改都会导致其后所有记录的哈希校验失败，从而具备“写入即不可篡改、不可删除、可验证”的特性。审计记录仅在系统执行“彻底销毁文档”等极少数情况下会随销毁流程写入一条不可逆的“销毁”记录，但销毁本身也被审计且其哈希链关系保持连续。审计看板支持按多维度组合检索与导出，并提供哈希链完整性校验工具，便于系统管理员与外部监督人员定期校验审计链的连续性与未被篡改性。 在传输加密层面，系统在生产部署中强制启用加密通道。后端服务通过部署单位密码基础设施签发的服务器证书对外提供加密接口，所有访问令牌、所有文件上传与下载、所有表单提交均在加密通道中传输，避免被中间人窃听或篡改。证书签发、信任链管理与密钥保管均由部署单位按涉密信息系统密码保障要求统一组织，本系统不引入任何外部认证服务。前端与后端之间的所有请求均通过同一加密通道，避免“接口走加密通道但文件走明文通道”的混合内容漏洞。 在存储隔离层面，系统对原始文件、预览缓存、日志文件、数据库文件进行物理目录隔离。原始文件按“业务类型、年月”分层存储，文件名使用随机生成的唯一标识而非用户上传的原文件名，避免通过文件名枚举攻击。预览缓存单独存储在专属子目录下，便于备份与清理。日志文件按“日期、进程”切分，避免单个日志文件过大。数据库文件存储在独立子目录下，与文件存储、日志目录互不干扰。所有目录的访问权限按银河麒麟操作系统文件系统的最小特权原则配置，运行账号仅具有对自身数据目录的读写权限，无系统目录的写入权限。 在应用层加密层面，系统在传输加密与存储隔离之上叠加一层信封加密，使原始文件即使被直接读取也无法还原出明文。系统在受控配置中持有一份主密钥（KEK），用于加密每份文档落盘时随机生成的数据密钥（DEK）；DEK加密文档内容后与密文一同写入文件目录，KEK始终不落盘、不出进程，仅在系统启动时从受控配置或部署单位密码设施注入。数据库中的敏感字段（如审计日志中可能含敏感细节的备注、用户表的密码哈希之外的敏感属性等）同样按字段维度使用DEK加密、DEK由KEK包裹后存储。文件读取、字段读取、备份恢复时由应用服务按相反顺序解密，磁盘与备份介质上始终只存在密文，即便备份介质被带离专用网络也无法直接还原。密钥轮换由系统管理员在审批留痕后触发，新KEK生成后对存量DEK重新包裹，旧KEK在轮换窗口内保留以便解密历史数据，窗口结束后从内存中清除。 在敏感信息处理层面，系统对所有可能泄露内部细节的对外响应进行收敛。错误响应不包含绝对路径、文件摘要、SQL文本、堆栈信息等内部细节，仅返回业务可读的错误码与中文消息。文件下载响应不暴露原始存储路径，仅返回经过处理的文件流。审计日志的对外响应按当前用户的密级进行过滤，低密级用户看不到高密级操作的细节。系统管理员导出审计日志时，导出文件中包含敏感字段（如IP、用户名）按合规要求进行可选脱敏。所有敏感字段在数据库中按应用层加密规则以密文形式存储，仅在应用层按当前用户权限解密后呈现，对外响应与导出环节再按当前用户的密级与角色进行收敛，避免敏感信息通过应用层接口或导出文件扩散。 在运维安全层面，系统对自身运行所需的密钥、口令、连接串等敏感配置统一通过环境变量或专用配置文件注入，不硬编码在源码中、不写入版本控制。签名密钥、数据库连接串、初始管理员口令等配置项在系统启动时从受控来源读取，部署单位的运维管理员可以通过操作系统级的环境变量管理工具或专用密钥管理服务集中管理。系统的可执行产物附带完整性校验，运行启动时自校验关键资源文件的哈希值，发现异常立即中止并提示用户。系统默认不开放任何调试接口、不打印任何敏感日志、不向外部网络发送任何遥测数据。 --- ## 6. 可靠性、维修性、保障性、测试性、安全性设计 本系统按装备研制“六性”要求，结合软件形态特点对前五性进行设计；环境适应性并入部署运行环境交代。 ### 6.1可靠性设计 本系统的可靠性设计从避免出错、容忍异常、快速恢复三个层次展开。避免出错方面：所有对外接口采用强类型入参校验，完成必填项、类型、长度、范围、枚举检查；所有写操作强制乐观锁版本号，避免并发覆盖；所有数据库操作经数据访问层与参数化查询执行，杜绝SQL注入；所有文件操作显式声明编码与字符集，避免编码异常崩溃。容忍异常方面：外部依赖调用（外部转换引擎、向量化服务、文件读写、摘要计算、加解密）均包裹异常捕获，异常返回错误码而非崩溃进程；外部转换引擎与向量化服务均设置独立超时与内存上限，异常不影响应用服务主进程；数据库连接池配置超时、回收与健康检查策略。快速恢复方面：业务变更在事务内原子提交，异常自动回滚；文件操作采用“先写临时文件、确认后再原子重命名”策略；应用服务、向量化服务、数据库主备、负载均衡器均按主备或集群方式部署，单节点故障可由备用节点或备用IP切换接管；第三台服务器按“3-2-1”原则集中保存每周全量与每日增量备份，备份目录以只追加不覆盖方式写入，构成数据级兜底与防误删最后一道防线。 ### 6.2维修性设计 本系统的维修性设计体现在可观测、可定位、可修改、可回滚四个层面。可观测方面：响应中的请求追踪标识同时写入审计日志与运行日志，运维人员据此串联请求全链路；运行日志按日期、进程、级别切分，包含时间戳、级别、模块、行号、消息与上下文变量。可定位方面：错误码按业务域命名，运维人员据此快速锁定问题模块与场景；异常堆栈在开发模式输出到日志，在生产模式收敛到受控通道。可修改方面：分层与模块化设计使一处变更通常只影响一个模块；迁移脚本按版本号线性递增、不允许修改历史迁移。可回滚方面：所有变更通过版本控制管理，可快速回退历史版本；数据库迁移提供“前进”与“回滚”两类操作，便于数据结构变更引发问题时回滚到稳定状态。 ### 6.3保障性设计 本系统保障性设计核心是集群化部署、本地化运行、低门槛使用。集群化部署方面：采用5台银河麒麟服务器的集群部署方案，第一、二、三台组成无状态应用服务集群并行承担业务访问，第一台承担主负载均衡器与主向量化服务，第二台承担备用负载均衡器与备用向量化服务，第四、五台承担数据库主备集群、采用同步双写的热备方式，第三台按“3-2-1”原则集中存储每周全量与每日增量备份、备份目录以只追加不覆盖方式写入，构成多重故障下的数据兜底与防误删最后一道防线。本地化运行方面：全部能力依托专用网络内部资源完成，不依赖任何在线Office服务、在线PDF渲染服务、外部认证服务、在线大模型服务；备份恢复通过标准数据库管理工具与系统附带的备份执行脚本配合完成；提供正文回填与向量回填脚本，一键补齐历史数据的检索与语义匹配能力。低门槛使用方面：用户界面按非技术用户五分钟内学会日常使用的标准设计，所有操作通过对话框与表单引导，无命令行交互；系统管理员的运维与管理操作均通过专用页面完成。 ### 6.4测试性设计 本系统测试性设计体现在分层测试、高覆盖率、可重复执行、持续集成四个层面。分层测试方面：后端按单元测试（领域服务层）、集成测试（应用层路由层）、端到端测试（关键业务流程）三层组织；前端按组件测试、模块测试、端到端测试组织。高覆盖率方面：后端业务层目标覆盖率80%（核心服务方法90%），前端组件层目标70%，关键业务流程端到端测试覆盖率目标100%。可重复执行方面：所有测试使用隔离的测试数据库或临时目录，互不污染、可任意顺序执行。持续集成方面：变更合并到主分支前必须通过全部自动化测试；流水线在每次提交后运行后端单元、集成测试与前端组件、模块测试，每晚运行端到端测试。 ### 6.5安全性设计 本系统作为承载敏感方案文档的软件平台，其“安全性”在装备研制“六性”语境下聚焦于“数据安全、操作安全、运行安全、保密安全”四个层面，与第5章“安全保密措施设计”的纵深防御体系互为呼应，但更侧重软件形态下对人员、数据与业务连续性的保障。 数据安全方面，系统对所有原始文件、预览缓存、数据库文件按物理目录隔离并叠加应用层信封加密，磁盘与备份介质上始终只存在密文；备份策略遵循“3-2-1”原则——至少3份副本、至少2种存储介质、至少1份异地副本（专用网络内的不同服务器），第三台服务器集中保存每周全量与每日增量备份，备份目录以只追加不覆盖方式写入，防止误删或恶意删除波及备份本身；数据库采用主备热备、同步双写，主库故障时可在系统管理员审批与主备切换脚本配合下切换至备库，备库切换前需经哈希链完整性校验确认审计链未被篡改。 操作安全方面，系统对销毁、密级调整、角色变更、权限批量授予与撤销、备份恢复、主备切换等高权限或不可逆操作统一要求“二次确认+二次认证”：前端弹出二次确认对话框、要求填写操作理由，后端再次校验登录密码并限定二次认证会话时间窗口；同时所有写操作携带乐观锁版本号，防止并发覆盖；所有审计记录以哈希链方式串联，事后可由系统管理员或外部监督人员校验完整性。这一组合措施保证“即便用户账号被劫持，攻击者也无法在短时间内完成批量销毁或越权操作”。 运行安全方面，系统对内部服务调用（外部转换引擎、向量化服务、文件读写、摘要计算、加解密）均包裹异常捕获并设置独立超时与内存上限，任一外部依赖异常都不会击穿应用服务主进程；应用服务、向量化服务、负载均衡器、数据库均按主备或集群方式部署，单节点故障由备用节点或备用IP接管；备份恢复与主备切换均由系统管理员在审批留痕后通过受控脚本执行，避免运维人员直接操作数据库或文件目录。 保密安全方面，系统通过密级管控、可见范围、细粒度授权、传输加密、应用层加密、敏感信息脱敏、错误信息收敛等多层机制叠加，形成“任何单一防线被突破都不会直接导致敏感信息泄露”的纵深格局；密钥、口令、连接串等敏感配置统一通过环境变量或专用配置文件注入，不硬编码在源码中、不写入版本控制；系统默认不开放任何调试接口、不打印任何敏感日志、不向外部网络发送任何遥测数据。系统研制与交付阶段同步开展安全漏洞扫描、渗透测试与桌面演练，并在每个季度进行一次安全事件响应预案演练，确保从“漏洞发现 — 影响评估 — 补丁开发 — 紧急发版 — 用户通知 — 事后复盘”的全流程责任人、时间窗口与沟通策略均经过实战检验。 --- ## 7. 关键技术解决途径 本系统在研制过程中遇到若干关键技术问题，这些问题没有现成的开源方案可以直接照搬，需要项目组结合实际场景进行技术选型与工程攻关。下面对其中最关键的四项技术问题及其解决途径进行说明，每一项均涵盖“问题背景、技术挑战、解决途径、验证效果”四个维度，便于后续维护人员理解为何采用当前方案、以及如何在演进过程中保留这些方案的核心价值。 ### 7.1物理隔离环境下的离线Office文档预览技术 问题背景方面，方案计划类文档以PDF、DOC、DOCX三种格式流转，但DOC与DOCX无法在浏览器中直接渲染，必须先转换为PDF。技术挑战方面，离线Office转换需要满足三个相互制约的条件：转换质量必须接近原始Office的渲染效果（保留字体、段落、表格、嵌入对象）、转换延迟必须控制在数秒内、转换依赖必须能够在专用网络内部署运行。解决途径方面，本系统选择成熟的开源办公套件作为离线转换引擎：开源办公套件跨平台、长期维护，转换质量在主流Office文档上接近原始效果；提供命令行转换接口，可被应用服务通过受控抽象层调用，无需常驻服务进程；安装包随服务器镜像一次性部署，不依赖任何在线服务。本系统在转换抽象层中将外部转换引擎的调用封装为“输入文件路径、输出目录，输出转换结果路径”的最小接口，并对外部进程设置独立的超时与内存上限；同时通过文件摘要缓存避免对同一份文件重复转换。验证效果方面，在数百份真实方案文档的样本上，转换成功率达到98%以上，平均转换时间为数秒级，缓存命中率在重复上传场景下接近100%。 ### 7.2基于文件摘要的预览缓存与去重技术 问题背景方面，方案类文档在单位内部经常以“多人多次上传同一份文件”的方式流转，例如不同人员分别上传同一份红头文件作为各自方案的依据。如果对每一次上传都重新执行转换与正文提取，将造成大量重复的CPU与磁盘开销。技术挑战方面，去重必须满足“语义等价的文件必须命中同一份缓存”，而语义等价的判定本身就是一个开放问题——同名但内容不同的文件不应命中、同内容但不同名的文件应该命中、内容仅空白差异的文件是否应该命中也需要决策。解决途径方面，本系统采用安全摘要算法计算出的文件摘要作为文件语义等价的判定标准：在文件落盘的同一事务中计算文件摘要，并将摘要写入文档表；预览缓存的键即为该摘要，缓存表记录摘要、预览PDF的相对路径、生成时间、引用计数；当上传件触发预览生成时，先按摘要查询缓存，命中则直接复用缓存的PDF，未命中才触发转换。这一策略保证了“内容相同的文件无论被上传多少次，只会被转换一次”，把转换成本从“上传次数线性增长”降为“唯一内容数线性增长”。验证效果方面，在大批量模拟上传（实际唯一内容远少于上传次数）的场景下，预览生成调用次数与唯一内容数一致，相比无缓存方案显著节省了转换开销，预览PDF的存储开销节省了同样的比例。 ### 7.3多机集群部署与主备自动切换技术 问题背景方面，本系统的目标用户是各级军事机关、部队及野外作业分队，方案类文档需要在多人之间协同流转、需要持续在线可用、需要抵御单机故障导致的服务中断与数据丢失。技术挑战方面，部署形态必须满足“任一应用节点故障不影响业务访问、任一数据库节点故障不丢失已提交事务、关键服务具备主备自动切换能力、关键数据具备多重备份兜底且备份自身不被误删与恶意删除波及”，同时所有组件必须能够在严格物理隔离的专用网络内部署运行。解决途径方面，本系统采用5台服务器的集群部署方案：第一、二、三台部署完全同构的应用服务包、组成无状态应用服务集群，由负载均衡器统一分发请求；第一台承担主负载均衡器与主向量化服务，第二台承担备用负载均衡器与备用向量化服务，主向量化服务不可达时各应用服务节点自动切换至备用；第四、五台承担数据库主备集群、采用同步双写的热备方式，主库故障时由系统管理员通过主备切换脚本受控切换至备库；第三台作为集中备份目标，按“3-2-1”原则承接第一、二台的数据备份——每周日凌晨全量、每日凌晨增量，备份目录以只追加不覆盖方式写入，构成两台数据库同时损坏情况下的第三重保险与防误删的最后一道防线。前端构建产物由应用服务包以静态资源方式对外提供，无需独立部署。验证效果方面，应用服务集群支持任一节点故障下的并行可用，主备向量化服务支持主节点故障下的自动切换，数据库主备支持同步双写下的零数据丢失，备份策略支持多重故障下的数据兜底与误删可恢复。 ### 7.4关键字合并检索与向量化语义检索的双路混合检索技术 问题背景方面，方案类文档的检索需求是“既能按关键字精确命中标题、概述、标签、正文，又能按语义命中含义相近但用词不同的文档”，单一检索链路无法同时兼顾精确性与语义性。技术挑战方面，本系统需要在“不依赖在线大模型服务、不显著增加数据库负担、不破坏既有应用层协议”的前提下同时实现两类检索，并支持命中正文时给出上下文片段。解决途径方面，本系统采用“关键字合并检索 + 向量化语义检索”的双路混合方案：在文档记录上同时维护“完整正文存储字段”与“裁剪后的检索专用字段”，在文档分片表与文档向量表上分别记录每片文本与对应的向量表示；检索时并行启动两条召回链路——第一条对标题、概述、标签、检索专用字段执行模糊匹配合并查询，第二条将用户问句送至本地向量化服务得到查询向量、再在文档向量表上按相似度检索出Top-N候选片；两路结果按既定权重合并、去重、排序后分页返回；命中后，后端在正文存储字段中定位关键词或匹配片段首次出现的位置，截取前后各若干字符作为上下文片段；前端在结果行的下方延展一行展示片段，并使用高亮组件把关键词在片段中可视化标红。这一方案在数千份文档的典型规模下响应时间控制在数百毫秒级别，且向量化依托本地资源完成、不依赖任何在线服务；数据规模增长后可平滑切换到专用全文检索引擎或专用向量数据库，前端与应用层协议均无需变更。验证效果方面，在典型规模（数千份文档）的样本上，单关键词、多关键词组合、自然语言问句三类检索的平均响应时间均保持在日常指挥办公可接受的范围内，命中正文的上下文片段截取与向量相似度计算耗时可忽略。 --- ## 8. 质量控制与标准化管理 ### 8.1质量控制 本系统研制周期紧张，质量控制聚焦核心门槛与回归验证。研制启动时明确若干硬性门槛：所有对外接口遵循统一响应结构、所有写操作支持乐观锁、所有迁移文件按版本号线性递增、所有审计记录与业务变更原子提交。代码合并到主分支前必须通过代码评审与自动化测试；自动化测试按单元测试、集成测试、端到端测试三层组织，覆盖核心业务流程。发版前在测试环境执行回归验证，确认未引入新缺陷。 ### 8.2标准化管理 标准化管理以代码、命名、版本三项最为关键。代码方面，所有源码按对应语言的业界通用风格组织，公开方法均有中文说明。命名方面，业务对象使用业务名词，数据库层按下划线分隔、前端层按驼峰分隔，同一业务对象在所有层级命名一致。版本方面，迁移文件按版本号线性递增、不允许修改历史迁移；文档按“主版本.次版本.修订号”三段式管理，修改记录在文档末尾统一维护。 --- ## 9. 风险分析 ### 9.1技术风险 本系统面临的主要技术风险可以归纳为“性能风险、兼容性风险、依赖风险、安全风险”四类，每一类风险均在研制过程中被识别、被评估、被缓解，剩余风险被显式记录并跟踪。 性能风险方面，系统的检索能力由“关键字多字段合并检索”与“向量化语义检索”双路召回构成，前者基于关系数据库的模糊匹配实现、后者基于文档向量表的相似度检索实现，在数据规模增长到数万份文档以上时，两路召回的响应时间均可能从当前的数百毫秒级别退化到秒级，影响用户体验。这一风险的缓解措施包括：在检索专用字段与文档向量表的相似度索引上建立合适索引、对常用筛选字段（分类、密级、状态）建立组合索引、对长字段做适度裁剪、对检索结果做合理分页，将“全表模糊扫描”与“全量向量比对”均控制在可接受范围内；同时，数据模型与对外接口在设计上即为切换到数据库自身的高级全文索引、专用全文检索引擎或专用向量数据库预留了平滑路径，未来如需切换仅需替换后端实现而无需变更对外契约。剩余风险是“在切换之前如出现数据规模暴增，可能在短时间内影响响应时间”，应对策略是建立性能监控告警，在响应时间连续超过阈值时立即触发切换预案。 兼容性风险方面，系统的离线格式转换依赖开源办公套件，而开源办公套件对部分复杂文档（包含复杂表格嵌套、宏、嵌入对象、特殊字体）的渲染可能存在偏差，与商用办公软件的呈现效果略有差异。这一风险的缓解措施包括：在样本库中收集各类典型文档并定期回归转换效果、对转换失败的文档显式提示用户“在线预览不可用，请下载后查看”、对关键文档提供“原文件下载”作为兜底通道。剩余风险是“极少数极复杂的文档转换效果与原始办公软件渲染存在不可消除的差异”，应对策略是在用户手册中明确说明“在线预览仅供快速浏览使用，正式审阅请下载原文件”。 依赖风险方面，系统的运行依赖若干开源项目（Web框架、ORM、文档解析库、前端框架、构建工具、预览渲染引擎、办公转换套件等），这些项目的活跃度、维护策略、许可证可能随时间发生变化。这一风险的缓解措施包括：在依赖选型阶段优先选择“长期维护、社区活跃、许可证宽松、跨平台支持好”的项目、在依赖清单中固定版本号、定期关注依赖项目的安全公告与维护动态、对核心依赖（如办公转换套件）保留可替换的抽象层，转换服务可整体替换为其他转换引擎而不影响上层调用。剩余风险是“某个关键依赖项目停止维护或修改许可证”，应对策略是建立“依赖健康度季度评估”机制，对存在风险的依赖提前规划替代方案。 安全风险方面，系统作为承载敏感方案文档的平台，自身始终是潜在的安全攻击目标。缓解措施包括分层鉴权、密级管控、操作审计、传输加密、存储隔离、敏感信息脱敏、错误信息收敛、依赖版本固定等。剩余风险是“未知的零日漏洞或社会工程学攻击”，应对策略是建立“安全事件响应预案”，明确从“漏洞发现 — 影响评估 — 补丁开发 — 紧急发版 — 用户通知 — 事后复盘”的全流程责任人、时间窗口与沟通策略，并在每个季度进行一次桌面演练。 ### 9.2进度风险 进度风险方面，本系统采用迭代式研发，按“基础设施先行、核心功能优先、增强功能次之、辅助功能最后”的顺序推进。基础设施阶段（数据库、迁移、鉴权框架、响应封装、分页协议）必须在前20%的工期内完成，否则后续业务功能将受其拖累；核心功能阶段（主方案、子方案、配套资料、文件上传、预览、检索、向量化）必须在前60%的工期内完成，否则无法进入用户验收；增强功能阶段（审计、权限管理、统计、标签筛选、批量回填）在最后40%工期内完成；辅助功能（导出、统计图表、定制化主题等）如时间紧张可以延期到下个版本。 为控制进度风险，项目组采取三项措施：其一，每两周进行一次进度复盘，对照计划评估实际进度，发现偏差超过10%立即分析根因并调整后续排期；其二，核心功能采用“垂直切片”方式开发——每个垂直切片包含“后端领域服务+应用层路由+前端界面+集成测试”的完整链路，使每个切片完成后即可由用户验收，避免“后端先做完、前端滞后”的传统延期模式；其三，建立“最小可行版本（MVP）— 增强版本（V1）— 完整版本（V2）”的三阶段发布策略，每个阶段均有可演示的产出物，避免“全部完成才能演示”的整体性延期风险。 进度风险的剩余来源主要是“需求变更”与“外部依赖延迟”。需求变更通过“变更控制委员会”机制管理，每个变更均评估对进度的影响，超出阈值的变更转入下个版本。外部依赖延迟（如办公转换套件版本升级、操作系统兼容性问题）通过“提前集成、提前测试”的策略缓解，所有关键外部依赖在研制早期即完成集成验证，避免在后期才暴露问题。 --- ## 10. 实施步骤 ### 10.1研制人员及分工 本系统研制团队由3至4人组成，按“项目负责人、后端工程师、前端工程师、测试工程师”四个角色组织，项目负责人兼任架构师与运维。 项目负责人对进度、范围与架构决策负责，承担需求对接、技术方案编写与维护、关键模块（基础设施层与鉴权框架）编码、代码评审与发版批准，并兼顾部署与现场支持。后端工程师负责后端业务层、数据层、基础设施层的编码与单元测试，按“先模型、再迁移、再服务、再路由、再测试”的顺序推进，并参与接口设计与错误码定义。前端工程师负责前端所有特性模块与公共组件的编码与组件测试，按“先接口客户端、再特性模块、再页面集成、再端到端测试”的顺序推进，并参与接口设计与界面评审。测试工程师负责集成测试、端到端测试、回归测试、安全测试的编写与执行，并对每次发版进行验收测试，同时维护自动化测试流水线与缺陷跟踪。 各角色之间的协作通过每日站会与每周复盘会组织，关键设计变更通过代码评审与决策会议确定。 ### 10.2进度安排 本系统研制周期约6周，其中开发约4周、安全测试与交付约2周。开发阶段按“基础期 — 核心期 — 增强期”三段推进：基础期（约0.5周）完成数据库初始化、迁移框架、鉴权框架、响应封装、分页协议、错误码体系、前后端接口客户端骨架；核心期（约2.5周）完成主方案、子方案、配套资料、文件上传、预览（含深度渲染器与办公转换套件集成）、关键字合并检索、文档分片与向量化等核心业务功能；增强期（约1周）完成审计、权限管理、标签筛选、批量回填、集群部署与主备切换等增强功能。安全测试与交付阶段（约2周）完成安全漏洞扫描、渗透测试、用户验收测试、用户手册与运维手册编写、试点部署、正式发版。 具体节点按“第1周末完成基础设施与第一条业务链路冒烟、第2周末完成核心业务后端与前端MVP、第3周末完成核心业务全量并启动增强功能、第4周末完成开发并冻结代码、第5周末完成安全测试与缺陷修复、第6周末完成用户验收与试点部署”控制。 发版后的维护与演进按需推进。安全补丁与关键缺陷修复优先处理；功能增强（如批量导入作业、跨库联邦检索、专用全文检索引擎切换、专用向量数据库切换等）按用户需求排期到后续版本。 --- ## 修改记录 | 版本 | 日期 | 修订人 | 修订内容 | | --- | --- | --- | --- | | v1.0 | 2026-08-12 | 项目组 | 首次发布，按研制任务书要求完成全部章节编制 |