文档移动会直接拉高磁盘io，因其强制执行删除旧文档、插入新文档、重写索引三项磁盘操作；预填充必须用真实长度占位，空值无效；验证需通过db.collection.stats()比对avgobjsize与预估字节数。
为什么文档移动会直接拉高磁盘IO
Document Moving 不是“偶尔慢一下”，而是每次触发都强制执行删除旧文档 + 插入新文档 + 重写所有相关索引项。WiredTiger 引擎下，这三步全部走磁盘路径：journal 刷盘、page write、B-tree 分裂。实测中，moves 指标每秒超 5 次，iostat -x 1 的 w/s 就会翻倍，await 常突破 30ms。
预填充字段必须写满长度，空值或{}完全无效
MongoDB 只按 BSON 序列化后的实际字节数分配空间，{ profile: {} } 仅占约 5 字节，后续塞进 avatar URL 和 bio 文本后必然超限移动。真正有效的预填充要逼近预期上限：
- 用固定长度字符串占位：
"avatar": "https://placeholder.example.com/1000charlongurl..."（确保长度接近真实 URL 上限） - 数组字段不能留空：
"tags": ["tag1", "tag2", "tag3", "...", "tag50"]（填满预期最大数量） - 嵌套结构必须展开写全：
{ profile: { avatar: "", bio: "", tags: [], last_updated: ISODate("1970-01-01") } }，而非{ profile: {} }
如何验证预填充是否生效
光看插入语句没用，得查引擎层反馈：
- 执行
db.collection.stats()，对比avgObjSize和你预填充时估算的字节数，偏差应 - 运行
db.runCommand({ serverStatus: 1 }).metrics.record.moves，持续观察该值是否趋近于 0（注意：需在更新高峰期测） - 用
db.collection.find().explain("executionStats")查executionStats.nMoved，非零即说明某次 update 还是触发了移动
定长设计在现实中几乎不可行
想靠字段类型硬控长度？UTF-8 下中文、emoji、控制字符字节长度不一，String.length 在 JS 层面和 BSON 字节长度完全不是一回事。例如："a" 是 1 字节，"??" 是 14 字节（含零宽连接符），MongoDB 只认后者。Buffer 类型虽可定长，但牺牲了可读性与索引能力，且无法解决数组/嵌套文档动态增长问题。真正能落地的只有“结构预填充 + 监控校准”这一条路。
