Go 中无法原生撤销删除，os.Remove 是不可逆的物理擦除；所谓“撤销”需手动实现移至回收站、记录元数据并处理还原冲突。
直接说结论：Go 里没法原生“撤销删除”，os.Remove 是不可逆的物理擦除；所谓“撤销”，本质是把删除动作替换成「移到回收站」，再提供一个还原路径的能力——这需要你自己实现移动逻辑、记录元数据、并管理还原时的文件冲突。
为什么 os.Remove 不能撤销
os.Remove 调用的是系统底层 unlink 系统调用（Linux/macOS）或 DeleteFile（Windows），文件数据块立即标记为可复用，没有快照、不写日志、不保留路径信息。一旦成功返回，就真的没了。
- 常见误判：以为
os.RemoveAll或 defer + Close 能回滚——它们只是控制执行时机，不改变删除语义 - 错误尝试：在
Execute()里删文件，Undo()里试图用os.Stat检查原路径是否存在再恢复——失败，因为文件已不存在，且没备份 - 真正能“撤销”的前提，是你根本没调用
os.Remove，而是先os.Rename到安全位置
Linux 下模拟回收站的关键步骤
标准 XDG Base Directory 规范定义了 Linux 回收站路径：$HOME/.local/share/Trash/files，配合 .trashinfo 元数据文件才能支持桌面环境还原。纯 Go 实现至少要覆盖核心移动逻辑：
- 用
os.Getenv("HOME")拼出 trash 根路径，别硬编码/home/user - 用
filepath.Base(path)提取原始文件名，避免路径遍历（如../../../etc/passwd） - 调用
os.MkdirAll(trashPath, 0700)创建回收站目录，权限必须是0700，否则其他用户可读 - 用
os.Rename(src, dst)移动，不是os.Copy+os.Remove——后者多一次 I/O 且失败时状态不一致 - 移动前检查目标是否已存在同名文件，否则会被覆盖；建议在
dst后加时间戳后缀做去重
DeleteToBin 函数的典型缺陷与修复
网上流传的 DeleteToBin 实现常忽略两个致命问题：路径安全性校验和元数据缺失。
立即学习“go语言免费学习笔记（深入）”；
- 不校验输入路径：传入
../config.yaml会直接移到~/.local/share/Trash/files/config.yaml，丢失原始父路径，还原时无法定位原位置 - 不写
.trashinfo：导致 Nautilus/Dolphin 等文件管理器无法识别该文件来自哪、何时删的，也不能右键“还原” - 错误处理粗暴：用
fmt.Errorf但没返回，return false前没设 error 变量，实际 panic 风险高 - 修复方向：封装成结构体（如
TrashManager），保存原始路径、删除时间、原始权限，还原时按需os.Chmod和os.Rename回原位
命令模式实现 Undo 的真实约束
要让 DeleteCommand.Undo() 可靠工作，必须在 Execute() 执行前就固化所有还原所需信息——它不是“反向推导”，而是“精准回放”。
- 字段必须包含：
originalPath string、trashPath string、originalMode fs.FileMode、originalModTime time.Time - 不能依赖全局变量或当前磁盘状态：比如
Undo()里再调用os.Stat(originalPath)判断父目录是否存在——父目录可能已被删 - 还原失败要可重试：
os.Rename(trashPath, originalPath)若因父目录缺失失败，应先os.MkdirAll(filepath.Dir(originalPath), 0755) - 切片存命令必须用
[]Command，不是[]interface{}：后者在cmd.Undo()前需断言，漏判就 panic
真正的复杂点不在代码长度，而在元数据完整性——少记一个 Mode，还原后文件就变成只读；少存一层父路径，还原就只能落到 home 目录下。这些细节不补全，“撤销”就是个假动作。
