Python标准库无真正粉碎删除，os.remove()仅解除链接；安全删除需调用shred（Linux/macOS）或sdelete（Windows），并注意HDD/SSD差异、文件系统限制及管理员权限。
Python 标准库不提供真正意义上的“粉碎性删除”（即多次覆写磁盘扇区），os.remove() 只是解除文件链接、标记空间为可复用，原始数据仍可能被恢复。
为什么 os.remove() 和 shutil.rmtree() 不安全
它们不触碰文件实际占用的磁盘块内容。即使文件已“删除”，用 photorec、debugfs 或专业取证工具仍可提取未覆盖的扇区数据。SSD 还受 TRIM 和磨损均衡影响，覆写行为不可靠——这点常被忽略。
- SSD 上反复写入同一逻辑地址 ≠ 物理位置被覆写
- 文件系统日志、快照、备份、缓存（如 Windows 卷影副本）可能保留副本
-
os.remove()对只读文件会抛PermissionError，但不会报“覆写失败”
用 shred 命令（Linux/macOS）配合 Python 调用
这是最实用的折中方案：依赖系统级工具完成物理层覆写，Python 负责调度与前置检查。注意：shred 对 ext4 的 extent 文件、XFS、Btrfs 及所有 SSD 默认无效（除非挂载时启用 -o shredding 且文件系统支持）。
import subprocess
import os
<p>def secure_delete(filepath):
if not os.path.exists(filepath):
raise FileNotFoundError(f"{filepath} not found")</p><h1>先取消只读，否则 shred 会失败</h1><pre class="brush:php;toolbar:false;">os.chmod(filepath, 0o600)
try:
subprocess.run(["shred", "-u", "-n", "3", filepath],
check=True, capture_output=True)
except subprocess.CalledProcessError as e:
# shred 返回非0码：可能是文件系统不支持，或权限问题
raise RuntimeError(f"shred failed: {e.stderr.decode().strip()}")示例调用
secure_delete("/tmp/secret.txt")
-
-u表示覆写后unlink（等效于删除） -
-n 3指定覆写 3 次；FIPS 140-2 推荐 3 次，DoD 5220.22-M 是 7 次 - 务必确认目标路径在传统 HDD 上；SSD 需改用厂商提供的安全擦除命令（如
hdparm --user-master u --security-set-pass p /dev/sdX）
Windows 上用 sdelete 替代
Sysinternals 的 sdelete 是 Windows 下最接近标准的解决方案，支持 DoD 5220.22-M 和 Gutmann 算法。Python 同样只做封装：
立即学习“Python免费学习笔记（深入）”；
import subprocess
import os
<p>def secure_delete_win(filepath):
sdelete_path = r"C:\tools\sdelete64.exe" # 需提前下载并放指定路径
if not os.path.exists(sdelete_path):
raise FileNotFoundError("sdelete64.exe not found")
subprocess.run([sdelete_path, "-p", "3", "-q", filepath],
check=True, capture_output=True)
-
-p 3表示 3 遍覆写；-q静默模式 - 必须以管理员权限运行 Python 进程，否则
sdelete会因无法绕过卷影副本而失败 - 对 NTFS 压缩或加密文件（EFS），
sdelete会先解压/解密再覆写——但 EFS 密钥若仍在内存或注册表中，仍存在风险
真正安全的粉碎删除不是“调一个函数就完事”，它取决于硬件类型、文件系统特性、操作系统策略和权限上下文。别信纯 Python 实现的“覆写文件再删”——那只是自我安慰。硬盘空闲空间本身也可能残留旧数据，所以高敏场景应直接加密存储，而非依赖事后删除。
