io.pipe仅实现流式中转，不替代增量同步逻辑；需手动实现比对、校验、位点管理等业务逻辑，配合fsnotify与兜底扫描才能保障文件同步可靠性。
Go 用 io.Pipe 做文件同步转发，不能替代真正的增量同步逻辑，它只解决「流式中转」这一环；真正决定是否同步、跳过什么、校验哪部分，得靠你手动实现的比对和控制逻辑。
为什么 io.Pipe 适合做异构系统间文件中转
io.Pipe 提供内存级 FIFO 流通道，写端阻塞直到读端消费，天然适配「源→管道→目标」这种单向、无状态、不落地的转发场景。比如从本地 fsnotify 捕获事件后，把文件内容直接流式推给 HTTP 客户端或 SFTP 写入器，避免临时文件和磁盘 IO。
- 写端在 goroutine 中调
w.Write()，读端在另一 goroutine 调r.Read()，二者必须分离，否则死锁 - 管道不缓存全部数据，适合大文件（如视频、日志归档），内存占用可控
- 配合
gzip.NewReader(r)或http.NewRequest("PUT", url, r)可无缝接入压缩、HTTP、SFTP 等下游协议 - 注意：管道本身不带错误传播，
w.CloseWithError(err)才能让r.Read()返回对应错误，否则读端可能卡住或返回io.EOF
fsnotify + io.Pipe 组合容易漏事件
编辑器原子写（先写 file.tmp 再 Rename）、NFS 挂载、跨文件系统移动，都会让 fsnotify 丢事件。仅靠监听 + 管道转发，必然导致文件丢失。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 必须搭配低频兜底扫描：
filepath.WalkDir每 5 秒跑一次，只比对FileInfo.Size()和ModTime()，不读内容 -
Rename事件不能直接当“更新”处理——要检查是否是.tmp→real.txt这类模式，否则会把临时文件当有效文件转发 - 监听前用
filepath.WalkDir预加载当前路径树，只对已知文件/目录调watcher.Add()，跳过node_modules、.git等噪声目录
同步前必须做内容比对，不能只靠管道转发
io.Pipe 不管内容是否变更，它只是搬运工。如果源文件没改，但你仍走一遍管道+HTTP PUT，既浪费带宽又可能触发 ES 的 _version 冲突或覆盖 MongoDB 的 change stream 位点。
- 小文件：用
os.Stat比Size()+ModTime()，一致就跳过整个管道流程 - 大文件或高一致性要求：流式计算前 64KB + 后 64KB 的 SHA256，再 fallback 全量校验；别用
os.ReadFile全读进内存 - 目标端是 ES 时，必须带
VersionType("external")和Version(100)，否则并发写入会静默覆盖 - 目标端是 PostgreSQL 时，管道输出不能直接进
pglogrepl，需先解析成 WAL 格式（如 wal2json），再喂给逻辑复制槽
跨系统同步时，位点和元数据必须独立管理
MySQL 的 binlog position、PG 的 LSN、ES 的 _version、MongoDB 的 resumeToken，四者语义不同、不可互换。管道转发不解决位点对齐问题。
- 位点必须单独存 SQLite 或 etcd：MySQL 存
{file: "mysql-bin.000001", pos: 12345}，PG 存{lsn: "0/1A2B3C4D"}，字段名和类型都得分开 - 符号链接不能靠
io.Copy处理——要用os.Lstat判断Mode() & os.ModeSymlink，再用os.Readlink+os.Symlink重建 - 权限和属主信息在跨系统时基本无法保真：Windows 下
os.Chown必败，SFTP 目标端需自定义协议头携带mode字段，而非依赖 OS 层
真正难的不是把字节流从 A 推到 B，而是判断“该不该推”“推完怎么确认成功”“失败了从哪续”。io.Pipe 只负责中间那段最轻量的部分，其余全是业务逻辑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
