S27-B03 · 文件上传与文档处理全链路

适用读者：要做"大文件上传 → 解析 → 检索"的人。
前置：S01-B03（工具链）、S13-B01（检索）。
覆盖旧文：562(624) 567(325) 561(405) 194(263) + 相关 = 1,775 点。
覆盖扩展：E-S27-004（分片上传三要素）、E-S27-010（OCR 预处理）。
上一篇：S27-B02 · 顺畅使用：配置、Skills、规范与反模式
下一篇：S27-B04 · 微信生态。

1. 一句话结论

上传链路的可靠性来自三件事：分片（可续传）、校验（内容完整）、幂等（重复上传不产生多份）。

客户端切分 → 逐片上传（带序号）→ 服务端落临时存储 → 全部到齐后合并 → 校验（hash）→ 入库

2. 分片上传三要素（E-S27-004）

要素	作用	缺失后果
分片序号 + 总数	支持断点续传	失败要重传全部
每片校验（hash）	检测损坏	合并出坏文件
合并幂等	防重复合并	多份副本/覆盖

判据："上传中断后，用户要重传整个文件吗？" 要 → 分片没做好。

3. 文档处理链路（A-567）

上传 → 类型识别（Tika）→ 文本抽取（PDF/Office）→ OCR（扫描件）→ 清洗 → 分块 → 向量化

环节	工具	注意
类型识别	Apache Tika	别只看扩展名
文本抽取	对应解析器	表格/图片丢失（S20-B02）
OCR	PaddleOCR 类	需预处理（倾斜/低分辨率）
分块	递归/句子（S20-B02）	块要能独立表达

4. OCR 的预处理（E-S27-010）

预处理	效果
去噪/二值化	提升识别率
倾斜校正	减少断行错误
分辨率提升/缩放	小字提升明显
区域裁剪	只识别关键区域

"为什么 OCR 常不如预期"：多数失败在预处理，不在模型。

5. 安全与成本

风险	措施
恶意文件（超大/压缩炸弹）	大小与页数上限
类型伪装	内容嗅探（Tika）
存储成本	原文件与解析结果分级存储

6. 五个误区

误区	真相
"分片只影响速度"	影响续传与可靠性
"看扩展名判断类型"	可能伪装
"OCR 直接上就行"	预处理决定上限
"解析一次就够"	解析结果要可重建
"大文件直接传"	易失败且不可续

7. 自检

上传链路五步？
分片三要素各解决什么？
文档处理链路的五个环节？
OCR 预处理四项？
三个安全风险与措施？

8. 下一篇

S27-B04 · 微信生态：扫码登录与支付

文档讲完，下一篇讲微信扫码登录的 SSE + 半长连接怎么实现。

本篇属于系列《S27 · AI 辅助后端工程实战》。旧文来源：A-562/567/561/194 + 相关卡；扩展点 E-S27-004/010。