Files.newByteChannel()的标准选项组合需按需组合StandardOpenOption枚举值：只读用READ；覆盖写用WRITE+CREATE+TRUNCATE_EXISTING；追加用WRITE+CREATE+APPEND；读写用READ+WRITE+CREATE；注意APPEND与TRUNCATE_EXISTING互斥，WRITE必须搭配CREATE或CREATE_NEW。
Files.newByteChannel() 的标准选项组合怎么写
直接用 Files.newByteChannel() 时，不传 OpenOption 参数默认只读，想写或追加必须显式指定。核心就是组合 StandardOpenOption.READ、StandardOpenOption.WRITE、StandardOpenOption.CREATE 这几个——它们不是互斥的，可以同时传多个。
常见组合示例：
- 只读：仅
StandardOpenOption.READ - 覆盖写（清空重写）：
StandardOpenOption.WRITE+StandardOpenOption.CREATE+StandardOpenOption.TRUNCATE_EXISTING - 追加写：
StandardOpenOption.WRITE+StandardOpenOption.CREATE+StandardOpenOption.APPEND - 读写并存（如随机读写）：
StandardOpenOption.READ+StandardOpenOption.WRITE+StandardOpenOption.CREATE
注意：APPEND 和 TRUNCATE_EXISTING 不能共存，否则抛 IllegalArgumentException；WRITE 必须搭配 CREATE（或 CREATE_NEW）之一，否则文件不存在时会报 NoSuchFileException。
为什么用 APPEND 时 position() 总是无效
APPEND 模式下，所有写入操作自动跳转到文件末尾，无论你调用 channel.position(n) 多少次，下一次 write() 仍从末尾开始。这不是 bug，是规范行为——APPEND 的语义就是“强制追加”，绕过当前 position 控制。
如果你需要精确控制写入位置又想保留原有内容，别用 APPEND，改用 WRITE + CREATE，然后手动 channel.size() 获取长度再 position(size)。但要注意并发写入风险，APPEND 模式本身是线程安全的末尾写，手动定位则不是。
和 FileOutputStream / RandomAccessFile 相比，newByteChannel() 有什么实际差异
底层都是基于系统 file descriptor，性能差别极小，关键在语义和控制粒度：
-
FileOutputStream写模式固定（覆盖或追加），无法随机读写；newByteChannel()用选项组合可同时支持读、写、截断、创建等，更接近RandomAccessFile的灵活性 -
RandomAccessFile构造时用"r"/"rw"字符串，不够类型安全；newByteChannel()的OpenOption是枚举，编译期可检查 -
newByteChannel()返回的是SeekableByteChannel，天然支持position()、size()、truncate()，而FileOutputStream.getChannel()返回的 channel 在只写模式下可能不支持position()（取决于是否带READ）
简单说：要精细控制打开行为或后续 seek/truncate，优先选 newByteChannel()；只是简单顺序写日志，FileOutputStream 更直白。
容易被忽略的权限与异常细节
Windows 下，如果目标文件被其他进程以独占方式打开（比如记事本未关闭），newByteChannel() 即使只读也会抛 AccessDeniedException，而非 IOException——这点和传统流不同，容易误判错误原因。
另外，CREATE_NEW 要求文件绝对不能存在，否则抛 FileAlreadyExistsException；而 CREATE 会复用已有文件。很多人混淆这两个，结果在并发场景下因竞态条件意外覆盖文件。
还有个隐藏坑：路径含中文或特殊字符时，确保 Path 对象由 Paths.get() 构建，别用字符串拼接，否则某些 JDK 版本在 Windows 上可能因编码问题解析失败。
