租户文件路径必须使用系统生成的不可预测哈希值作为子目录名，而非原始tenantid或用户可控字段；需严格校验路径、隔离权限、禁用静态映射，并通过软删除+异步清理保障安全。
租户文件路径必须带唯一标识，不能只靠文件名隔离
多租户下最常见错误是把所有文件存进同一个目录，仅靠 tenantId 做文件名前缀（比如 "tenant123_report.pdf"）。这会导致路径冲突、误删、权限绕过——尤其当租户能控制部分文件名时，../ 路径遍历或同名覆盖就很容易发生。
正确做法是每个租户独占一个根级子目录，且该目录名必须由系统生成、不可预测、不可篡改：
- 用哈希值而非原始
tenantId作路径段，例如Path.Combine(root, "t", Convert.ToBase64String(SHA256.HashData(Encoding.UTF8.GetBytes(tenantId.ToString()))).Substring(0, 16)) - 禁止接受用户输入直接拼入路径，所有路径构造必须走白名单校验函数，如
IsValidTenantPathSegment() - 物理存储路径和数据库中记录的路径必须严格一致，避免“写在这里、查那里”的不一致
File.WriteAllBytes 不能直接写到租户路径，要加权限沙箱
File.WriteAllBytes 默认以当前进程身份运行，如果应用跑在高权限账户下（比如 Windows 的 SYSTEM 或 Linux 的 root），租户文件就可能被越权读写。更危险的是，一旦路径构造出错，File.WriteAllBytes 可能直接覆写系统配置文件。
实际操作中必须做三件事：
- 为每个租户分配独立的 Windows ACL 或 Linux 文件系统权限组，应用进程本身不拥有全局写权限
- 用
FileStream手动控制打开模式，显式指定FileAccess.Write和FileShare.None，避免并发写乱序 - 写入前调用
Directory.CreateDirectory确保父路径存在，但该路径必须已通过租户隔离校验——不能让CreateDirectory自动创建上级任意深度目录
ASP.NET Core 中 IWebHostEnvironment.WebRootPath 不适合存租户文件
很多人图省事把租户上传文件往 IWebHostEnvironment.WebRootPath（通常是 wwwroot）里扔，结果导致两个问题：一是静态文件服务器会直接暴露租户文件 URL，二是 WebRootPath 通常没有按租户划分的访问控制机制。
安全路径应满足三个条件：不在 Web 根目录下、不被任何中间件自动映射、有独立生命周期管理：
- 推荐路径结构：
Path.Combine(Directory.GetCurrentDirectory(), "tenant-data", tenantHash) - 禁用对该目录的静态文件中间件映射，哪怕加了
[Authorize]也不行——认证和文件路径权限是两层事 - 若需提供下载，必须走受控 API（如
GET /api/tenants/{id}/files/{fileId}），并在响应前校验租户上下文与文件归属
租户文件删除必须走异步清理 + 软删除标记
直接调用 File.Delete 或 Directory.Delete 风险极高：租户A删自己文件时，若路径计算错误，可能触发租户B的整个目录递归删除；更麻烦的是，SQL Server 或 PostgreSQL 里文件元数据还没删完，磁盘文件先没了，后续查询就报空引用。
稳妥做法是分两步走：
- 第一步只更新数据库状态字段（如
IsDeleted = true,DeletedAt = DateTime.UtcNow），并记录待清理的物理路径到专用队列表 - 第二步由后台服务（如
IHostedService）定时扫描队列，逐条执行File.Delete，失败则重试 + 告警，成功后才从队列移除 - 所有删除入口（API、后台任务、迁移脚本）都必须校验租户 ID 与目标文件元数据中的
TenantId完全匹配，不允许模糊匹配或通配符
租户隔离不是加个文件夹前缀就能搞定的事，真正难的是路径构造、权限落地、生命周期同步这三环咬合——漏掉一环，隔离就形同虚设。
