访问一些文件时经常会出现如题的异常提示，下面讨论一些解决思路和文案
文件访问示例代码如下：
if (System.IO.File.Exists(fullName)) {FileStream fs = null;byte[] rtnByte = null;try{fs = System.IO.File.Open(fullName, FileMode.Open, FileAccess.Read,FileShare.Read);rtnByte = new Byte[fs.Length];int nBytesRead = fs.Read(rtnByte, 0, rtnByte.Length);}catch (Exception ex){_logger.Error(string.Format("下载文件出错 【参数: fileName:{0} oPath:{1}】", fileName, oPath),ex);throw new Exception("下载文件出错" + ex.ToString());}finally{if (fs != null){fs.Flush();fs.Close();fs = null;}}return rtnByte; }
初步修改方案
尝试打开文件并读取到内存。若文件被其他进程以共享读写方式占用，FileShare.ReadWrite 可以允许读取。
若其他进程以独占方式锁定文件，则会抛出 IOException。此处增加重试策略并记录日志以便排查。
if (System.IO.File.Exists(fullName)) {// 尝试打开文件并读取到内存。若文件被其他进程以共享读写方式占用，FileShare.ReadWrite 可以允许读取。// 若其他进程以独占方式锁定文件，则会抛出 IOException。此处增加重试策略并记录日志以便排查。int maxAttempts = 3;for (int attempt = 1; attempt <= maxAttempts; attempt++){try{using (FileStream fs = new FileStream(fullName, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))using (MemoryStream ms = new MemoryStream()){fs.CopyTo(ms);return ms.ToArray();}}catch (IOException ioEx){_logger.Warn(string.Format("下载文件 IO 异常 attempt={0} fullName={1}", attempt, fullName), ioEx);if (attempt == maxAttempts){_logger.Error(string.Format("下载文件出错 【参数: fileName:{0} oPath:{1}】", fileName, oPath), ioEx);throw new Exception("下载文件出错" + ioEx.ToString());}System.Threading.Thread.Sleep(200);continue;}catch (Exception ex){_logger.Error(string.Format("下载文件出错 【参数: fileName:{0} oPath:{1}】", fileName, oPath), ex);throw new Exception("下载文件出错" + ex.ToString());}} }
说明（简短）：
• 改动内容：使用 Path.Combine 构建路径；以 FileShare.ReadWrite 打开文件，并通过 MemoryStream 使用 CopyTo 安全读取；对可能的 IOException 增加重试（3 次、每次等待 200ms）；在最终失败时记录详细日志并抛出异常。
• 理由：原异常是“文件被另一进程使用导致无法访问”。使用 FileShare.ReadWrite 可在大多数由写/读共享导致的问题上允许读取；重试可以应对短时间内的文件锁冲突。若目标进程对文件使用独占锁（无法共享），仍会抛出 IOException，此时需要找出并修改占用该文件的进程（例如 PDF 生成/写入代码未正确关闭流、或反病毒/预览程序锁定文件）。
结论（简短）
• 最可能的原因：在生成/处理 文件时（如PDF生成、加水印、合并等）时，生成进程对该文件持有独占句柄，下载请求在此期间尝试打开文件导致被拒绝。
• 次可能原因：客户端（或服务器端的预览/杀毒/索引程序）在下载时占用文件并阻塞其它并发访问，但按你给出的代码，第一种更可能。
关键证据（基于代码）
• 下载处代码： 使用了
fs = System.IO.File.Open(fullName, FileMode.Open, FileAccess.Read, FileShare.Read);
仅允许其它进程以可读共享打开文件；如果写入方以独占方式打开（常见）就会抛 IOException（正是你看到的错误）。
其他生成文件时生产问题的原因：
• 使用 FileMode.Append 向临时文件追加，期间写入流会把文件锁住直到 pdfStamper.Close()。若写入尚未完成或异常发生，文件句柄可能未及时释放。
• 该类方法（以及 PDFEntrance.WriteReport/报表生成流程）都会在服务器上写文件并替换/删除原文件，生成过程中对文件的独占访问是常态。
• 报表通常是“按需生成/覆盖”或“生成后替换原文件”，因此在多个评委几乎同时打开同一报表时，很容易出现“一个线程在写、另一个线程要读”的竞态。
建议（优先级）
1. 优化生成端（首要）
• 生成/处理时写入临时文件（例如 path.tmp 或 path + ".tmp"），写入完成并确保流已 Close/Flush 后再用原子操作替换（File.Replace 或先 Delete 再 Move）。避免直接在目标文件上追加/写入。
• 在 SetWatermark 中不要用 FileMode.Append 写到目标名，改为 FileMode.Create 写临时文件，最后 Replace。确保所有 FileStream、PdfStamper、PdfReader 都在 using/finally 中正确关闭。
2. 下载端容错（次要）
• 在下载时增加短重试 + 日志，并允许更宽松的共享（FileShare.ReadWrite）或先复制到临时副本再读取返回。你之前的修改方向（FileShare.ReadWrite + 重试）是合适的补救措施。
• 更好做法：如果文件可能正在被写入，先判断文件最后写入时间 / 是否仍在写入（例如尝试以写模式打开短时间失败）再返回错误或重试。
3. 排查锁定来源
• 在复现环境用 Process Explorer / Handle 工具 确认是哪个进程持有句柄（是报表生成进程、IIS 工作进程、杀毒还是 IE 预览）。
• 在代码路径里加强异常与持锁日志（记录何时开始生成、何时结束、何时替换文件），便于定位。
4. 长远改进
• 考虑 WCF 使用流式传输（Streamed）返回文件，或让报表生成端在生成完成后把文件放到只读目录并通过代理/缓存来分发，减少并发写/读冲突。
总结一句话：按照你当前代码和错误信息，最可能是“生成/处理报表时未及时释放句柄（或生成过程仍在写入）”，导致并发读取失败；并发多个 IE 请求在没有写锁的情况下通常不会导致“另一个进程使用中”的 IOException。需要优先确保报表生成流程使用临时文件 + 原子替换，并在下载端加重试或复制读取以缓解问题。