本地运行Azure Blob Trigger Function首次触发处理容器全部文件问题

• 不少开发者都遇到过和你一模一样的情况：本地运行Blob触发器函数时，首次启动会扫一遍容器里所有现存图片；后续短时间重启，或者某些场景下，哪怕是3月7日、3月16日的历史图片也会被再次触发处理，哪怕这些文件根本没被修改过。

常见原因 #

• 本地检查点机制：本地运行时，触发器的检查点默认存在%TEMP%\azure-webjobs-hosts目录里。首次启动没有历史检查点，必然会全量扫描容器内所有Blob；如果短时间内重启，本地检查点可能还没完全写入或者被系统清理，导致触发器重新扫描近期有LastModified记录的Blob——哪怕这个时间变动是存储后台维护、工具查看属性这类隐性操作导致的。
• Blob元数据隐性更新：触发器依赖LastModified属性判断是否需要触发，如果通过Azure门户查看Blob详情、用第三方工具修改过元数据（哪怕只是查看操作），都可能导致这个属性被动更新，触发器会误判成“新更新的文件”。

缓解方法 #

• 检查本地检查点：运行函数后去%TEMP%\azure-webjobs-hosts目录看看有没有对应容器的检查点文件；如果想跳过首次全量扫描，可以从已部署的函数应用里导出检查点文件放到本地这个目录（注意匹配存储账户和容器信息）。
• 排查LastModified时间：去存储账户里查看那些被重复触发的历史图片，确认它们的LastModified时间是不是近期有变动，排查有没有自动化脚本或手动操作碰过这些文件的元数据。
• 配置远程检查点存储：修改local.settings.json，把检查点存储指向Azure存储的一个容器，避免本地文件丢失或异常导致的重复扫描，示例配置：

  {
    "Values": {
      "AzureWebJobsStorage": "你的存储账户连接字符串",
      "AzureWebJobsBlobTriggerCheckpointContainer": "checkpoint-container"
    }
  }
  

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