FastAPI + SQLite + RapidOCR 离线识别,从零搭建维权线索管理系统 一个真实落地的本地部署方案:Excel 线索自动解析入库 + 营业执照 OCR + 全文检索 + 多账号协作,已稳定承载 6.9 万+ 条线索、381 份文件、3748 张证照截图。

如果你是做诉讼维权方向的团队,大概率会遇到这样的场景:
这些问题,本质上是「非结构化的离线表格数据」无法被统一检索和追溯。本文给出一个轻量、零外部依赖、可单机跑通、可平滑上云的解决方案——维权线索管理系统。
本文所有代码与方案均为真实生产实践,非 demo。文末附完整技术架构与避坑清单。
需求 | 选型 | 理由 |
|---|---|---|
Web 后端 | FastAPI + Uvicorn | 异步高性能,自动生成 OpenAPI 文档,部署轻量 |
数据库 | SQLite(WAL 模式) | 单机零运维,6.9 万条记录查询毫秒级;一个文件随迁随走 |
认证 | JWT + bcrypt | 无状态鉴权,适配多账号与后续上云 |
Excel 解析 | openpyxl + xlrd | 兼容 .xlsx 与老 .xls 两种格式 |
图片 OCR | RapidOCR(onnxruntime) | 离线可用、中文识别效果好,无需调云端 API |
文件监控 | watchdog | 目录新增/修改自动触发解析入库 |
前端 | 原生 HTML/CSS/JS 单页应用 | 零构建、零框架依赖,改完即用 |
核心原则只有一条:本地优先、离线优先、可控优先。维权数据涉及商业敏感信息,不适合直接丢给云端 OCR 服务或第三方数据库。

整条数据链路是这样的:

维权线索表往往不是规整的「一行表头 + 一行数据」,实际会碰到:
为此,系统内置了一张「字段别名映射表」,例如「店铺名称」列,能自动匹配 店铺名称 / 店铺 / 店名 / APP名称 等多种写法;「盗版经营公司」匹配 盗版经营公司 / 经营主体 / 经营公司。未映射的列不会丢,统一保留在「原始数据」字段里,同样可被检索。
关键设计:.xls 老格式文件先复制副本再转换,绝不改动用户的原始文件——维权证据文件一旦被污染,后果不堪设想。
表格里内嵌的营业执照截图,是整个线索里最有价值的字段之一——它能直接锁定侵权主体。系统在解析时自动提取这些内嵌图片,交给 RapidOCR 做离线识别:
这是体验提升最明显的一环。配好监控目录后,团队只需把新的线索表丢进指定文件夹,系统自动:
监控目录支持两种形态:本机路径直接填;同事电脑的文件夹先设 Windows 共享,再填 \\IP\共享名 网络路径,系统会自动切换为轮询监控。
检索是这套系统的灵魂。支持:
某出版社 拼多多 一次定位到指定平台上的侵权店铺。所有接口需登录(JWT)。两种角色:
满足 2~10 人团队的分工与数据隔离需求。
针对「同一份线索表反复更新」的场景,提供文件比对能力:比对结果统一导出到指定的「比对·团队处理」区域,方便团队对增量线索做集中处理。


形态 | 做法 |
|---|---|
本机单机 | 直接运行,初次启动自动全量扫描监控目录 |
局域网共享 | main.py 中 host 改为 0.0.0.0,防火墙开放 8300 端口 |
迁移上云 | 整个 clue-system 目录 + Python 环境迁过去即可,SQLite 在 data/ 目录随迁;数据备份只需拷贝 data/ |
\\IP\共享名 网络共享路径,别填成别的电脑的本地路径。本文的「文件监控 → 解析入库 → OCR → 全文检索 → 多账号协作」架构,本质是一个通用离线文档智能检索引擎,稍作改造即可复用于:
这套系统的价值不在用了多「炫」的技术,而在于把一个高频、重复、易错的维权排查流程,变成了「丢文件进去就能查」的自动化闭环。从线索的稳定运行来看,SQLite + FastAPI + 离线 OCR 的轻量组合,完全扛得住中小团队的真实业务量。
如果你也在做类似的版权保护或数据治理工作,欢迎交流。文中的字段映射、OCR 离线化、网络共享监控这三处,是踩坑后反复打磨出来的,希望能帮你少走弯路。
(本文为真实项目实践整理,涉及的具体账号、目录、数据规模均为实际运行数据。)
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。