档案系统的技术栈选型，外面讨论很少，但踩坑很多。常见两种极端：
我们经历过"激进派"的翻车，最后收敛到一套务实、好部署、够扩展的技术栈。这篇把选型理由讲透，给同行一个参考。
早期一个项目，我们用了一堆"时髦"技术：微服务架构 + 消息队列 + 容器化 + 前后端全分离 + NoSQL。开发时很爽，结果：
最后项目靠"降级版"（砍掉一半服务、合并部署）才上线。教训：技术栈不是给自己爽的，是给客户运维的。 档案系统客户普遍 IT 能力有限、环境受限（内网、信创、低配），"能现场跑起来、运维别太难"比"架构多先进"重要得多。
| 选型 | 理由 |
|---|---|
| Java（Spring Boot） | 生态成熟、招人易、信创兼容性好（政务/国企客户主流） |
| 单体部署（模块化解耦） | 部署简单（一个 Jar/WAR），内部模块边界清晰（见第 17 篇） |
| PostgreSQL | 关系型、支持 JSON、归档场景够用；信创环境可切达梦/人大金仓 |
| MinIO（对象存储） | 档案文件存储正解（见第 18 篇） |
| Elasticsearch | 全文检索（见第 19 篇），独立部署 |
| Redis | 缓存、Session、分布式锁 |
| 选型 | 理由 |
|---|---|
| Vue 3 + Element Plus | 国内生态成熟、开发效率高、组件全（表格、树、表单都是档案系统刚需） |
| 不搞微前端 | 档案系统不需要；微前端部署复杂度对客户现场是负担 |
| 选型 | 理由 |
|---|---|
| Python（独立服务） | OCR、图像处理生态最强（OpenCV、PaddleOCR） |
| 图像处理/OCR 独立成服务 | Java 负责业务，Python 负责重活，通过任务队列解耦（互不拖垮） |
业务服务（Spring Boot 单体）
+ 图像/OCR 服务（Python，独立进程）
+ PostgreSQL + Redis + MinIO + ES
→ 全部可装在一台 16G 服务器上（中小项目）
→ 高可用时各组件独立集群化
方案 A 很先进但现场装不上，方案 B 朴素但现场能跑——永远选 B。
档案客户环境普遍：内网、无外网、低配服务器、IT 能力一般、可能信创。任何需要"外网拉镜像""复杂编排""高级运维技能"的方案，先在选型阶段枪毙。
政务/国企客户大概率要求国产化：国产 CPU/OS/数据库/中间件。选型时就要约束：
档案系统的重活（OCR、图像增强、批量转换）和业务系统耦合在一起，是性能灾难。Python 独立服务 + 任务队列：
| 技术 | 排除理由 |
|---|---|
| 微服务全家桶 | 部署复杂度对档案客户是灾难（见第 17 篇） |
| K8s/容器编排 | 客户现场普遍不具备条件 |
| NoSQL 当主库 | 档案数据强关系（全宗-门类-案卷-文件），关系型更合适 |
| 前后端全分离 + 微前端 | 过度设计，档案系统不需要 |
| Python 全家桶（后端全 Python） | 政务/信创生态 Java 更稳，且 Python 招人/运维在传统客户圈不占优 |
| 自研存储引擎 | 没有理由造轮子，对象存储已经够好 |
档案系统技术栈的核心不是"先进"，而是"客户现场能跑、团队能维护、信创能兼容、数据能长久"。我们踩过"炫技"的坑，最后明白：技术在档案系统里是手段，不是卖点——客户为"档案管得好"买单，不为"技术栈潮"买单。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。