追加写入的物理落盘时滞源于os缓存与磁盘写入的延迟；append必须与write组合使用，搭配dsync或force(false)可确保数据同步落盘，严禁混用truncate_existing。
追加写入时的物理落盘时滞，本质是操作系统缓存层与磁盘实际写入之间的延迟。StandardOpenOption 本身不直接控制落盘时机，但它能配合底层行为和显式同步操作，显著缩短或规避时滞风险。
APPEND 必须搭配 WRITE 才生效
单独使用 StandardOpenOption.APPEND 会抛出异常（如 NoSuchFileException），因为 APPEND 是写模式的修饰符，不是独立打开方式。必须与 WRITE 显式组合：
- 错误写法：`FileChannel.open(path, APPEND)` → 报错，通道无法建立
- 正确写法：`FileChannel.open(path, WRITE, APPEND)` → 确保追加语义，且系统知道你要写
用 DSYNC 避免元数据缓存拖慢落盘
APPEND 模式下，每次写入默认只保证数据进入内核页缓存，不强制刷盘。若需确保“追加内容已真正写入磁盘”，应添加 DSYNC：
- DSYNC 保证写入的数据块（不含文件大小、时间戳等元数据）同步落盘
- 比 SYNC 轻量（SYNC 同时刷数据+元数据），更适合高频追加场景
- 示例：
FileChannel.open(path, WRITE, APPEND, DSYNC)
避免 TRUNCATE_EXISTING 干扰追加逻辑
TRUNCATE_EXISTING 会清空文件内容，与 APPEND 完全冲突。若误加入该选项：
- 文件被截断为 0 字节，后续 APPEND 实际变成从头写入
- 看似追加，实则覆盖，且失去原有数据，落盘行为也完全改变
- 务必检查选项组合中是否混入 TRUNCATE_EXISTING 或 CREATE_NEW（后者在文件存在时直接失败）
手动调用 force() 弥补选项局限
即使用了 DSYNC，某些 JVM 或文件系统实现仍可能因缓冲策略导致微秒级偏差。关键日志类场景建议在每次 append 写入后主动刷盘：
-
channel.write(buffer)后立即调用channel.force(false) -
false表示只刷数据（等效 DSYNC），true才刷元数据（等效 SYNC） - 注意：force() 是阻塞调用，需权衡吞吐与可靠性
