文件上传后通过事件源自动触发lambda或functions：aws用s3事件（如s3:objectcreated:*）绑定桶，azure用blobtrigger绑定容器；需注意权限、超时和内存配置。

文件上传后怎么触发 Lambda 或 Functions 执行

触发靠事件源，不是轮询也不是手动调用。AWS Lambda 通常绑定 S3 事件（如 s3:ObjectCreated:*），Azure Functions 则用 BlobTrigger 绑定存储账户的容器。

• AWS：上传文件到指定 S3 桶 → 自动触发 Lambda，事件中带 bucket 和 key，别硬编码路径
• Azure：函数签名必须含 string myBlob 参数或 Stream，绑定字符串是 path/to/container/{name}，{name} 会自动注入
• 常见错误：AccessDenied（Lambda 执行角色没 s3:GetObject）、FunctionTimeout（大文件流式读取没设超时或内存不足）
• 小文件（MemoryStream；大文件务必用 Stream + 分块处理，避免 OutOfMemoryException

怎么在无服务器环境安全读取和解析文件内容

不能依赖本地路径或 File.OpenRead，所有 I/O 必须走云存储 SDK 提供的异步流接口。

• AWS：用 AmazonS3Client.GetObjectAsync 获取 GetObjectResponse.ResponseStream，别调 Stream.CopyTo 到 MemoryStream 再解析——大 CSV/JSON 会爆内存
• Azure：BlobClient.DownloadStreamingAsync 返回 Response<stream></stream>，直接传给 StreamReader 或 JsonSerializer.DeserializeAsync
• 编码陷阱：S3 默认不存 Content-Type 或 Content-Encoding，CSV 文件若含中文，必须显式指定 Encoding.UTF8，否则乱码
• 不要用 File.ReadAllText、File.ReadAllBytes —— 这些在无服务器环境会抛 UnauthorizedAccessException 或找不到路径

如何避免冷启动导致文件处理延迟突增

冷启动本身无法消除，但能减少它对文件处理链路的影响。

C#

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

• 保持函数常驻：AWS 可启用 Provisioned Concurrency，Azure 开启 Always On（仅 Premium 计划支持）
• 别在 Startup 或构造函数里初始化重对象（如 HttpClient 实例、大型词典）——改用 static readonly 或 Lazy<t></t>
• 日志别打太多：每条 Console.WriteLine 或 ILogger.Log 都会触发 CloudWatch / Application Insights 的 IO，积少成多拖慢首字节响应
• 冷启动时首次解析 JSON 可能慢 300–800ms，用 System.Text.Json 而非 Newtonsoft.Json，前者冷启动开销低约 40%

错误怎么捕获、重试和通知

无服务器函数失败 ≠ 重试成功，得自己控制语义重试和死信边界。

• AWS：S3 触发默认重试 3 次（含初始执行），失败进 DeadLetterQueue（需手动配 SQS 或 SNS）；别依赖自动重试来扛网络抖动，HTTP 调用要用 HttpClient + Polly 做内部重试
• Azure：BlobTrigger 默认最多 5 次重试，失败进 poison 容器（路径为 webjobs-blobtrigger-poison），得另写函数监听该容器做告警
• 文件解析失败（如 JSON 格式错）必须 catch 并记录原始 key 和 bucket，否则根本不知道哪条数据坏了
• 别在函数里发邮件或调短信 API —— 超时风险高，应写入 EventBridge 或 Service Bus，由下游服务统一通知

真正难的不是读文件，而是当一个 200MB 的 Excel 上传后，Lambda 内存设 1024MB 仍 OOM，而你发现 EPPlus 库默认把整表加载进内存——这种细节，查文档不如看 GitHub Issues。