一个文件同步工具一旦在网络两端读写用户文件，就会面临比崩溃更严重的隐患——静默地销毁用户无法恢复的成果。以下是开发过程中遇到的四种数据丢失陷阱，以及对应的修复方案。这些 bug 都不算罕见，且都能通过简单的测试，但实际却是错误的。
1.os.WriteFile先截断后写入。若进程在两步之间被杀死，文件会变成半截内容。修复：先写入临时文件，再rename进行原子替换。注意临时文件需与目标同目录，且rename会交换 inode，硬链接和扩展属性会丢失。更隐蔽的二次伤害：若写入发生在本地区块记录之前，被杀死的写入会产生一个工具不认识的内容片段，下次运行会误报“本地文件已更改”，然后提供--force破坏性标志作为解决方案。
2. 基于 etag 或 mtime 的冲突检测会遗漏双方都修改的情况。本地和远端都改动时，etag 比对只会看到“服务端不同”并直接覆盖本地编辑。冲突判定必须基于字节哈希，而非元数据。元数据只适合作为跳过任务的快速路径，不能作为授权覆盖的依据。
3.--prune/mirror标志造成的破坏最大，因为删除不可撤销。幼稚的规则是“本地有但远端没有就删除”，这会误删用户从未同步过的文件、本地修改的文件以及仅存本地的文件。正确规则：只删除能证明是你写入且用户没有触碰的文件。证明来自你的本地区块记录。若操作中途中断，必须将自身记录为失败，否则prune逻辑会将崩溃解读为一批用户删除。
4. 当服务端返回的文件列表为null时，Go 的json.Unmarshal("null", &slice)会成功并产生一个nil切片。不加保护地处理此输入，工具会认为项目没有文件，下次push --prune就会删除所有本地文件。防御措施：不可信输入必须进行形状验证，任何意外情况都需停止操作，而非放行。需要明确拒绝 null 列表、达到分页上限的列表，以及内容长度与服务端声明不符的列表。一次错误的信任可能损失用户文件。
这四种 bug 都能通过 happy-path 测试，只有通过问“如果此刻崩溃或出错，用户会损失什么”才能暴露出来。工具是开源的，上述每个决策都有测试用例锁定。
GitHub
#开发者 #工具 #Go #数据安全 #Git #sync #编程教程
@DevToolboxHub