事情本身不复杂，线索都在日志里。文档同步任务用 getmtime 与上次记录比较，跑一个月后发现十几份更新过的制度没进库，文件修改时间与记录差不到一秒。
第一反应是「记录的是本地时间，容器与宿主时区不同导致偏移」，验证下来不成立。
这类报错背后常见的原因有几处，逐个排除就行。文件系统时间戳精度到秒，同秒修改判断不出差异。还有一种是批量拷贝会保留源文件 mtime，本地时间反而更旧。
少数情况下是只比 mtime，不比文件大小与内容哈希。
动手时先看同目录文件的时间戳精度
python -c "import os;print(os.stat('policy.docx').st_mtime_ns)"接着改成 mtime 加 size 双条件判断
python -c "import os;s=os.stat('policy.docx');print(s.st_mtime_ns,s.st_size)"然后对变更文件算内容哈希再比对
python -c "import hashlib;print(hashlib.sha256(open('policy.docx','rb').read()).hexdigest()[:16])"末了把同步游标存成纳秒并落库
python -c "import json;print(json.dumps({'cursor_ns':1730000000123456789}))"改完先别撤，确认这几项。下一轮同步能检出全部 13 份更新文件，紧接着重跑一轮变更数为 0，向量库文档数与原目录一致。
提醒一点。增量同步的游标精度要跟着文件系统走，拷贝流程保留 mtime 的场景下哈希校验比时间戳可靠。这类问题最好一次改到位，反复小改反而容易把原因搅混。