京公网安备11010502063487号本机真实验证object类型拍平数组导致的跨对象假阳性匹配问题，以及nested类型查询语法的硬性要求。
本机真实验证超过ignore_above长度的值不会被拒绝写入也不会被截断，而是整个被排除在倒排索引外，变得不可精确查询。
本机真实发现index:false单独使用时term查询仍能命中（doc_values提供后备路径），必须同时关闭doc_values才会真正不可查询。
本机真实对比开启和关闭norms时，field length normalization如何让短文档比含同一个词的长文档得分更高，以及norms写入后不可原地修改的限制。
本机真实关闭_source后验证stored_fields和docvalue_fields仍能独立取到字段值，但Update API会因缺少_source而彻底失效。
本机真实验证多个Index Template匹配同一索引名时priority数值越大越优先，并意外撞上ES内置系统模板导致的相同priority创建拒绝机制。
快照机制实测:每 snapCount/2~snapCount 个事务随机一次(504~963);20 万 znode 的快照 54 MiB、写 163 ms;后台快照不影响前台写延迟;gz 压缩使 10 万 znode 的快照从 27.0 MiB 降到 1.1 MiB(写 653 ms)。
快照频率与事务日志增长实测:不清理时 6 万次写产生 38 个快照(145 MiB)、81 个日志文件(表观 5 GiB、实占 13 MiB);PurgeTxnLog -n 3 清理后剩 3 个快照;autopurge 配置启动时即执行一次。
事务日志预分配与 fsync 实测:默认同步写 p50 3.02 ms,forceSync=no 降到 0.27 ms;fsync 慢时日志出现「fsync-ing the write ahead log … took 5ms」;异步写时平均批大小 15.0937,20000 个事务只多出 1044 次 fsync。
磁盘类型与提交延迟:macOS 上普通 os.fsync 中位 0.020 ms、F_FULLFSYNC 中位 2.96 ms;ZooKeeper 同步写 p50 3.01 ms(fsync 平均 2.1277 ms),去掉 fsync 后 0.32 ms——写延迟 ≈ fsync 耗时 + 约 0.3 ms。
磁盘满时的服务行为实测(24 MiB 小盘):写入 174 个 100 KiB znode 后失败,服务端因「No space left on device」自己退出(退出码 0);腾出 6 MiB 重启仍因写不下启动快照而失败(退出码 10,留下写了一半的快照);搬到 256 MiB 盘后数据完整。
文件损坏后的启动失败实测:最新快照截断 / 清零 → 回退旧快照 + 回放日志,数据不丢;无快照只剩日志 → 默认拒绝启动(trust.empty=true 放行);日志内容被改坏 → CRC check failed 拒绝启动;断电式撕裂写 → 丢弃不完整的最后一条正常启动;集群里清空数据目录可重新同步。