使用XmlSerializer与Azure ShareFileClient生成文件大小异常问题求助

在Azure Function中，需将导入的RowSet数据通过XmlSerializer序列化后上传至Azure文件存储。由于XML文件大小通常在100-250MiB，因此采用Azure.Storage.Files.Shares命名空间下的OpenWrite方法，避免大文件加载到内存导致的资源占用问题。但设置ShareFileOpenWriteOptions.MaxSize后，生成的文件大小始终等于该值——即使是空XML也是如此。原本预期MaxSize是限制文件的最大允许尺寸，而非强制设置实际文件大小。虽然先将XML全量加载到内存再上传能得到正确的文件大小，但大文件场景下内存占用过高，需要一种无需加载全量数据的流式解决方案。

核心原因 #

ShareFileOpenWriteOptions.MaxSize的实际作用是预先创建指定大小的文件，而非限制文件的最大尺寸。当设置该值后，Azure文件存储会直接生成对应大小的空文件，后续写入的内容仅覆盖前部分字节，剩余空字节保留，导致最终文件大小与MaxSize一致。

修改后的实现代码 #

public void WriteXmlToFile<MyRowSetType>(MyRowSetType rs, string filePath, string fileName)
{
    try
    {
        ShareFileClient fileClient = _shareClient.GetDirectoryClient(filePath).GetFileClient(fileName);

        // 不设置MaxSize，直接打开可写流（true表示覆盖已存在的文件）
        using (var stream = fileClient.OpenWrite(true))
        {
            var serializer = new XmlSerializer(typeof(MyRowSetType));
            serializer.Serialize(stream, rs);
            
            // 获取实际写入的字节数，调整文件大小为实际长度
            long actualBytesWritten = stream.Position;
            fileClient.SetLength(actualBytesWritten);
        }
    }
    catch (Exception ex)
    {
        _logger.LogError($"Error writing XML to Azure File Storage, FileName: {fileName}, FilePath: {filePath}, Exception: {ex}");
        throw;
    }
}

方案优势 #

• 全程流式处理，无需将XML全量加载到内存，适配100-250MiB的大文件场景
• 通过SetLength方法截断文件，确保最终文件大小与实际序列化内容一致
• 保留了OpenWrite方法的低内存特性，避免内存过载问题

内容的提问来源于stack exchange，提问作者ChrisFromTheBlock