GridFS查询不准确主因是从节点读取延迟导致元数据与块数据不一致；应强制readPreference="primary"、禁用retryReads、避免混合读偏好，并用replSetGetStatus确认同步延迟。
查询结果不准确，先看是不是从节点读到了旧数据
GridFS 查询返回陈旧或缺失的文件，常见原因是驱动默认用了 ReadPreference.SECONDARY 或 ReadPreference.NEAREST，而从节点同步延迟导致 fs.files 元数据还没追上——尤其在写完立刻查、或主节点刚切换后最明显。
这不是 GridFS 特有 bug，是 MongoDB 读偏好机制的正常行为；但 GridFS 的两阶段读（先查 files 再查 chunks）会让这种不一致更易暴露：files 记录已存在，但对应 chunks 还没复制完，结果 openDownloadStream() 找不到块、返回空流或报错。
- 用
db.runCommand({ replSetGetStatus: 1 })查各节点optimeDate差值，确认延迟是否 >1s - 临时强制主节点读：
bucket.find({ filename: "x.pdf" }, { readPreference: "primary" }) - Node.js 驱动中，连接字符串加
&readPreference=primary最彻底，避免每个查询都手动设 - 别依赖
readConcern: "majority"来“修复”这个问题——它只保证读到已多数提交的数据，不解决延迟本身；且 GridFS 的files和chunks跨集合，无法用事务包住
为什么 findOne() 返回 undefined，但文件明明存在
表面是查不到，实际常是重试 + 读偏好叠加导致的竞态：驱动在 SECONDARY_PREFERRED 下发起 findOne，第一次去从节点查 fs.files 没命中，触发重试，第二次连上主节点时，fs.chunks 还没写完（或网络丢包），最终组合失败返回 undefined。
这类问题在高并发上传+立即下载场景下高频出现，日志里往往看不到报错，只有空响应或超时。
- 禁用自动重试：
bucket.findOne({ filename: "x.pdf" }, { retryReads: false }) - 显式指定
readPreference: "primary"，并加maxTimeMS: 5000防卡死 - 不要用
findOne()做关键路径的文件存在性校验；改用find().limit(1).toArray()+ 显式判空，便于加日志定位哪一步失败 - 如果业务允许小延迟，上传后 sleep(100ms) 再查——比调优读偏好更简单可靠
Range 请求返回 200 而非 206，说明读偏好干扰了 HTTP 头解析
客户端发了 Range: bytes=1024-2048，服务端却返回完整文件（200）+ 全量 body，不是部分响应（206）。这通常不是代码漏解析 Range 头，而是底层 openDownloadStream() 因读偏好选到不同节点，导致元数据（files 中的 length 字段）和实际块数据（chunks）不匹配，驱动 fallback 到全量读取逻辑。
- 必须统一读节点：
bucket.openDownloadStream(id, { start: 1024, end: 2048 }, { readPreference: "primary" }) - 检查
files文档里的length是否和你传的end值合理（比如end > length会静默截断，不报错也不发 416） - Node.js 中若用
stream.pipe(res)，确保res已设好Status: 206和Content-Range头——驱动不自动帮你填 HTTP 头
真正难排查的是混合读偏好场景
有些服务把 GridFS 查询混在普通集合操作里，比如先查 users 表拿用户权限，再查 fs.files 拿文件。这时如果两个查询用了不同 readPreference（一个配 primary，一个配 secondary），就可能出现“用户存在但文件查不到”的假象——其实是权限查的是主节点，文件查的是延迟 2s 的从节点。
这种问题不会报错，监控也难定位，只能靠全链路 trace 日志里打上每个查询的实际节点 host 和 optimeDate。
