seek()跳不到预期位置是因为参数为字节偏移量，非行号或字符索引；混用UTF-8与ASCII编码、错误使用writeBytes()写中文、未配对readUTF()/writeUTF()等均导致错乱。
RandomAccessFile 的 seek() 为什么跳不到预期位置？
因为 seek() 的参数是 字节偏移量（long），不是行号、不是记录序号，更不是字符索引。如果你按文本行逻辑计算偏移却用 UTF-8 写入，或混用不同编码读写，seek() 后读出来的内容必然错乱。
常见错误现象：seek(100) 后读出半个中文、字段对不齐、解析 JSON 报 Unexpected character。
- 确认文件是纯二进制格式，或严格按固定字节长度编码（如 ASCII/ISO-8859-1）；若含 UTF-8 中文，必须用
DataInputStream+readUTF()等配套方式，不能裸 seek +readLine() - 写入时务必用
writeBytes()或writeUTF()而非writeChars()（后者按 char 写，2 字节/字符，UTF-8 下完全不匹配） - 用
getFilePointer()实时校验当前位置，尤其在多次seek()和读写穿插时
如何安全地在大文件中定位并修改一条固定长度记录？
这是 RandomAccessFile 最典型且最稳妥的用法：每条记录占 N 字节，第 i 条记录起始位置就是 i * N。只要写入时严格对齐，seek(i * N) 就绝对精准。
示例：日志索引文件，每条 256 字节，含时间戳（8B）、状态（4B）、长度（4B）、正文偏移（8B）：
Teleport tsh SSH (Identity-First SSH Access, no passwords/static keys)
下载
使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
raf.seek(recordIndex * 256); raf.writeLong(timestamp); raf.writeInt(status); raf.writeInt(contentLength); raf.writeLong(contentOffset);
- 记录长度
N必须是常量，不能动态变化；变长字段（如正文）需单独存到另一区域，并用偏移+长度引用 - 写入前建议先
seek()到目标位置再调用writeXxx()，避免因上次读写残留指针导致覆盖错误位置 - 多线程访问同一
RandomAccessFile实例时，seek()+write()不是原子操作，必须加外部同步（如synchronized(raf)），否则可能相互干扰
RandomAccessFile 读写中文时到底该用 writeUTF 还是 writeBytes？
writeUTF() 写入的是带 2 字节长度前缀的 modified UTF-8，readUTF() 能精确还原；writeBytes() 是逐字节写入字符串的低字节（即只取 char & 0xFF），对中文直接丢数据 —— 所以它只适合 ASCII 场景。
错误示范：raf.writeBytes("你好") 在 UTF-8 文件里写入的是 0x4F60 0x597D 的低字节 0x60 0x7D，完全不可读。
- 坚持配对原则：用
writeUTF()就必须用readUTF()；用writeChars()（不推荐）就得用readChars()，且两端 JVM 字节序一致 - 如果文件要被其他语言（如 Python/C）读取，放弃
writeUTF()，改用write(byte[])+str.getBytes(StandardCharsets.UTF_8)，并自行管理长度字段 -
writeUTF()最大只支持 65535 字节内容，超长会抛UTFDataFormatException，生产环境务必检查字符串长度
为什么用 RandomAccessFile 处理 GB 级文件仍卡顿？
因为 RandomAccessFile 本身不缓存，每次 read() 或 write() 都触发系统调用。即使只是跳转后读 4 字节，也可能引发一次磁盘寻道 —— 对机械硬盘尤其致命。
- 对频繁随机访问场景，自己套一层
ByteBuffer缓冲：用raf.getChannel().map(...)做内存映射，比反复seek()快一个数量级 - 避免在循环里反复
seek() → readInt() → seek() → readInt()，改为一次seek()后批量readFully(new byte[N])，再用ByteBuffer.wrap()解析 - 注意
getChannel().force(true)的开销：它强制刷盘，用于保证数据落盘，但每写一条都调用会极大拖慢速度；应按事务边界（如每万条）批量刷盘
真正难的不是跳转，而是确保跳转后读写的语义和外部系统一致——编码、字节序、字段对齐、并发控制，漏掉任意一环，文件就变成“已损坏”状态。
