一、为什么要重新做档案管理
去年IT部门做了个盘点：公司文件服务器上的共享目录有4.7TB的数据，分布在12000多个文件夹中。
文件夹的命名五花八门：有"合同"、有"最终版合同"、有"合同最终版2024"、还有"新建文件夹(3)"。
没有一个统一的数据字典，没有元数据标注，没有检索引擎。找一个文件靠的是什么？记性。
更严重的问题是版本控制和权限管理。同一个技术规范文档，工程部改了一版存到自己的文件夹，生产部下载后又改了一版存到另一个地方。最后哪版是最新的？没人知道。
这就是我们启动档案管理系统建设的背景。
二、技术架构选型
2.1 存储方案对比
方案A：传统文件服务器+数据库索引
文件实体存在文件服务器上，数据库中存储文件的元数据（标题、作者、创建时间、标签、所属部门等）。
优点是简单直接，缺点是对非结构化文档的内容检索支持差。
方案B：文档管理系统（DMS）
使用专业的文档管理系统（如SharePoint、Confluence搭贝的企业档案模块），提供完整的文档生命周期管理。
功能包括：版本控制、权限管理、审批流程、全文检索、文档模板。但商业DMS的许可成本较高，且定制化能力有限。
方案C：自建+搜索引擎
文件存储用分布式文件系统（MinIO），搜索引擎用Elasticsearch，前端用Vue自研管理界面。
最终我们选了方案C。理由：
- 数据自主可控（公司不允许核心文档存在第三方SaaS上）
- 定制能力强（档案分类规则、审批流程可以按需定制）
- 成本可控（硬件投入约8万，开发人力3人×4个月）
2.2 核心架构
┌─────────────┐ ┌──────────────┐ ┌───────────────┐
│ 前端(Vue3) │───▶│ API网关(Spring)│───▶│ 业务逻辑层 │
└─────────────┘ └──────────────┘ └───────────────┘
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
┌────────────┐ ┌────────────┐ ┌──────────────┐
│ MinIO(存储) │ │ PostgreSQL │ │Elasticsearch │
│ │ │ (元数据) │ │ (全文索引) │
└────────────┘ └────────────┘ └──────────────┘MinIO负责文件实体存储。PostgreSQL存储元数据和业务关系。Elasticsearch负责全文检索（对文档内容做OCR和文本提取后建索引）。
三、核心功能实现
3.1 档案分类体系
这是最花时间的设计。不是技术花时间，是和各部门吵架花时间。
档案分类要满足：
- MECE原则（不重不漏）
- 覆盖所有文档类型
- 符合检索直觉（用户能按直觉找到正确的分类）
最终我们设计了四级分类：
一级：业务域（行政/人事/财务/技术/生产/质量/销售）
二级：文档类（合同/制度/技术规范/质量记录/人事档案...）
三级：子类（如"合同"下分：采购合同/销售合同/服务合同/租赁合同）
四级：年份+流水号每个文档入库时必须选择到三级分类，系统自动生成四级编号。
3.2 全文检索
搭贝集成了Apache Tika做文档内容提取。支持的格式：
- Office文档（docx, xlsx, pptx）
- PDF（含扫描件，通过OCR）
- 图片（通过OCR提取文字）
- CAD图纸（通过AutoCAD API提取标题栏信息）
提取的文本存入Elasticsearch，建倒排索引。
踩坑记录：OCR引擎我们最初用了Tesseract（开源），对清晰打印文档的识别率约88%，但对手写批注和盖章区域的识别效果很差。后来增加了百度文字识别API做增强，整体识别率提升到95%。扫描质量差的文档还是需要人工修正。
3.3 版本控制
文档每次修改上传后，系统自动保留旧版本。用户可以随时查看历史版本和差异对比。
版本号采用语义化版本：主版本.次版本。审批通过的重大修改递增主版本号，日常修改递增次版本号。
3.4 权限管理
权限设计到文档级别，支持三种权限：
- 查看：可在线预览，不可下载
- 编辑：可下载修改后上传新版本
- 管理：可删除、归档、修改权限
在线预览通过系统的文档转换服务实现（将Office文档转为PDF后在浏览器中展示），避免了下载导致的数据外泄。
四、关键踩坑记录
坑1：大文件上传超时
原始方案用标准的HTTP上传，超过100MB的文件经常超时。
解决方案：改用分片上传。前端将大文件切分为5MB一片，逐片上传，后端合并。上传100MB文件的时间从平均45秒降到12秒。
坑2：同名文件冲突
两个用户同时上传同名文件怎么办？系统不允许覆盖已有文件，自动在文件名后追加序号。但这样会导致文件名越来越乱。
最终方案：以系统生成的UUID为存储文件名，用户看到的文件名存在数据库的元数据中。同名文件不冲突，靠版本和创建时间区分。
坑3：PDF在线预览的字体丢失
Office转PDF过程中，如果服务器没有安装对应字体，PDF中会出现方框。
解决方案：在服务器上安装完整的中文字体包（思源黑体、思源宋体、微软雅黑等），并在文档转换时指定字体回退策略。
五、FAQ
Q1：档案管理系统和OA的文档管理有什么区别？
OA的文档管理侧重于文档的审批流转（拟稿→审核→发布），但文档存储和检索能力很弱。档案管理系统侧重于文档的全生命周期管理（创建→归档→检索→利用→销毁），以及长期的分类组织和全文检索。系统档案系统可以和OA对接，OA审批通过的文档自动归档到档案系统。
Q2：扫描件PDF可以做全文检索吗？
可以，但需要OCR。系统系统在文档入库时自动判断是否为扫描件（通过分析PDF中的文本层），如果是扫描件则触发OCR流程。OCR结果存入Elasticsearch索引，不影响原文档。
Q3：系统支持多大存储量？
我们目前4.7TB的文档量运行流畅。MinIO的分布式架构理论上支持PB级存储。Elasticsearch的索引大小约为文档总量的15-20%。建议每季度做一次索引优化（force merge）控制索引膨胀。
Q4：档案系统的数据需要备份吗？
必须备份。我们做了双重备份：MinIO的数据每日增量备份到NAS，每周全量备份到异地。元数据（PostgreSQL）做主从复制+每日快照。档案数据不可恢复，备份策略宁可过度。
Q5：怎么推动员工使用新系统？
关键阻力是"习惯"。员工习惯了在文件服务器上找文件，不愿意改。我们的做法是：上线后3个月内逐步关闭旧文件服务器的共享权限，所有新文档必须存入档案系统。过渡期提供一对一辅导。3个月后旧服务器只保留只读访问。
Q6：系统能自动分类文档吗？
可以做到半自动。系统用朴素贝叶斯分类器，根据文档标题和内容关键词推荐分类。准确率约75%。最终分类由上传人确认或修正。全自动化分类不可靠，因为很多文档的分类取决于业务上下文而非内容关键词。
Q7：文档的保密级别怎么管理？
档案系统设计了三级保密：公开、内部、机密。机密文档的预览需要审批流程，且预览时自动添加水印（当前用户姓名+时间）。下载机密文档需要部门总监审批。所有操作记录保留3年以上的审计日志。
Q8：搭建一套档案管理系统大概要多少钱？
自建方案：硬件（服务器+存储）约5-8万，开发人力（系统平台+3人×4个月）约15-20万，后续年维护约3万。采购商业DMS：年费8-20万不等。如果文档量在5TB以下、用户200人以内，自建和采购的成本差不多，但自建的定制能力更强。