你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure Functions PowerShell 开发人员指南

项目
01/24/2025

本文详细介绍了如何使用 PowerShell 编写 Azure Functions。

PowerShell Azure 函数（简称函数）表示为在触发时执行的 PowerShell 脚本。每个函数脚本都有一个相关的 function.json 文件，用于定义该函数的行为方式，例如其触发方式及其输入和输出参数。若要了解详细信息，请参阅触发器和绑定一文。

与其他类型的函数一样，PowerShell 脚本函数采用与 function.json 文件中定义的所有输入绑定的名称相匹配的参数。此外还传递了一个 TriggerMetadata 参数，该参数包含启动了该函数的触发器的附加信息。

本文假定你已阅读 Azure Functions 开发人员参考。此外，还假设你已完成创建第一个 PowerShell 函数所需的 PowerShell 函数快速入门。

文件夹结构

PowerShell 项目所需的文件夹结构如下所示。可更改此默认值。有关详细信息，请参阅 scriptFile 部分。

PSFunctionApp
 | - MyFirstFunction
 | | - run.ps1
 | | - function.json
 | - MySecondFunction
 | | - run.ps1
 | | - function.json
 | - Modules
 | | - myFirstHelperModule
 | | | - myFirstHelperModule.psd1
 | | | - myFirstHelperModule.psm1
 | | - mySecondHelperModule
 | | | - mySecondHelperModule.psd1
 | | | - mySecondHelperModule.psm1
 | - local.settings.json
 | - host.json
 | - requirements.psd1
 | - profile.ps1
 | - extensions.csproj
 | - bin

项目的根目录中有共享的 host.json 文件，可用于配置函数应用。每个函数都有一个文件夹，其中包含它自己的代码文件 (.ps1) 和绑定配置文件 (function.json)。 function.json 文件的父目录的名称始终是函数的名称。

某些绑定要求存在 extensions.csproj 文件。 2.x 及更高版本的 Functions 运行时中所需的绑定扩展在 extensions.csproj 文件中定义，实际库文件位于 bin 文件夹中。本地开发时，必须注册绑定扩展。在 Azure 门户中开发函数时，系统将为你完成此注册。

在 PowerShell 函数应用中，你可以选择创建一个在函数应用开始运行（也称为冷启动）时运行的 profile.ps1。有关详细信息，请参阅 PowerShell 配置文件。

将 PowerShell 脚本定义为函数

默认情况下，Functions 运行时会在 run.ps1 中查找你的函数，其中，run.ps1 与其相应的 function.json 共享同一个父目录。

在执行时，会向你的脚本传递多个参数。若要处理这些参数，请将 param 块添加到脚本顶部，如以下示例所示：

# $TriggerMetadata is optional here. If you don't need it, you can safely remove it from the param block
param($MyFirstInputBinding, $MySecondInputBinding, $TriggerMetadata)

TriggerMetadata 参数

TriggerMetadata 参数用于提供有关触发器的附加信息。此元数据因绑定而异，但是它们都包含一个 sys 属性，该属性包含以下数据：

$TriggerMetadata.sys

properties	说明	类型
UtcNow	函数的触发时间（采用 UTC 格式）	DateTime
MethodName	已触发的函数的名称	字符串
RandGuid	针对函数的此执行操作的唯一 GUID	字符串

每个触发器类型都有一组不同的元数据。例如，QueueTrigger 的 $TriggerMetadata 包含 InsertionTime、Id、DequeueCount 等内容。有关队列触发器的元数据的详细信息，请参阅队列触发器官方文档。查看你在使用的触发器的相关文档，以了解触发器元数据内部的情况。

绑定

在 PowerShell 中，需在函数的 function.json 中配置和定义绑定。函数通过多种方式与绑定交互。

读取触发器和输入数据

触发器和输入绑定被读取为传递给函数的参数。输入绑定在 function.json 中有一个设置为 in 的 direction。在 function.json 中定义的 name 属性是 param 块中参数的名称。由于 PowerShell 使用已命名参数进行绑定，因此参数的顺序并不重要。不过，最佳做法是遵循 function.json 中定义的绑定的顺序。

param($MyFirstInputBinding, $MySecondInputBinding)

写入输出数据

在 Functions 中，输出绑定在 function.json 中有一个设置为 out 的 direction。你可以使用 Push-OutputBinding cmdlet（可用于 Functions 运行时）将数据写入到输出绑定。在所有情况下，function.json 中定义的绑定的 name 属性都对应于 Push-OutputBinding cmdlet 的 Name 参数。

以下示例展示了如何在函数脚本中调用 Push-OutputBinding：

param($MyFirstInputBinding, $MySecondInputBinding)

Push-OutputBinding -Name myQueue -Value $myValue

还可以通过管道传入特定绑定的值。

param($MyFirstInputBinding, $MySecondInputBinding)

Produce-MyOutputValue | Push-OutputBinding -Name myQueue

Push-OutputBinding 的行为因为 -Name 指定的值而异：

当指定的名称无法解析为有效的输出绑定时，会引发错误。
当输出绑定接受值的集合时，可以重复调用 Push-OutputBinding 来推送多个值。
当输出绑定只接受单一实例值时，第二次调用 Push-OutputBinding 会引发错误。

Push-OutputBinding 语法

下面是用于调用 Push-OutputBinding 的有效参数：

名称	类型	位置	说明
`-Name`	字符串	1	你要设置的输出绑定的名称。
`-Value`	Object	2	你要设置的输出绑定的值，它是从管道 ByValue 接受的。
`-Clobber`	SwitchParameter	名为	（可选）指定了此项时，系统会强制为指定的输出绑定设置值。

还支持以下常用参数：

Verbose
Debug
ErrorAction
ErrorVariable
WarningAction
WarningVariable
OutBuffer
PipelineVariable
OutVariable

有关详细信息，请参阅关于 CommonParameters。

Push-OutputBinding 示例：HTTP 响应

HTTP 触发器使用名为 response 的输出绑定返回响应。在下面的示例中，response 的输出绑定具有“output #1”值：

PS >Push-OutputBinding -Name response -Value ([HttpResponseContext]@{
    StatusCode = [System.Net.HttpStatusCode]::OK
    Body = "output #1"
})

由于输出是针对 HTTP（仅接受单一实例值），因此在第二次调用 Push-OutputBinding 时会引发错误。

PS >Push-OutputBinding -Name response -Value ([HttpResponseContext]@{
    StatusCode = [System.Net.HttpStatusCode]::OK
    Body = "output #2"
})

对于仅接受单一实例值的输出，可以使用 -Clobber 参数替代旧值，而不要尝试将内容添加到集合。下面的示例假定你已经添加了一个值。通过使用 -Clobber，以下示例中的响应会替代现有值以返回“output #3”值：

PS >Push-OutputBinding -Name response -Value ([HttpResponseContext]@{
    StatusCode = [System.Net.HttpStatusCode]::OK
    Body = "output #3"
}) -Clobber

Push-OutputBinding 示例：队列输出绑定

Push-OutputBinding 用于将数据发送到输出绑定，例如 Azure 队列存储输出绑定。在下面的示例中，写入到队列的消息具有值“output #1”：

PS >Push-OutputBinding -Name outQueue -Value "output #1"

存储队列的输出绑定接受多个输出值。在本例中，在第一个示例之后调用以下示例会向队列中写入具有以下两个项的列表：“output #1”和“output #2”。

PS >Push-OutputBinding -Name outQueue -Value "output #2"

在前两个示例之后调用时，以下示例向输出集合添加两个额外的值：

PS >Push-OutputBinding -Name outQueue -Value @("output #3", "output #4")

写入到队列时，消息包含这四个值：“output #1”、“output #2”、“output #3”和“output #4”。

Get-OutputBinding cmdlet

可以使用 Get-OutputBinding cmdlet 来检索当前为你的输出绑定设置的值。此 cmdlet 会检索一个包含输出绑定名称及其各自值的哈希表。

下面是使用 Get-OutputBinding 返回当前绑定值的示例：

Get-OutputBinding

Name                           Value
----                           -----
MyQueue                        myData
MyOtherQueue                   myData

Get-OutputBinding 还包含一个名为 -Name 的参数，该参数可用于筛选返回的绑定，如以下示例所示：

Get-OutputBinding -Name MyQ*

Name                           Value
----                           -----
MyQueue                        myData

Get-OutputBinding 支持通配符 (*)。

Logging

PowerShell 函数中的日志记录的工作方式类似于常规的 PowerShell 日志记录。你可以使用日志记录 cmdlet 将内容写入到每个输出流。每个 cmdlet 都映射到 Functions 使用的一个日志级别。

Functions 日志记录级别	日志记录 cmdlet
错误	`Write-Error`
警告	`Write-Warning`
信息	`Write-Information` `Write-Host` `Write-Output` 写入 `Information` 日志级别。
调试	`Write-Debug`
跟踪	`Write-Progress` `Write-Verbose`

除了这些 cmdlet 外，写入到管道的任何内容都会重定向到 Information 日志级别，并以默认的 PowerShell 格式设置进行显示。

重要

并非仅使用 Write-Verbose 或 Write-Debug cmdlet 就可以查看详细级别和调试级别的日志记录。你还必须配置日志级别阈值，该阈值声明你实际关注的日志级别。若要了解详细信息，请参阅配置函数应用日志级别。

配置函数应用日志级别

可以使用 Azure Functions 来定义阈值级别，以便轻松控制 Functions 向日志写入内容的方式。若要针对写入到控制台的所有跟踪设置阈值，请在 host.json 文件中使用 logging.logLevel.default 属性。此设置应用于 Function App 中的所有函数。

以下示例将阈值设置为对所有函数启用详细日志记录，但将阈值设置为对名为 MyFunction 的函数启用调试日志记录：

{
    "logging": {
        "logLevel": {
            "Function.MyFunction": "Debug",
            "default": "Trace"
        }
    }
}

有关详细信息，请参阅 host.json 参考。

查看日志

如果你的函数应用在 Azure 中运行，则可以使用 Application Insights 监视它。若要了解有关查看和查询函数日志的详细信息，请阅读监视 Azure Functions。

如果要在本地运行函数应用以进行开发，则日志会默认保存到文件系统。若要在控制台中查看日志，请在启动函数应用之前将 AZURE_FUNCTIONS_ENVIRONMENT 环境变量设置为 Development。

触发器和绑定类型

有许多触发器和绑定可以用于你的函数应用。可在此处找到触发器和绑定的完整列表。

所有触发器和绑定在代码中都表示为一些真实的数据类型：

Hashtable
字符串
byte[]
int
Double
HttpRequestContext
HttpResponseContext

此列表中的前五个类型是标准 .NET 类型。最后两个类型仅由 HttpTrigger 触发器使用。

函数中的每个绑定参数都必须是这些类型之一。

HTTP 触发器和绑定

HTTP 和 webhook 触发器以及 HTTP 输出绑定使用请求和响应对象来表示 HTTP 消息。

请求对象

传递给脚本的请求对象是 HttpRequestContext 类型的，它具有以下属性：

properties	说明	类型
`Body`	一个包含请求正文的对象。 `Body` 基于数据序列化为最佳类型。例如，如果数据是 JSON，则它将作为哈希表传入。如果数据是字符串，则它将作为字符串传入。	对象
`Headers`	一个包含请求头的字典。	Dictionary<string,string>^*
`Method`	请求的 HTTP 方法。	字符串
`Params`	一个包含请求的路由参数的对象。	Dictionary<string,string>^*
`Query`	一个包含查询参数的对象。	Dictionary<string,string>^*
`Url`	请求的 URL。	字符串

^* 所有 Dictionary<string,string> 键都不区分大小写。

响应对象

应当发送回的响应对象的类型为 HttpResponseContext，该类型具有以下属性：

Property	说明	类型
`Body`	一个包含响应正文的对象。	对象
`ContentType`	一种速记形式，用于设置响应的内容类型。	字符串
`Headers`	一个包含响应标头的对象。	字典或哈希表
`StatusCode`	响应的 HTTP 状态代码。	字符串或整数

访问请求和响应

使用 HTTP 触发器时，可以使用与任何其他输入绑定相同的方式访问 HTTP 请求。它位于 param 块中。

使用 HttpResponseContext 对象返回一个响应，如以下示例所示：

function.json

{
  "bindings": [
    {
      "type": "httpTrigger",
      "direction": "in",
      "authLevel": "anonymous"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

run.ps1

param($req, $TriggerMetadata)

$name = $req.Query.Name

Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
    StatusCode = [System.Net.HttpStatusCode]::OK
    Body = "Hello $name!"
})

调用此函数的结果为：

PS > irm http://localhost:5001?Name=Functions
Hello Functions!

触发器和绑定的类型强制转换

对于某些绑定（例如 blob 绑定），你可以指定参数的类型。

例如，若要将 Blob 存储中的数据作为字符串提供，请将以下类型强制转换添加到 param 块：

param([string] $myBlob)

PowerShell 配置文件

在 PowerShell 中存在 PowerShell 配置文件的概念。如果你不熟悉 PowerShell 配置文件，请参阅关于配置文件。

在 PowerShell 函数中，在首次部署并闲置后，会在应用中为每个 PowerShell 工作进程实例执行一次配置文件脚本（冷启动）。如果通过设置 PSWorkerInProcConcurrencyUpperBound 值启用了并发，则会为所创建的每个运行空间运行配置文件脚本。

当你使用工具（例如 Visual Studio Code 和 Azure Functions Core Tools）创建函数应用时，系统会为你创建一个默认的 profile.ps1。默认配置文件在 Core Tools GitHub 存储库中维护，其中包含：

自动向 Azure 进行 MSI 身份验证的功能。
根据需要启用 Azure PowerShell AzureRM PowerShell 别名的功能。

PowerShell 版本

下表显示了适用于 Functions 运行时的每个主要版本的 PowerShell 版本，以及所需的 .NET 版本：

Functions 版本	PowerShell 版本	.NET 版本
4.x	PowerShell 7.4	.NET 8
4.x	PowerShell 7.2（支持结束）	.NET 6

可以通过输出任何函数的 $PSVersionTable 来查看当前版本。

若要详细了解 Azure Functions 运行时支持策略，请参阅本文

注意

Azure Functions 中对 PowerShell 7.2 的支持将于 2024 年 11 月 8 日结束。升级 PowerShell 7.2 函数以在 PowerShell 7.4 上运行时，可能需要解决一些中断性变更。请按照此迁移指南升级到 PowerShell 7.4。

在特定版本上以本地方式运行

载本地运行 PowerShell 功能时，需要在项目根目录的 local.setting.json 文件的 Values 数组中添加设置 "FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.4"。在 PowerShell 7.4 上以本地方式运行时，你的 local.settings.json 文件类似于以下示例：

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "",
    "FUNCTIONS_WORKER_RUNTIME": "powershell",
    "FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.4"
  }
}

注意

在 PowerShell 函数中，FUNCTIONS_WORKER_RUNTIME_VERSION 的值“~7”是指“7.0.x”。我们不会将具有“~7”的 PowerShell 函数应用自动升级到“7.4”。今后，对于 PowerShell 函数应用，我们将要求应用同时指定它们要面向的主要和次要版本。因此，如果要面向“7.4.x”，则必须提及“7.4”

更改 PowerShell 版本

在将 PowerShell 函数应用迁移到 PowerShell 7.4 之前，请考虑到以下注意事项：

由于迁移可能会在应用中引入中断性变更，因此请在将应用升级到 PowerShell 7.4 之前查看此迁移指南。
确保函数应用在 Azure 中最新版本的 Functions 运行时上运行，即版本 4.x。有关详细信息，请参阅查看和更新当前运行时版本。

请使用以下步骤更改函数应用使用的 PowerShell 版本。可以在 Azure 门户中或使用 PowerShell 执行此操作。

Portal
PowerShell

在 Azure 门户中，浏览到你的函数应用。
在“设置”下，选择“配置”。在“常规设置”选项卡中，找到“PowerShell 版本”。
选择所需的 PowerShell Core 版本并选择“保存”。收到等待重启的警告时，请选择“继续”。函数应用会在所选的 PowerShell 版本上重启。

注意

PowerShell 7.4 的 Azure Functions 支持已正式发布（正式版）。你可能会在 Azure 门户中看到 PowerShell 7.4 仍显示为预览版，但这将很快更新，以反映 GA 状态。

运行以下脚本以更改 PowerShell 版本：

Set-AzResource -ResourceId "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<FUNCTION_APP>/config/web" -Properties @{  powerShellVersion  = '<VERSION>' } -Force -UsePatchSemantics

将 <SUBSCRIPTION_ID>、<RESOURCE_GROUP> 和 <FUNCTION_APP> 分别替换为你的 Azure 订阅的 ID、你的资源组的名称和函数应用。此外，还将 <VERSION> 替换为 7.4。你可以在返回的哈希表的 Properties 中验证 powerShellVersion 设置更新后的值。

在对配置进行更改后，函数应用会重启。

依赖项管理

可以通过两种方式在 PowerShell 中编写的 Azure Functions 中管理模块：使用托管依赖项功能或直接在应用内容中包含模块。两种方法各有优点，选择正确的方法取决于你的特定需求。

选择正确的模块管理方法

为何使用托管依赖项功能？

简化的初始安装：根据 requirements.psd1 文件自动处理模块安装。
自动升级：模块会自动更新（包括安全修补程序），无需手动干预。

为什么在应用内容中包含模块？

不依赖 PowerShell 库：模块与应用捆绑，无需外部依赖项。
更可控：避免自动升级导致的回归风险，可完全控制使用哪些模块版本。
兼容性：适用于 Flex 消耗，也建议用于其他 Linux SKU。

托管依赖项功能

托管依赖项功能让 Azure Functions 能够自动下载和管理 requirements.psd1 文件中指定的 PowerShell 模块。此功能在新 PowerShell 函数应用中默认启用。

配置 requirements.psd1

若要将 Azure Functions 中的托管依赖项与 PowerShell 配合使用，需要配置 requirements.psd1 文件。此文件指定函数所需的模块，而 Azure Functions 会自动下载和更新这些模块，以确保环境保持最新状态。

下面介绍如何设置和配置 requirements.psd1 文件：

如果 Azure 函数的根目录中不存在 requirements.psd1 文件，请创建一个。
在 PowerShell 数据结构中定义模块及其版本。

示例 requirements.psd1 文件：

@{
    'Az' = '9.*'  # Specifies the Az module and will use the latest version with major version 9
}

在应用内容中包含模块

若要更好地控制模块版本并避免依赖外部资源，可以直接在函数应用的内容中包含模块。

若要包含自定义模块，请执行以下操作：

在函数应用的根目录中创建 Modules 文件夹。
```
mkdir ./Modules
```
使用以下方法之一将模块复制到 Modules 文件夹：
- 如果模块已在本地可用：
```
Copy-Item -Path /mymodules/mycustommodule -Destination ./Modules -Recurse
```
- 使用 Save-Module 从 PowerShell 库检索：
```
Save-Module -Name MyCustomModule -Path ./Modules
```
- 从 PSResourceGet 模块使用 Save-PSResource：
```
Save-PSResource -Name MyCustomModule -Path ./Modules
```

函数应用应具有以下结构：

PSFunctionApp
 | - MyFunction
 | | - run.ps1
 | | - function.json
 | - Modules
 | | - MyCustomModule
 | | - MyOtherCustomModule
 | | - MySpecialModule.psm1
 | - local.settings.json
 | - host.json
 | - requirements.psd1

当你启动函数应用时，PowerShell 语言工作进程会将此 Modules 文件夹添加到 $env:PSModulePath 中，以便你可以像在常规 PowerShell 脚本中那样依赖于模块自动加载。

对托管依赖项进行故障排除

启用托管依赖项

若要使托管依赖项正常运行，必须在 host.json 中启用该功能：

{
  "managedDependency": {
          "enabled": true
       }
}

目标特定版本

面向特定模块版本时，请务必遵循以下两条步骤来确保加载正确的模块版本：

指定 requirements.psd1 中的模块版本：
```
@{
  'Az.Accounts' = '1.9.5'
}
```

向 profile.ps1 添加导入语句：

Import-Module Az.Accounts -RequiredVersion '1.9.5'

执行以下步骤可确保在函数启动时加载指定的版本。

配置特定的托管依赖项间隔设置

可以使用以下应用设置配置托管依赖项的下载和安装方式：

设置	默认值	说明
MDMaxBackgroundUpgradePeriod	`7.00:00:00`（七天）	控制 PowerShell 函数应用的后台更新时间段。
MDNewSnapshotCheckPeriod	`01:00:00`（一小时）	指定 PowerShell 辅助角色检查更新的频率。
MDMinBackgroundUpgradePeriod	`1.00:00:00`（一天）	升级检查之间的最短时间。

依赖关系管理注意事项

Internet 访问：托管依赖项需要访问 https://www.powershellgallery.com 以下载模块。请确保环境允许此访问，包括根据需要修改防火墙/VNet 规则。
许可证接受：托管依赖项不支持需要接受许可证的模块。
Flex 消耗计划：Flex 消耗计划不支持托管依赖项功能。请改用自定义模块。
模块位置：在本地计算机上，模块通常安装在 $env:PSModulePath 的一个全局可用文件夹中。在 Azure 中运行时，PowerShell 函数应用的 $env:PSModulePath 不同于常规 PowerShell 脚本中的 $env:PSModulePath，而且它将包含随应用内容上传的 Modules 文件夹以及由托管依赖项管理的单独位置。

环境变量

在 Functions 中，服务连接字符串等应用设置在执行过程中将公开为环境变量。可以使用 $env:NAME_OF_ENV_VAR 访问这些设置，如以下示例所示：

param($myTimer)

Write-Host "PowerShell timer trigger function ran! $(Get-Date)"
Write-Host $env:AzureWebJobsStorage
Write-Host $env:WEBSITE_SITE_NAME

可以通过以下几种方法添加、更新和删除函数应用设置：

如果更改函数应用设置，则需要重启函数应用。

在本地运行时，可从 local.settings.json 项目文件读取应用设置。

并发

默认情况下，Functions PowerShell 运行时一次只能处理一个函数调用。但是，在以下情况下，此并发级别可能不够高：

当你尝试同时处理大量调用时。
当函数调用同一函数应用内的其他函数时。

你可以根据工作负荷的类型来探索几个并发模型：

增大 FUNCTIONS_WORKER_PROCESS_COUNT。增加此设置后，就可以在同一实例的多个进程中处理函数调用，这会带来一定的 CPU 和内存开销。通常，I/O 绑定函数不受此开销影响。对于 CPU 绑定函数，影响可能会很大。
增大 PSWorkerInProcConcurrencyUpperBound 应用设置值。增加此设置后，就可以在同一进程中创建多个运行空间，从而大大降低 CPU 和内存开销。

可以在函数应用的应用设置中设置这些环境变量。

Durable Functions 可能会显著提高可伸缩性，具体取决于你的用例。若要了解详细信息，请参阅 Durable Functions 应用程序模式。

注意

你可能会收到“请求正在排队，因为没有可用的运行空间”警告，请注意这不是错误。此消息通知你，请求正在排队，会在前面的请求完成后获得处理。

使用并发时的注意事项

默认情况下，PowerShell 是单线程脚本语言。但是，可以通过在同一进程中使用多个 PowerShell 运行空间来添加并发。创建的运行空间的数量，因此，每个工作器的并发线程数会受 PSWorkerInProcConcurrencyUpperBound 应用程序设置限制。在默认情况下，Functions 运行时的版本 4.x 中的运行空间数设置为 1,000。在版本 3.x 及更低版本中，最大运行空间数设置为 1。函数应用的吞吐量受所选计划中可用的 CPU 和内存量的影响。

Azure PowerShell 使用某些进程级上下文和状态，避免你进行过多的键入。但是，如果你在函数应用中启用并发，并调用可更改状态的操作，则可能会出现争用情况。这些争用情况很难调试，因为一个调用依赖于某个特定状态，而另一个调用更改了该状态。

Azure PowerShell 提供的并发性具有巨大的价值，因为某些操作可能需要相当长的时间。但是，你必须谨慎操作。如果怀疑出现争用情况，请将 PSWorkerInProcConcurrencyUpperBound 应用设置设为 1，并且为并发改用语言工作进程级隔离。

配置函数 scriptFile

默认情况下通过 run.ps1（一个文件，与对应的 function.json 共享相同父目录）执行 PowerShell 函数。

可以使用 function.json 中的 scriptFile 属性来获取以下示例所示的文件夹结构：

FunctionApp
 | - host.json
 | - myFunction
 | | - function.json
 | - lib
 | | - PSFunction.ps1

在本例中，myFunction 的 function.json 包括一个 scriptFile 属性，该属性引用要运行的已导出函数所在的文件。

{
  "scriptFile": "../lib/PSFunction.ps1",
  "bindings": [
    // ...
  ]
}

通过配置 entryPoint 来使用 PowerShell 模块

本文使用了模板生成的默认 run.ps1 脚本文件展示 PowerShell 函数。但是，你还可以在 PowerShell 模块中包含你的函数。你可以通过在 function.json 配置文件中使用 scriptFile 和 entryPoint 字段来引用模块中的特定函数代码。

在本例中，entryPoint 是 scriptFile 中引用的 PowerShell 模块中的函数或 cmdlet 的名称。

考虑以下文件夹结构：

FunctionApp
 | - host.json
 | - myFunction
 | | - function.json
 | - lib
 | | - PSFunction.psm1

其中，PSFunction.psm1 包含：

function Invoke-PSTestFunc {
    param($InputBinding, $TriggerMetadata)

    Push-OutputBinding -Name OutputBinding -Value "output"
}

Export-ModuleMember -Function "Invoke-PSTestFunc"

在此示例中，myFunction 的配置包含 scriptFile 属性，该属性引用 PSFunction.psm1，这是另一文件夹中的 PowerShell 模块。 entryPoint 属性引用 Invoke-PSTestFunc 函数，该函数是模块中的入口点。

{
  "scriptFile": "../lib/PSFunction.psm1",
  "entryPoint": "Invoke-PSTestFunc",
  "bindings": [
    // ...
  ]
}

使用此配置，Invoke-PSTestFunc 会完全像 run.ps1 那样执行。

PowerShell 函数的注意事项

使用 PowerShell 函数时，请注意以下各部分中的注意事项。

冷启动

当在无服务器托管模型中开发 Azure Functions 时，冷启动是存在的现实情况。冷启动指的是函数应用开始运行以处理请求所经历的时间段。在消耗计划中，冷启动的发生更频繁，因为函数应用在非活动期间会关闭。

避免使用 Install-Module

在每个调用的函数脚本中运行 Install-Module 可能会导致性能问题。请在发布函数应用之前使用 Save-Module 或 Save-PSResource 绑定必要的模块。

有关详细信息，请参阅依赖项管理部分。

后续步骤

有关详细信息，请参阅以下资源：

通过