冷热分层需业务逻辑+存储策略组合实现，核心是热度判定、迁移目标与访问路由；须维护元数据记录访问信息及存储层级，安全迁移需原子性保障与回滚，访问路由须透明且缓存元数据，云自动分层不可替代应用层控制。
冷热分层不是 C# 自带功能，得靠业务逻辑 + 存储策略组合实现
没有 File.MoveToColdStorage() 这种 API。C# 本身只管本地文件读写，冷热分层是架构设计问题，核心在于：什么时候判断“不常用”，以及把文件往哪迁、怎么保证后续还能读到。
常见错误是直接在 FileStream 或 FileInfo 上加标记，以为改个属性就能自动归档——不行。文件系统不认“热度”，得你自己记访问时间、调用频次，再触发迁移动作。
- 必须单独维护一份元数据（比如数据库表或 JSON 文件），记录
FilePath、LastAccessTime、AccessCount、StorageTier（如"hot"/"cool"/"archive"） - 不能依赖
File.GetLastAccessTime()—— Windows 默认禁用该时间更新，Linux 的atime也常被挂载为noatime - 真实访问日志建议从应用层埋点：每次
File.OpenRead()或 HTTP 下载前，主动更新元数据里的访问时间
如何安全地把文件从本地磁盘迁到对象存储（如 Azure Blob / AWS S3）
迁移不是简单 File.Copy() + File.Delete()。出错就丢数据，必须有原子性保障和回滚路径。
典型流程是“先传后删”，但要防中间态失败：
- 上传前生成唯一
MigrationId，把原路径、目标 URL、状态（"uploading"/"uploaded"/"deleted"）写入元数据 - 用 SDK 上传（如
Azure.Storage.Blobs.BlobClient.UploadAsync()），成功后再删本地文件；删之前校验远程 ETag 和本地MD5是否一致 - 删除失败时，保留原文件，元数据标为
"orphaned_local"，靠后台任务定期扫描修复 - 千万别用
File.Replace()或硬链接——对象存储不支持这些语义
用户访问时如何透明路由到冷/热存储
前端或客户端不能感知文件在哪。统一入口必须做路由转发，否则就得改所有调用方代码。
最轻量做法是封装一个 StorageService 类，内部根据元数据决定读取路径：
- 查元数据发现
StorageTier == "hot"→ 直接File.OpenRead(localPath) - 发现
"cool"→ 调用BlobClient.DownloadStreamingAsync()并流式返回给 HTTP 响应 - 必须缓存元数据（如
MemoryCache），避免每次请求都查 DB；但注意失效策略，比如SlidingExpiration = TimeSpan.FromMinutes(10) - 别在 HTTP 层用 302 重定向到 S3 公共 URL——会暴露密钥、绕过权限控制、丢失访问审计
为什么不用云厂商的自动分层（如 Azure Blob 的 Access Tier）
云存储的 Hot/Cool/Archive tier 是服务端行为，但 C# 应用层无法直接触发“按访问频率自动降级”。它只响应你显式调用 SetAccessTierAsync()，且 Archive tier 不支持直接读，必须先 Rehydrate（耗时分钟级）。
所以真实项目里，通常混合使用：
- 高频小文件：留在本地 SSD 或 Hot tier
- 中低频大文件（如用户上传的 PDF、视频）：迁到 Cool tier 对象存储 + 应用层管理生命周期
- 真正归档（如 3 年以上无访问）：走 Archive tier，但必须配套异步解冻队列和用户提示机制
- 关键点：所有 tier 切换操作都要记录到审计日志，包括谁触发、何时、原始大小、耗时——排查“文件打不开”时全靠它
最容易被忽略的是元数据一致性。迁移脚本跑一半崩了，或者并发修改同一文件的 tier 状态，会导致路径错乱。要么加分布式锁（如 Redis lock），要么用数据库行级锁配合 SELECT ... FOR UPDATE。没做这步，后面查半天发现是脏状态。
