ASP.NET MVC应用文档重复与文件映射错误问题排查及优化咨询

背景 #

我们开发了一款基于.NET 4.8与ASP.NET MVC的证书申请应用，已稳定运行多年。用户申请证书时需上传相关文档并经人工核验；文档存储于文件系统，路径存入SQL Server数据库的CertificateDocument对象（与Certificate对象关联）。近期出现两个关键问题：

1. 服务器文件重复
2. 文件映射错误，导致检索到错误文档

已排查动作：确认代码多年未改动，关闭服务器复制设置，启用详细日志但未定位根因。

问题解答 #

1. 代码未变更环境下问题的可能诱因 #

结合提供的代码与运维场景，可能的诱因包括：

• 并发上传冲突：用户重复点击上传按钮或前端未做防重复提交处理，导致同一申请的同一文档被多次上传。代码中UploadDocument方法直接用WriteAllBytes写入文件，未检查文件是否存在，会直接覆盖已有文件，同时数据库会添加多条重复的CertificateDocument记录，引发文件重复与映射错误。
• 文件名重复覆盖：SaveCertificateDocument中生成documentName时，若用户上传时提供了自定义document.Name，不同申请可能出现同名文件，导致后续上传的文件覆盖之前的文件，数据库中却存储了不同的记录指向同一文件路径，引发映射错误。
• 数据库事务异常：代码中文件上传成功后才添加数据库记录，但_db.SaveChanges()若失败，已上传的文件不会被删除，形成垃圾文件；反之，若数据库记录添加成功但文件上传后续步骤（如云存储同步）出错，也可能导致数据不一致。
• 文件系统权限/磁盘问题：服务器磁盘权限变更导致文件读写异常，或磁盘出现坏道、缓存同步延迟，使得实际存储的文件与数据库路径映射不匹配。
• TxFileManager线程安全问题：若TxFileManager未实现线程安全的文件操作，多并发请求下可能出现文件写入混乱，导致文件内容错误或路径映射异常。
• 日志信息不足：当前日志仅记录了上传参数，未记录最终生成的文件路径、文件哈希值等关键信息，无法对比数据库记录与实际文件的一致性。

2. .NET或ASP.NET MVC是否存在相关已知问题 #

针对.NET 4.8与ASP.NET MVC，相关已知问题需重点关注：

• Path.Combine路径拼接异常：当folderName包含特殊字符或相对路径时，Path.Combine可能生成不符合预期的路径，但此问题通常在代码上线时就会暴露，而非运行多年后突发。
• File.ReadAllBytes读取缓存问题：在文件被其他进程锁定或磁盘缓存未同步时，File.ReadAllBytes可能读取到旧版本文件内容，但此场景需结合服务器负载与文件操作频率判断。
• EF上下文并发冲突：若多个请求同时操作同一Certificate关联的CertificateDocument，未加并发控制的情况下，可能出现数据库记录重复或路径覆盖。
• ASP.NET MVC请求重复提交：默认情况下ASP.NET MVC未对重复提交做防护，若前端未做限制，易引发重复上传问题。

3. 文件系统存文档、数据库存路径的最佳实践 #

针对文件系统存储+数据库存路径的方案，需遵循以下最佳实践：

• 文件名唯一化：放弃依赖用户输入或业务ID生成文件名，改用Guid.NewGuid().ToString()生成唯一文件名，彻底避免重复覆盖问题。
• 存储相对路径：数据库中存储相对于应用根目录的相对路径，而非绝对路径，避免服务器迁移、目录变更导致的路径失效。
• 事务一致性：将文件上传与数据库记录保存纳入同一事务（可使用文件系统事务或补偿机制），确保两者要么同时成功，要么同时回滚。例如，若数据库保存失败，删除已上传的文件。
• 完整性校验：计算文件的MD5/SHA256哈希值，存储到CertificateDocument表中，检索文件时校验哈希值，确保文件未被篡改或错误覆盖。
• 防重复上传：上传前检查数据库中是否存在同一申请、同一文档类型的记录，或检查文件系统中是否存在同名文件，避免重复操作。
• 增强日志：记录文件上传的完整路径、哈希值、操作时间、操作用户ID等信息，便于后续排查问题。
• 权限控制：设置文件存储目录的最小权限，仅允许应用程序池身份访问，避免未授权的文件修改或删除。
• 定期清理：定时清理数据库中无对应记录的文件，以及超过保留期限的历史文件，释放磁盘空间。

4. 是否建议迁移存储方案，低成本选项有哪些 #

若当前文件系统方案的问题难以快速定位，或未来有扩展性需求，建议考虑迁移存储方案。低成本选项包括：

• 本地文件系统优化：升级服务器存储为RAID阵列提升可靠性，或使用Windows Server的DFS（分布式文件系统）实现多服务器文件同步，成本较低且无需大幅改动代码。
• 云对象存储：采用Azure Blob存储标准层、AWS S3标准-IA层等低成本云存储服务，支持版本控制、生命周期管理，无需维护本地存储设备，仅需修改代码中的文件读写逻辑为调用云存储API。
• 开源对象存储：部署MinIO开源对象存储服务到本地服务器，兼容S3 API，成本仅为服务器硬件成本，适合中小规模应用。
• 数据库存储（小文件场景）：将小文件（如小于10MB）存储到SQL Server的VARBINARY(MAX)字段中，无需维护独立文件系统，但会增加数据库存储成本，不适合大文件。

代码潜在问题分析 #

结合提供的代码，以下点需重点优化：

• 文件覆盖风险：UploadDocument方法中直接使用WriteAllBytes写入文件，未检查文件是否存在，易导致文件被覆盖。
• 事务不一致：文件上传成功后才添加数据库记录，若_db.SaveChanges()失败，已上传的文件无法回滚，形成垃圾文件。
• 文件名不唯一：依赖document.Name或applicationId生成文件名，存在重复风险。
• 云存储同步无容错：File.ReadAllBytes读取文件后上传云存储，若此步骤失败，无重试或补偿机制，导致本地与云存储数据不一致。

// 原SaveCertificateDocument方法关键片段
var documentName = string.IsNullOrEmpty(document.Name) ? $"{documentTypeName}_{applicationId.ToString()}" : document.Name;
// 问题：documentName可能重复，导致文件覆盖

// 原UploadDocument方法关键片段
var filePath = Path.Combine(folderPath, documentNameWithExtension);
fileManager.WriteAllBytes(filePath, document.Data);
// 问题：未检查文件是否存在，直接覆盖

内容的提问来源于stack exchange，提问作者Donald N. Mafa