GridFS本身不支持PDF内容搜索，必须借助外部索引引擎：先用PyMuPDF（fitz）从GridFS读取并解析PDF文本，再将清洗后的文本及文件ID写入Elasticsearch等支持全文检索的系统，并确保更新PDF时同步重建索引。
GridFS本身不支持PDF内容搜索，必须借助外部索引引擎
MongoDB GridFS只负责存储和分块管理大文件（如PDF），files集合存元数据，chunks集合存二进制分块——它没有文本解析能力，更不会自动提取PDF文字。直接在GridFS上执行$text查询或正则匹配chunk.data，结果一定是空的或完全不可靠。
真正可行的路径只有一条：把PDF从GridFS读出 → 用PDF解析库提取纯文本 → 将文本和原始文件ID一起写入支持全文检索的外部系统（如Elasticsearch、Meilisearch或PostgreSQL的tsvector）。
用Python + PyPDF2/fitz提取PDF文本时要注意编码与结构问题
不是所有PDF都能被无损提取。扫描件（图片型PDF）会返回空字符串；加密PDF可能抛PdfReadError；含复杂表格或多栏排版的PDF，文字顺序容易错乱。别默认用PyPDF2.PdfReader——它对现代PDF兼容性差，推荐优先用fitz（即PyMuPDF）：
import fitz
doc = fitz.open(stream=pdf_bytes, filetype="pdf")
text = ""
for page in doc:
text += page.get_text() # 比PyPDF2更稳定，支持更多PDF版本-
page.get_text("text")返回线性文本（适合搜索） -
page.get_text("blocks")返回带坐标的文本块（适合结构化处理） - 务必捕获
fitz.FileDataError（损坏PDF）和fitz.EmptyFileError（空文件） - 提取后建议用
re.sub(r"\s+", " ", text).strip()清理多余空白，避免索引膨胀
Elasticsearch索引设计要关联GridFS的_id并控制字段长度
不能把整个PDF文本塞进一个content字段然后开match查询——长文本会导致分词爆炸、内存占用高、响应变慢。正确做法是：
- 索引文档结构包含：
{"gridfs_id": "<ObjectId>", "filename": "report.pdf", "content_preview": "前2000字符...", "full_text_hash": "sha256..."} -
gridfs_id字段设为keyword类型，用于精确回查MongoDB：db.fs.files.findOne({_id: ObjectId("...")}) - 禁用
content_preview的index: true（除非真需要搜预览片段），重点给full_text_hash建keyword索引做去重 - 实际搜索走另一个轻量级
search_content字段，它只存清洗后的关键词（比如用jieba抽关键名词+动词），而非全文
更新PDF时必须同步触发索引重建，否则搜索结果过期
GridFS没有内置hook机制。如果你用bucket.upload_from_stream()覆盖同名文件，旧_id已失效，但Elasticsearch里还留着对应文档——下次搜到的就是404文件。
必须自己实现原子性更新逻辑：
- 先调
bucket.find_one({"filename": "a.pdf"})拿到旧_id - 用该
_id调es.delete(id=...)删旧索引 - 再
upload_from_stream上传新PDF，拿到新_id - 提取新文本，构造新文档写入ES，
id设为新_id字符串（不是ObjectId对象） - 整个流程包在try/except里，失败则回滚ES删除操作（记录日志，人工介入）
最容易被忽略的是PDF元数据变更（比如修改了title字段但没重提文本）——只要PDF二进制变了，就必须重新解析、重新索引，不能只比对filename或uploadDate。
