GDPR和CCPA合规要求文件写入前声明用途与保留期、元数据分离存储、删除时覆盖擦除且禁用回收站、路径文件名须哈希脱敏、FileStream权限最小化。
文件写入前必须显式声明数据用途和保留期限
GDPR 和 CCPA 的核心不是“不存数据”，而是“存得有依据、删得有响应”。C# 程序在 File.WriteAllText 或 FileStream 写入用户数据前，不能只做业务逻辑判断，必须同步记录该文件的法律依据（如 "consent" 或 "contract"）和自动删除时间点。
- 把元数据和文件内容物理分离：用独立的
audit.json存储file_id、purpose、retention_until、data_subject_id，而不是写进文件头或注释里——后者无法被 DSR（删除权请求）自动化扫描 - 避免用
DateTime.Now计算过期时间；改用DateTime.UtcNow.AddMonths(24)，防止时区歧义影响合规审计 - 如果文件是日志类（如
user_activity.log），需在写入每条记录前检查是否已超出retention_until，超期则跳过写入而非事后清理
删除操作必须覆盖文件系统级残留
File.Delete 只是移除目录项，磁盘扇区数据仍在。GDPR 第17条“被遗忘权”要求“不可恢复地擦除”，这意味着你不能依赖 .NET 默认行为。
- 对敏感文件（如含
email、ssn的 CSV），删除前先用零填充覆盖：调用File.OpenWrite+stream.Write写入等长new byte[stream.Length]，再执行File.Delete - 禁用回收站：确保
File.Delete传入的是绝对路径，且不调用Microsoft.VisualBasic.FileIO.FileSystem.DeleteFile（它默认走回收站） - SSD 环境下，覆盖写入可能无效——此时应配合
SecureString管理密钥，并将原始文件加密存储（用AesGcm），删除即销毁密钥，让密文变废料
路径和文件名本身可能构成个人数据
CCPA 明确将“可识别特定自然人的信息”纳入规制范围，而 C:\users\alice@domain.com\profile.json 这种路径，邮箱就是直接标识符。
- 禁止在路径中拼接
user.Email、user.FullName等字段；改用不可逆哈希（如Convert.ToBase64String(SHA256.HashData(Encoding.UTF8.GetBytes(user.Id)))）生成目录名 - 文件扩展名也要审查：
.pdf合规，但_consent_form_alice.pdf中的alice就是风险点——统一用doc_<code>guid.pdf 格式 - Windows 下注意
GetFiles返回的完整路径会被日志捕获，若日志未脱敏，等于二次泄露；应在日志中仅记录file_hash和operation_type
FileStream 构造时的 FileMode 和 FileAccess 必须匹配最小权限原则
开一个 FileStream 时选错 FileMode 或 FileAccess，可能无意中允许未授权读写，破坏“数据最小化”原则。
- 仅需追加日志？用
FileMode.Append+FileAccess.Write，别用FileMode.OpenOrCreate—— 后者允许Seek到任意位置重写，违反完整性控制 - 读取配置文件时，明确指定
FileAccess.Read，而非默认的ReadWrite；否则静态分析工具（如 SonarQube）会报Security Hotspot - 在容器或受限环境中（如 Azure App Service），
FileStream可能因FileShare.None导致并发失败；但合规要求又不允许FileShare.Read给其他进程——这时应改用内存映射文件（MemoryMappedFile）+ 临时密钥隔离
事情说清了就结束。最常被忽略的，是路径和文件名里的标识符，以及 File.Delete 的语义幻觉——它看起来像删除，其实只是解引用。
