企业官网建设流程全解析

简介：这是一份关于档案管理系统介绍的 doc 格式技术文档，面向政府机关、企事业单位的信息化管理人员、档案管理员及软件选型与实施人员。文档系统阐述了档案管理系统在信息技术背景下的定位与作用，涵盖文书、科研、产品、设备、基建、会计、声像等门类档案的管理思路，并详细介绍了全文管理、多种组卷方式、用户化报表、数据接口、权限设置与数据备份等核心功能模块。资源为单个 Word 文档，大小约70KB，内容结构完整，包含概述、特点效果、方案图解等部分，强调系统遵循国家档案分类原则，支持分类表四级结构和现行资料的跟踪控制，可作为了解档案管理系统功能架构与实施要点的入门资料。目前已有67人学习浏览，适合需要快速掌握档案管理信息化概念与系统功能框架的读者。文档还提供了分类表定制、组卷方式、权限角色设置等具体细节，便于后续开展系统选型或内部培训参考。

1. 拿到《档案管理系统.doc》这份文档时，先读懂它的真实含义

第一次看到这个文件名的人，多半会愣一下——“档案管理系统”重复了两遍，后缀还是 .doc。这种命名方式本身就是很多单位档案管理现状的缩影：文件堆在共享目录里，同一个名字反复出现，谁也说不清哪个是最终版。这份文档真正要讲的，不是某个软件的操作说明，而是“档案怎么收、怎么管、怎么用”的一整套业务规则。纸质档案数字化之后，不能再靠文件夹和文件名硬扛，要有明确的管理层次、编号规则、借阅审批和数据校验机制。

它适合三类人读：信息部门要接手系统建设的开发人员，档案室里熟悉业务但不懂技术的管理员，以及外包实施团队里负责需求调研的顾问。文档里写的不是界面长什么样，而是“全宗、案卷、卷内文件”这三个层次怎么组织，电子文件怎么归档、怎么借阅、怎么长期保存。把这些规则翻译成数据库表结构和接口逻辑，系统才算真正落地。

2. 从纸面到表结构：把文档里的业务规则翻译成数据库设计

2.1 电子档案的核心对象：不是“文件”和“文件夹”，而是“全宗—案卷—卷内”

很多第一次做档案系统的人，会习惯性地把数据库设计成一张 file 表加一个 folder 表，理由是“电子档案不就是文件存到服务器上，再用目录分一下类”。这个思路在个人网盘场景下没问题，但放在档案管理系统里会翻车——因为它丢失了档案行业最核心的管理单位。

档案管理有一套约定俗成的层次：全宗（ fonds ）是一个立档单位全部档案的总称，相当于“这个单位的档案库”；案卷是一组有联系的文件组合，相当于“一个年度、一个部门的问题归类”；卷内文件是案卷里的每一份具体文件。档案员平时统计的“案卷数”“卷内件数”“页数”，都是按这三个层次来的。如果你只设计了文件夹和文件两级，等于把业务语言丢掉了，后续做年报统计、移交进馆、到期鉴定，全都对不上账。

所以建表之前，先按住冲动，不要急着打开 MySQL 写 create table。先把文档里的业务对象理一遍：全宗表对应一个立档单位，案卷表挂在全宗下面，卷内文件表挂在案卷下面。除此之外，还有借阅审批记录表、保管期限表、分类号表。这四类表是档案管理系统的骨架，其他功能都是在这副骨架上长出来的。

我在做过的一个模拟项目里，见过最省事的做法是：全宗表和案卷表合并成一张 department 表，案卷编号直接存到 file 表的 parent_code 字段里。前两个月跑得挺顺，到了年底要做“按全宗统计案卷数量、按案卷统计文件页数”的报表时，SQL 越写越绕，最后不得不重构。这个教训说明，先按业务层次建表，比图省事合并表要划算得多。

2.2 核心表清单：全宗表、案卷表、卷内文件表、借阅表的职责边界

理清了层次，再看每张表的职责。全宗表存的是立档单位本身的信息，比如单位代码、单位名称、档案门类、起始年度。案卷表存的是“这一卷是什么”——案卷号、题名、年度、保管期限、密级、页数。卷内文件表存的是“这一卷里有哪几份文件”——文件编号、责任者、文号、题名、日期、附件信息、存储路径、文件格式。

借阅表则单独一类，它记录的是“谁、在什么时候、借走了哪份文件、批没批准、什么时候还”。注意，借阅表不要和卷内文件表混在一起。很多人为了省事，直接在文件表上加一个 is_borrowed 字段，这样做的问题在于：借阅是有历史记录的，一个人借了还了之后，下次再借，你得能查到上次的记录；如果只用字段标记，记录就丢了。而且审批流需要记录申请时间、审批人、审批意见、应还日期，这些字段放在文件表上会非常臃肿。

分类号和保管期限也不建议塞在案卷表里用字符串硬写。分类号有层级，比如“党群类—行政类—财务类”，用字符串存虽然直观，但做树形筛选时要 like 拼接，效率不高。常见做法是单独建一张分类表，案卷表存分类的 ID；保管期限也单独建字典表，避免每年写年报时把“永久”“30年”“10年”写成各种别名。数据字典这件事，越早做越省心。

2.3 把四张核心表落到 MySQL：一段可以直接跑的建表 DDL

理论说完了，给一份实际的建表脚本。我用 MySQL 5.7 以上版本的语法，引擎选 InnoDB，字符集用 utf8mb4——理由很简单，档案题名里可能出现生僻字和特殊符号，utf8mb4 才能不出乱码。以下是核心四张表的精简版本，省略了部分索引和冗余字段，保留主线。

-- 全宗表：一个立档单位一条记录 CREATE TABLE `archives_fonds` ( `fonds_id` INT NOT NULL AUTO_INCREMENT COMMENT '全宗ID', `fonds_code` VARCHAR(32) NOT NULL COMMENT '全宗号，如A001', `fonds_name` VARCHAR(255) NOT NULL COMMENT '立档单位名称', `category_type` VARCHAR(32) DEFAULT '文书' COMMENT '档案门类：文书/科技/财务/照片', `start_year` SMALLINT DEFAULT NULL COMMENT '起始年度', `end_year` SMALLINT DEFAULT NULL COMMENT '终止年度', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`fonds_id`), UNIQUE KEY `uk_fonds_code` (`fonds_code`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='全宗表'; -- 案卷表：挂在全宗下的案卷 CREATE TABLE `archives_volume` ( `volume_id` INT NOT NULL AUTO_INCREMENT COMMENT '案卷ID', `fonds_id` INT NOT NULL COMMENT '所属全宗ID', `category_id` INT DEFAULT NULL COMMENT '分类ID，关联分类表', `volume_code` VARCHAR(64) NOT NULL COMMENT '案卷号，如A001-2024-001', `volume_title` VARCHAR(500) NOT NULL COMMENT '案卷题名', `retention_period` VARCHAR(16) DEFAULT '永久' COMMENT '保管期限', `secrecy_level` VARCHAR(16) DEFAULT '内部' COMMENT '密级', `page_count` INT DEFAULT 0 COMMENT '总页数', `file_count` INT DEFAULT 0 COMMENT '卷内文件数', `status` TINYINT DEFAULT 1 COMMENT '1=已归档 0=临时', PRIMARY KEY (`volume_id`), UNIQUE KEY `uk_volume_code` (`volume_code`), KEY `idx_fonds` (`fonds_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='案卷表'; -- 卷内文件表：每一份电子文件 CREATE TABLE `archives_file` ( `file_id` INT NOT NULL AUTO_INCREMENT COMMENT '文件ID', `volume_id` INT NOT NULL COMMENT '所属案卷ID', `file_code` VARCHAR(64) NOT NULL COMMENT '文件编号，如A001-2024-001-01', `doc_title` VARCHAR(500) NOT NULL COMMENT '文件题名', `author` VARCHAR(255) DEFAULT NULL COMMENT '责任者', `doc_number` VARCHAR(64) DEFAULT NULL COMMENT '文号，如〔2024〕3号', `doc_date` DATE DEFAULT NULL COMMENT '成文日期', `page_start` INT DEFAULT NULL COMMENT '起始页号', `page_end` INT DEFAULT NULL COMMENT '结束页号', `file_path` VARCHAR(500) DEFAULT NULL COMMENT '电子文件存储相对路径', `file_format` VARCHAR(16) DEFAULT NULL COMMENT '原始格式，如pdf/ofd', `file_size` BIGINT DEFAULT 0 COMMENT '文件大小，字节', `upload_time` DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`file_id`), UNIQUE KEY `uk_file_code` (`file_code`), KEY `idx_volume` (`volume_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='卷内文件表'; -- 借阅记录表：审批与归还记录 CREATE TABLE `archives_borrow` ( `borrow_id` INT NOT NULL AUTO_INCREMENT COMMENT '借阅ID', `file_id` INT NOT NULL COMMENT '被借阅文件ID', `borrower` VARCHAR(64) NOT NULL COMMENT '借阅人姓名/工号', `borrow_dept` VARCHAR(128) DEFAULT NULL COMMENT '借阅人部门', `apply_time` DATETIME DEFAULT NULL COMMENT '申请时间', `approve_status` TINYINT DEFAULT 0 COMMENT '0=待审批 1=已批准 2=已拒绝 3=已归还', `approve_comment` VARCHAR(500) DEFAULT NULL COMMENT '审批意见', `should_return_date` DATE DEFAULT NULL COMMENT '应还日期', `actual_return_time` DATETIME DEFAULT NULL COMMENT '实际归还时间', PRIMARY KEY (`borrow_id`), KEY `idx_file` (`file_id`), KEY `idx_status` (`approve_status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='借阅记录表';

这段 DDL 里几个字段说下设计意图。file_code用了三段式编号：全宗号-年度-流水号，后面再接卷内顺序号，比如A001-2024-001-01，这个编号规则要和应用层生成逻辑保持一致，数据库层做唯一约束兜底。file_path存的是相对路径而不是绝对路径，这是为了迁移方便——系统换服务器时，只需要改存储根目录的配置，不需要动数据库里的记录。secrecy_level和retention_period虽然存的是字符串，但建议在应用层做白名单校验，只允许写入字典表里存在的值，避免“机密”“机秘”这种同音不同字的数据污染。

archives_borrow表单独维护审批状态，这里有个容易被忽略的点：实际归还时间用 DATETIME，应还日期用 DATE，两者类型不同是有意的。应还日期是业务上约定的期限，不需要具体到时分；实际归还时间是操作时间戳，要精确到秒。如果统一用 DATETIME，应还日期会带出 00:00:00，查询“今天到期未归还”的列表时就要用DATE(should_return_date) = CURDATE()做转换，多一层开销且容易写错。

3. 从表到流程：把“归档—借阅—统计”串成可运行的业务逻辑

3.1 在线归档的先后顺序：先转格式、再生成编号、最后写库

表结构只是骨架，业务跑起来靠的是操作流程的顺序。在线归档这一步，最常见的错误是先把文件传上去、把数据库记录插进去，然后再去转格式、补编号。如果中间某一步失败，数据库里就多了一条没有文件的脏记录，或者文件在磁盘上但数据库里找不到对应记录。

我一般建议的顺序是：文件上传到临时目录 → 校验文件格式和大小 → 执行格式转换（比如转 PDF/A 或 OFD）→ 按规则生成档号 → 移动文件到正式存储目录 → 插入数据库记录。整个过程要么全部成功，要么全部回滚。文件移动和数据库插入无法用同一个事务保证，所以实践中要在移动文件之前把目标文件路径先算好，如果插入数据库失败，再由定时任务清理孤儿文件。

格式转换是个容易忽略性能的点。一份扫描文件可能有几十 MB，在线接口里同步转换会让用户等很久。常见做法是上传完成后立刻返回“已接收”，转换和编号放到后台任务队列里异步处理，前端轮询状态。队列的选型不一定要上重型中间件，初期用数据库里的一个 task 表加定时任务扫描即可，等并发上来了再迁到消息队列。

这里给一段归档环节做编号生成和路径计算的 Python 示例，适用于 Flask 或 Django 的后台任务：

import os import datetime def build_archive_path(fonds_code, year, volume_seq, file_seq, ext): """ 生成归档文件存储路径和档号。 路径规则：STORAGE_ROOT/fonds_code/year/volume_seq/ 档号规则：fonds_code-year-volume_seq-file_seq """ storage_root = "/data/archives" # 实际环境从配置读取 volume_seq_str = str(volume_seq).zfill(3) file_seq_str = str(file_seq).zfill(2) # 目标目录：/data/archives/A001/2024/001/ target_dir = os.path.join(storage_root, fonds_code, str(year), volume_seq_str) os.makedirs(target_dir, exist_ok=True) # 新版文件名：档号 + 原始扩展名 file_code = f"{fonds_code}-{year}-{volume_seq_str}-{file_seq_str}" target_path = os.path.join(target_dir, f"{file_code}.{ext}") return target_path, file_code # 调用示例 path, code = build_archive_path("A001", 2024, 1, 1, "pdf") print(path) # /data/archives/A001/2024/001/A001-2024-001-01.pdf print(code) # A001-2024-001-01

这段代码里两个参数要注意：volume_seq和file_seq一定要在写入数据库前先查重，不能只靠数据库唯一索引报错了再回头改。因为如果路径已经算好、文件已经移动，再发现编号重复，处理起来就很麻烦。更好的办法是在一个事务里查重再插入，编号序列用数据库的SELECT ... FOR UPDATE或者 Redis INCR 来保证并发安全，不要让多个任务同时算出同一个编号。

3.2 借阅审批的状态机：让“申请—批准—归还”有据可查

借阅流程不复杂，但状态转换的细节很容易漏。我见过一套系统的借阅记录只有两个状态：“借出”和“归还”。结果审批环节的“待审批”“已拒绝”没有落库记录，档案员想查“上个月有哪些借阅申请被拒了”，只能翻聊天记录。这就是状态设计不完整。

完整的借阅状态至少要有五个：待审批、已批准、已拒绝、已归还、已逾期。其中“已逾期”不是一个独立状态，而是“已批准 + 应还日期小于今天”，在查询时动态计算即可，不需要单独更新数据库。这样设计的好处是，每天定时任务只需要扫描approve_status=1 AND should_return_date < CURDATE()，就能生成逾期清单，不用维护一个可能过期的冗余状态。

借阅还有一个容易漏的点：审批通过后，要不要临时开放文件下载权限？我的做法是，不在借阅表里塞权限字段，而是在审批通过时生成一个带有效期的下载令牌，存到单独的 token 表里。文件下载接口校验令牌和有效期，到期自动失效。这样比在文件表上改权限标记干净得多，而且可以细粒度控制“打印次数”或者“下载次数”。有些单位还要加水印，那就在生成下载链接时带上借阅人姓名，由文件服务在返回文件流时动态打水印。

如果是做 B/S 架构，借阅审批的接口路径可以这样设计：前端提交借阅申请 → 写入 borrow 表，状态置 0 → 审批人列表查询待审批记录 → 审批人点击批准或拒绝，更新 approve_status 和 approve_comment → 如果批准，异步生成下载令牌。这个流程里最应该写日志的是审批意见，因为档案借阅一旦出现问题，追溯责任靠的就是这串记录。

3.3 统计口径：为什么“案卷数、文件数、页数”经常和档案员手工台账对不上

系统上线后，最常见的一个矛盾是：档案员手里有一本手工台账，系统里导出报表，两边数字对不上。先别急着怀疑系统 bug，大多数情况是统计口径不一致。

台账上的“页数”是文件扫描时数出来的实体页数，系统里的page_count是档案员归档时手工填的或者扫描软件自动识别的页数。只要扫描软件把一张空白页识别成了两页，差异就产生了。台账上的“件数”可能包含“一文件多附件算一件”的规则，而系统里的file_count可能是“一份 PDF 算一件”，也可能把每个附件单独算了一件。这些口径问题，在需求阶段就要和档案员逐条确认，写进文档里，否则上线后就是无穷无尽的对账。

还有一个更隐蔽的坑：案卷表里的file_count和page_count是冗余字段。归档时先插入卷内文件记录，再用UPDATE archive_volume SET file_count=file_count+1的方式累加。但如果归档任务失败了、重跑了，累加就会重复。我的习惯是：归档时不要实时累加案卷表的计数，而是做完后统一执行一次统计 SQL，从卷内文件表反查汇总再更新案卷表。如下所示：

UPDATE archives_volume v SET file_count = (SELECT COUNT(*) FROM archives_file f WHERE f.volume_id = v.volume_id), page_count = (SELECT COALESCE(SUM(f.page_end - f.page_start + 1), 0) FROM archives_file f WHERE f.volume_id = v.volume_id);

这段 SQL 放定时任务里，每天凌晨跑一次。归档时只插入文件记录，不维护冗余计数，这样即使某次批处理中断，顶多是案卷表数字暂时不准，下次定时任务会修正，不会出现累加翻倍的问题。

4. 档案管理系统落地避坑：最容易翻车的五个现场

4.1 扫描件命名与目录挂接：文件传上去了，预览却打不开

现象：扫描员按“档号 + 顺序号”命名了一批 PDF，传到系统里，文件列表能看到记录，点击预览却一直转圈，最后报错“文件不存在或已损坏”。

原因：这批扫描件是从多台扫描仪导出的，部分 PDF 实际是 A3 横向扫描件。系统里的file_path存储时，宽度超过阈值的文件被转存到了另一个存储节点，而文件表里记录的路径还是上传后的临时路径。归档程序先写库、后移动文件，中间进程被运维 kill 掉，文件移动没完成，数据库记录却留下来了。

解决：归档流程调整为“先移动、后写库”，并且预览接口在返回文件流前先判断物理文件是否存在，不存在则直接返回明确的错误码，不要等前端转圈超时。另外，扫描仪导出的 PDF 要统一做一次“规范化”检查：文件能否正常打开、页数是否为 0、页面尺寸是否合理，不合格的文件在归档前就拦截下来。这个检查用pypdf或者系统命令pdfinfo都能做，别省这一步。

4.2 目录挂接与卷内顺序：文件顺序乱了，档号却是连续的

现象：档案员发现，某案卷里文件 03 和文件 04 在系统里显示的先后顺序，和纸质卷宗里的顺序相反，但档号编号却是连续的。

原因：批量挂接时用的是 Excel 导入，Excel 里的行顺序和实际扫描顺序不一致。录入员按扫描批次整理 Excel，扫描件是按物理顺序拍的，但 Excel 是按文件题名重新排过序的，导入程序直接按 Excel 行号生成了卷内顺序号，没有校验“卷内序号是否与原文页码顺序一致”。

解决：导入模板里增加“原文页码起止”字段，导入时用代码校验：前一行 PAGE_END 必须小于后一行的 PAGE_START，否则拒绝导入。目录挂接完成后，还要做一个抽查动作：随机挑两个案卷，用 PDF 的页码和系统里的 page_start/page_end 交叉比对，不一致就说明录入规则有问题。

4.3 借阅记录与权限边界：审批通过了，下载链接却能被转发

现象：借阅人把审批通过后的下载链接发给同事，同事也能直接下载文件，审批形同虚设。

原因：下载链接是固定的文件地址，只要 URL 不失效，任何人都能用。系统只在生成链接时校验了一次权限，后续访问不再校验登录态。

解决：下载链接必须和用户会话绑定。每次下载请求都要校验当前登录人是否就是借阅人，且链接本身加密带有效期。常见做法是生成一个随机 token 存数据库，设置过期时间，文件接口每次请求都查 token 是否有效、是否对应当前登录人。如果单位对安全要求更高，下载时动态打水印是最有效的补救手段——即使链接被转发，水印也能暴露转发者的工号。

4.4 浏览器兼容与插件依赖：Chrome 能预览，单位老电脑的 IE 打不开

现象：部分内网用户的电脑还是旧系统、老浏览器，新版 Chrome 能正常预览的 OFD 文件，在旧环境里直接白屏。

原因：预览组件用了较新的 Web API，旧浏览器不支持。很多单位的办公电脑系统更新滞后，不是技术难题而是管理问题。

解决：预览功能在设计时就要定一个最低浏览器版本。我一般建议做“双通道预览”：优先 HTML5 原生预览，不支持的浏览器自动降级为 PDF 下载预览。如果档案格式包含了 OFD，就得带一个独立安装的阅读器控件，并把安装包放到系统下载中心。关于控件安装失败的问题，多数是因为内网没配置控件白名单，让运维把控件域名加进安全例外即可。

4.5 元数据缺失：文件能存能看，就是搜不到

现象：按文件题名搜索，明明库里有这条记录，搜索引擎就是搜不出来。

原因：这里有个特例。多数系统用的是数据库 LIKE 查询，搜不到是编码问题——题名里混入了全角半角字符，比如“人事处”和“人事處”，搜索时用半角查全角记录当然匹配不上。另一个原因是只建了普通索引，没有建全文索引，长题名查询走 like 前缀匹配，结果集为空。

解决：搜索字段的录入环节就做标准化：全角转半角、统一大小写、去除首尾空格。全文检索单独建一个搜索索引表，把题名、责任者、文号、分类号拼接成一个文本字段，用全文索引或者外部搜索引擎处理。不要直接在原始表上做 like 检索，数据量超过十万条之后性能会明显下降。

5. 让这套系统真正省事的三个进阶技巧

5.1 OCR 与全文检索：把“扫描图片型 PDF”变成可搜的文字

档案系统上线一段时间后，用户最大的抱怨往往是“文件找到了，但里面是什么内容不知道”。老档案的扫描件是图片型 PDF，不能选中文字，更不能全文搜索。这时候就需要 OCR 处理。选型上要先确定数源：存量档案是分批扫描的，不可能一夜之间全部 OCR 完。我一般建议按“高借阅频次”的案卷优先处理，比如近三年的人事、合同类档案先做，年代久远的再逐步补。

OCR 引擎的选择和扫描质量强相关。扫描清晰的印刷体文件，开源引擎就够用；手写批注多的档案，识别率再高也救不回来，要允许人工校对流程。OCR 后的文字不要直接覆盖原始文件，单独存一个文本文件，放在和原始文件同名的.txt路径下，全文索引只索引这些文本。这样就算 OCR 结果有误，也不会影响原始文件完整性。

5.2 借阅台账与到期提醒：一个定时脚本替代人工催还

借阅逾期催还在很多单位是人工干的：档案管理员每个月翻一遍借阅登记本，打电话催。系统上线后，这件事可以用一段定时任务自动完成——每天上午扫描应还日期小于当前日期且状态为“已批准”的借阅记录，给借阅人发提醒消息，给档案员发汇总报表。

这个思路可以延伸到更多的日常检查：每周核对一次“归档文件物理路径是否缺失”，每月统计一次“零借阅的案卷清单”用于到期鉴定。定时任务的实现不必很复杂，服务器 crontab 加上一段脚本，或者系统内置的任务调度都能满足。关键是任务结果要能通知到人，不然脚本跑了一年没人看，等于白装。

5.3 长期保存的格式检查：别等光盘损坏才发现文件读不出来

长期保存是档案和普通文件最大的区别。普通的项目文件丢了可以重新生成，档案丢了就是永久损失。所以我有一个习惯：系统每季度做一次存储巡检，随机抽取一定比例的电子文件，重新计算文件哈希值，和入库时的原始哈希比对，不一致就说明存储介质开始劣化，需要迁移。

这个习惯来源于一次深刻教训。某单位做过一次数字化项目，扫描件刻录到光盘里，当时都能正常读取，两年后抽查发现部分光盘已经无法识别，连带着一批档案数据只能重新扫描。后来我就不再信任任何单一介质，硬盘、光盘、磁带各留一份，并且每年做一次恢复演练，确认备份真的能读出来。电子档案的核心不是“存进去”，而是“随时能拿出来”。

这个项目做下来，我最大的一个体会是：档案管理系统难的不是技术，是把档案员脑子里的那些约定俗成的规则——全宗怎么分、案卷怎么组、顺序怎么排、口令哪些术语不能混——一件件挖出来，变成表结构和校验逻辑。照着文档建表不难，难的是想清楚每一个字段背后对应的业务动作。希望这些实践能帮到你，让你少走一趟我走过的弯路。

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