Blob触发器函数必须声明BlobTrigger参数且路径严格匹配，容器名需小写并预先存在，大文件应使用Stream处理，本地调试需用Azurite，实时性要求高时须改用Event Grid。
Blob触发器函数必须声明 BlobTrigger 参数且路径格式要严格匹配
Azure Functions 的 Blob 触发器不是靠监听文件系统事件，而是轮询存储账户的 $logs 或使用事件网格（需额外配置），因此函数签名里必须有一个带 [BlobTrigger] 特性的参数，且绑定路径不能写死容器名以外的部分——比如 "samples-workitems/{name}" 是合法的，而 "samples-workitems/fixed.txt" 会直接导致函数无法启动。
- 路径中花括号
{name}、{blobName}等是占位符，会被自动解析为字符串参数，可用于后续读取元数据或构造 URL - 容器名必须小写、只能含字母数字和短横线，且函数部署前该容器必须已存在（触发器不会自动创建）
- 如果路径写成
"container/*"或带通配符的 glob 模式，会报错：「Binding pattern must be a literal or contain only {name} placeholders」
函数体内读取 Blob 内容时优先用 Stream 而非 string 绑定
虽然你可以把参数类型设为 string 或 byte[] 让运行时自动加载整个 blob，但这在文件较大（>10MB）时极易引发内存溢出或超时。生产环境应始终用 Stream 流式处理：
public static void Run(
[BlobTrigger("uploads/{name}", Connection = "StorageConnectionString")] Stream myBlob,
string name,
ILogger log)
{
using var reader = new StreamReader(myBlob);
var content = reader.ReadToEnd(); // 小文件可接受
// 大文件建议逐行或分块处理
}
-
Connection属性值必须对应local.settings.json中的键（本地）或应用设置里的连接字符串名称（Azure） - 若需访问 blob 元数据（如
ContentType、自定义属性），得额外注入IBinder或改用BlobClient手动获取——Stream参数本身不携带元数据 - 别在函数里调用
myBlob.Position = 0，Blob 流默认不可重置，重复读会抛NotSupportedException
本地调试时 StorageConnectionString 必须指向真实 Azure 存储账户或 Azurite
Visual Studio 或 func CLI 默认不支持用 UseDevelopmentStorage=true 这种旧式模拟器；Azure Functions v4+ 运行时要求明确的连接字符串。本地开发务必用 Azurite（轻量级开源模拟器）并确保连接字符串形如：
DefaultEndpointsProtocol=http;AccountName=devstoreaccount1;AccountKey=Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==;BlobEndpoint=http://127.0.0.1:10000/devstoreaccount1;
- Azurite 容器名需手动创建（例如
azurite -s -l ./azurite-data启动后用curl或 Storage Explorer 新建容器） - 若误填成空字符串或格式错误的连接字符串，函数启动时不会报错，但 blob 上传后完全无反应——日志里只显示「No job functions found」
- 连接字符串中的
BlobEndpoint必须带端口，缺省的10000不能省略
生产环境必须启用事件网格（Event Grid）才能实现秒级触发
默认的轮询机制有延迟（通常 1–10 分钟），根本达不到「文件一上传就触发」的效果。真要低延迟，必须关闭 Blob 触发器的轮询模式，改用 Event Grid + HTTP 触发函数中转：
- 在存储账户中开启「事件订阅」，目标设为同一函数应用的 HTTP 函数（
https://yourfunc.azurewebsites.net/runtime/webhooks/extension?functionName=BlobProcessor&code=xxx） - 原
BlobTrigger函数保留，但只作为被调用方；HTTP 函数收到 Event Grid 事件后，用BlobServiceClient主动下载 blob 并调用业务逻辑 - 这种组合绕过了轮询限制，但增加了部署复杂度——Event Grid 订阅需要 RBAC 权限，且 HTTP 函数要能处理批量事件（
data[].url可能含多个 blob）
轮询 vs Event Grid 的选择不是代码问题，而是架构权衡：简单脚本用轮询够用，实时性敏感的流水线必须切 Event Grid。很多人卡在“为什么我传完文件 5 分钟后才进函数”，答案往往就在这里。
