档案数字化研发手记：我们的技术栈选择——档案系统前后端选型理由（含一次"炫技"的教训）

一、为什么专门聊技术栈

档案系统的技术栈选型，外面讨论很少，但踩坑很多。常见两种极端：

• 保守派：Java + SSH 老一套，稳定但开发效率低、招人难、界面老气；
• 激进派：什么都上最新的（微服务、K8s、前后端全分离、最新框架），结果部署复杂、维护成本爆炸、客户现场跑不起来。

我们经历过"激进派"的翻车，最后收敛到一套务实、好部署、够扩展的技术栈。这篇把选型理由讲透，给同行一个参考。

二、一次"炫技"的教训

早期一个项目，我们用了一堆"时髦"技术：微服务架构 + 消息队列 + 容器化 + 前后端全分离 + NoSQL。开发时很爽，结果：

1. 客户现场是内网，没有容器仓库，镜像搬不进去；
2. 现场服务器 16G 内存，微服务全家桶（网关、注册中心、各服务、消息队列、缓存）光空跑就吃 8G；
3. 客户 IT 只会部署 Tomcat WAR 包，我们的部署文档他们看不懂；
4. 出问题排查要跨好几个服务看日志，现场人员根本搞不定。

最后项目靠"降级版"（砍掉一半服务、合并部署）才上线。教训：技术栈不是给自己爽的，是给客户运维的。 档案系统客户普遍 IT 能力有限、环境受限（内网、信创、低配），"能现场跑起来、运维别太难"比"架构多先进"重要得多。

三、我们的技术栈（当前生产标准）

后端

选型	理由
Java（Spring Boot）	生态成熟、招人易、信创兼容性好（政务/国企客户主流）
单体部署（模块化解耦）	部署简单（一个 Jar/WAR），内部模块边界清晰（见第 17 篇）
PostgreSQL	关系型、支持 JSON、归档场景够用；信创环境可切达梦/人大金仓
MinIO（对象存储）	档案文件存储正解（见第 18 篇）
Elasticsearch	全文检索（见第 19 篇），独立部署
Redis	缓存、Session、分布式锁

前端

选型	理由
Vue 3 + Element Plus	国内生态成熟、开发效率高、组件全（表格、树、表单都是档案系统刚需）
不搞微前端	档案系统不需要；微前端部署复杂度对客户现场是负担

图像/OCR（Python 侧）

选型	理由
Python（独立服务）	OCR、图像处理生态最强（OpenCV、PaddleOCR）
图像处理/OCR 独立成服务	Java 负责业务，Python 负责重活，通过任务队列解耦（互不拖垮）

部署形态

业务服务（Spring Boot 单体）
  + 图像/OCR 服务（Python，独立进程）
  + PostgreSQL + Redis + MinIO + ES
  → 全部可装在一台 16G 服务器上（中小项目）
  → 高可用时各组件独立集群化

四、选型背后的四条原则

原则 1：部署复杂度是"一票否决项"

方案 A 很先进但现场装不上，方案 B 朴素但现场能跑——永远选 B。

档案客户环境普遍：内网、无外网、低配服务器、IT 能力一般、可能信创。任何需要"外网拉镜像""复杂编排""高级运维技能"的方案，先在选型阶段枪毙。

原则 2：信创兼容性提前想

政务/国企客户大概率要求国产化：国产 CPU/OS/数据库/中间件。选型时就要约束：

• Java + Spring Boot：信创兼容性好；
• 数据库 SQL 规范（少用方言）：达梦/人大金仓/openGauss 可切；
• 前端不依赖特定浏览器插件：国产浏览器（Chrome 内核）兼容。

原则 3：稳定 > 新潮

• 框架版本选"稳定版 + 社区活跃"的，不追最新大版本（等半年让社区踩坑）；
• 数据库用成熟产品，不冒险用"实验性功能"；
• 技术栈的"新"换不来档案客户一毛钱，稳定性才是。

原则 4：图像处理独立成服务

档案系统的重活（OCR、图像增强、批量转换）和业务系统耦合在一起，是性能灾难。Python 独立服务 + 任务队列：

• 重活不影响业务响应（异步队列）；
• Python 生态随便用（不污染 Java 工程）；
• 单独扩缩容（量大时图像服务加机器）。

五、为什么不用这些（我们的"排除清单"）

技术	排除理由
微服务全家桶	部署复杂度对档案客户是灾难（见第 17 篇）
K8s/容器编排	客户现场普遍不具备条件
NoSQL 当主库	档案数据强关系（全宗-门类-案卷-文件），关系型更合适
前后端全分离 + 微前端	过度设计，档案系统不需要
Python 全家桶（后端全 Python）	政务/信创生态 Java 更稳，且 Python 招人/运维在传统客户圈不占优
自研存储引擎	没有理由造轮子，对象存储已经够好

六、给同行的一句话

档案系统技术栈的核心不是"先进"，而是"客户现场能跑、团队能维护、信创能兼容、数据能长久"。我们踩过"炫技"的坑，最后明白：技术在档案系统里是手段，不是卖点——客户为"档案管得好"买单，不为"技术栈潮"买单。

七、小结

• 一次"炫技"的教训：先进技术栈在档案客户现场可能直接翻车；
• 我们的技术栈：Java 单体 + PG + MinIO + ES + Redis + Vue3，图像/OCR 独立 Python 服务；
• 四条原则：部署复杂度一票否决、信创提前想、稳定 > 新潮、图像处理独立服务；
• 排除清单：微服务、K8s、NoSQL 主库、微前端——不是不好，是不适合档案场景；
• 技术是手段不是卖点，客户为"管得好"买单。