go语言无内置wal解析器，须依赖数据库官方接口或工具：postgresql用pglogrepl或pg_waldump，mysql用go-mysql/replication，sqlite wal则需主库文件配合且无标准解析方案。
Go 语言本身不解析 WAL，也没有内置 WAL 解析器——你得靠数据库自身暴露的接口或外部工具，否则直接读二进制 WAL 文件等于在猜字谜。
PostgreSQL WAL 日志不能用 os.ReadFile 直接解析
PostgreSQL 的 WAL 是紧凑二进制格式（含时间线、LSN、记录类型、块偏移等），没有文档化公开结构，版本间还可能微调。用 os.ReadFile 读出来只是一堆无法解释的字节，json.Unmarshal 或 binary.Read 都会 panic 或返回垃圾数据。
- 真正能安全消费 WAL 的方式只有两种：走逻辑复制协议（如使用
pglogrepl库），或调用 PostgreSQL 自带的pg_waldump命令行工具做离线分析 -
pglogrepl库底层复用了 libpq 的复制协议逻辑，它不碰原始 WAL 文件，而是通过START_REPLICATION命令从服务端流式接收已解码的逻辑变更 - 别试图用 Go 手写 WAL 解析器——PostgreSQL 官方明确不承诺 WAL 格式稳定，连注释都写着 “not for external use”
MySQL binlog 可以用 github.com/juju/errors？不，要用 github.com/siddontang/go-mysql
MySQL 的 binlog 虽然也是二进制，但有公开协议文档，且社区已有成熟解析库。但注意：github.com/juju/errors 是错误包装工具，和 binlog 完全无关；真正能用的是 go-mysql 提供的 replication 子包。
-
go-mysql/replication支持解析 row-based 和 statement-based binlog，能提取表名、操作类型（WriteRowsEvent/DeleteRowsEvent）、字段值（需配合TableMapEvent） - 必须先连接 MySQL 并执行
SHOW MASTER STATUS获取起始Binlog Filename和Position，再传给BinlogSyncer.StartSync - 跳过 GTID 模式下直接用文件+位置是危险的——GTID 开启后，应优先用
StartSyncGTID，否则可能漏事件或重复消费
SQLite WAL 文件（-wal）不是日志流，是内存页缓存快照
SQLite 的 WAL 不是用于复制或审计的“日志”，而是实现并发写的临时页缓冲区。它的格式是固定头 + 一系列帧（frame），每个帧含页号、提交版本、校验和，但不记录 SQL 语句或变更语义。
立即学习“go语言免费学习笔记（深入）”；
- 你可以用
hexdump -C your.db-wal | head看到前 32 字节是 WAL header（含 magic number3775490180），但后续每帧仅包含原始页数据，没 schema、没操作类型 - 想还原出“哪条 INSERT 被写了”，必须同时持有
your.db主文件（获取 schema 和页树结构）+your.db-wal+your.db-shm（共享内存索引），三者缺一不可 - Go 里没有标准库支持解析 SQLite WAL；
github.com/mattn/go-sqlite3本身绕过 WAL 直接走 VFS 层，不暴露帧解析能力
WAL 解析从来不是“读个文件然后 decode”这么简单——它强依赖数据库的具体实现、开启的模式（逻辑/物理复制、GTID/FILE_POS）、以及你手头是否握有配套元数据。最省事的路径，永远是走数据库官方支持的复制协议，而不是自己啃二进制。
