ASP.NET Core文件微服务应先实现FileStorageController，确保存、取、查功能，核心是路径抽象为ID、操作收口HTTP、存储适配可插拔；禁用原始文件名作key，需生成唯一ID并存OriginalName；下载避免FileStreamResult，优先预签名URL；上传需哈希校验实现幂等。
用 ASP.NET Core Web API 做文件微服务的起点
别从“微服务架构图”开始，先跑通一个能存、能取、能查的 FileStorageController。C# 文件微服务不是堆技术，而是把「文件路径抽象成资源 ID」「操作收口到 HTTP 接口」「本地磁盘或对象存储适配可插拔」这三件事做稳。
实操建议：
- 用
IWebHostEnvironment.WebRootPath临时存文件只用于验证流程，上线必须切换为IBlobStorage抽象层（如 Azure Blob、MinIO、S3 兼容存储） - 不要在 Controller 里直接 new
FileStream或拼接Path.Combine—— 路径校验、目录遍历防护、大小限制都得前置拦截 - 上传接口必须支持
IFormFile（小文件）和流式分块上传（大文件），否则前端一传 200MB 就超时或 OOM
文件 ID 设计：别用原始文件名当 key
用户上传 发票.pdf，你存成 invoice.pdf？马上撞上重名覆盖、中文乱码、路径穿越（比如文件名含 ../etc/passwd）。
实操建议：
- 生成唯一 ID 用
Guid.NewGuid().ToString("N")或Path.GetRandomFileName()，再加时间戳前缀便于排序，例如20240521_a1b2c3d4e5f67890 - 原始文件名存在数据库字段
OriginalName，不参与路径构造；访问下载时用Content-Disposition: attachment; filename*=UTF-8''{encoded}安全回传 - 如果业务要按类型查（如“所有合同 PDF”），在元数据表里加
ContentType和Tags字段，别靠后缀名过滤
为什么 FileStreamResult 在微服务里很危险
FileStreamResult 看似方便，但会把整个文件读进内存再吐给响应流——1GB 文件进来，进程 RSS 直接涨 1GB，K8s 下 Pod 很快被 OOMKilled。
实操建议：
- 下载接口一律用
PhysicalFile(path, contentType)（本地磁盘）或FileContentResult+ 分块读取（对象存储） - 对象存储场景下，优先返回预签名 URL（
GenerateSasUri），让客户端直连存储，微服务只做鉴权和日志 - 必须加
[ResponseCache(Duration = 300)]，但注意：带身份校验的文件不能全局缓存，要用VaryByHeader = "Authorization"
并发上传冲突与幂等性怎么落地
用户点两次上传按钮，后端收到两个相同文件，该合并还是报错？没处理好就出现重复存储、计费翻倍、检索结果错乱。
实操建议：
- 上传前先算文件 SHA256（前端用
FileReader+crypto.subtle.digest，后端用SHA256.HashData），查库是否存在相同哈希 → 存在则跳过写入，直接返回已有FileId - 用数据库唯一索引约束
(TenantId, FileHash)，避免竞态条件；插入失败捕获SqlException.Number == 2627并重试查询 - 不要依赖前端传来的 “文件大小+名称+时间” 组合判断重复——这些都可伪造，只有内容哈希可信
文件微服务真正的复杂点不在“怎么存”，而在“谁在什么时候以什么权限访问了哪个版本”。路径、ID、哈希、元数据、审计日志，这五样缺一不可，少一个，后面排查问题就得翻三天日志。
