Functions
最后更新：2026 年 7 月 16 日
你游戏的服务端逻辑 —— 全球运行，自动扩缩。用 TypeScript、JavaScript、Python 或 Go 编写，用 PlayServ CLI 部署 —— 没有基础设施要你操心。
Functions 一节位于 Project 侧边栏的 Engineering 之下。五个标签页覆盖了全部内容：Overview、Functions、Bindings、Logs 和 History。
Function 由 PlayServ CLI 创建和部署，从你的本地工程运行。一次部署完成后，这个 Function 就会出现在下面各个标签页中，带有实时状态、指标和日志。
Overview
当前 Environment 中所有 Function 的实时健康看板。
Function 列表
Project 中的所有 Function，汇总在一张表里。
按名称、描述或语言搜索。用 Status 和 Runtime 下拉框筛选 —— 在较大的项目里很有用，比如你只想看正在失败的 Python Function。
每一行都把要紧的东西摆在明面上：
语言标记（Js、Py、Go、C#）、Function 名称，以及来自清单的一行描述。
状态标记、副本数（运行中 / 期望值）、当前与上一个 24 小时周期的调用次数、错误率、P95 延迟，以及部署日期和 commit SHA。
状态
已部署并正在承载流量。正常的健康状态。
已部署但不接收流量。适合在转为 live 之前做灰度验证。
副本正在崩溃，或错误数超过了配置的阈值。需要处理。
已手动停止 。所有副本都已下线，这个 Function 不会接受调用。
点击右上角的 + New function，可以从模板脚手架出一个新 Function。这项功能尚未推出 —— 请用 CLI 创建新的 Function。
Function 详情面板
点击任意一行，右侧会打开详情面板。顶部显示 Function 名称、扩缩策略、上次部署日期与 commit SHA，以及实时状态。四个标签页提供完整的控制。
Status
单个 Function 的实时健康状况。顶部有三块统计区：
none，受保护的用 player。Replicas 列出每个活跃实例的 ID、区域、uptime、内存和 CPU。点击 Scale 可立即调整副本数 —— 无需重新部署。点击任意副本行可展开 At a glance：
(current)—Bindings
运行时注入到这个 Function 里的全部配置。分两块。
Env vars —— 完整的变量表：
LOG_LEVEL、NODE_ENVmanifest —— 在 platform.json 中声明autofix 一同显示覆盖值立即生效并重启副本 —— 不需要重新部署。清单中的默认值在这里是只读的。
Secrets —— 关联到这个 Function 的凭据：
STRIPE_WEBHOOK_SECRET、DATABASE_URLlinked；secret 尚未设置时为 missing点击 Rotate 生成新值。点击 Open project Bindings → 管理 Project 级的全部 secret。
Settings
这个 Function 的运行时行为。独立保存 —— 不需要重新部署代码。
auto 且指标为请求并发时，Scaling 卡片中的 Target 值会作为相对该上限的软触发阈值。none —— 允许匿名调用方；适合公开 webhook 和开放 endpoint。player —— 调用方必须出示已登录的 Player 会话（叠加在 Project 的 pk_* key 之上的 Player JWT）；PlayServ 会在 handler 内填好 ctx.player。manual —— 副本数由你自己控制。auto —— 平台按请求并发相对 Max concurrency 的比例 自动扩缩。manual 时的目标实例数。点击 Scale 立即生效。Deploys
这个特定 Function 的完整部署历史 —— 每一次经手过它的构建，最新的在最前。
live · draining（流量正在切向更新的版本）· archivedsucceeded，或 Build failed 并附上构建日志链接locked；archived 的显示删除图标在旧版本的在途请求处理完毕、流量完全切换之前，这次部署会处于 draining 状态。
Deploys 面板是只读的。所有部署的唯一可信来源是你的 CLI —— 在这里既不能触发部署，也不能回滚。
Function 的版本
默认情况下，每次部署都会替换掉那个没有 tag 的 latest，它承载全部流量。若要让同一个 Function 的第二个可寻址版本并行运行 —— 用于灰度验证，或某个固定版本的客户端 —— 就带上 version tag 部署：
playserv-cli deploy --tag ver2
带 tag 的部署会拿到自己的可寻址 URL，并且默认不分走任何流量 —— 所有常规调用仍由没有 tag 的 latest 承接。用同一个 tag 重新部署会就地改指向（后写者胜）；不同 tag 之间互不覆盖。
要调用某个特定版本，在调用 /fn/{slug} 时用 header 带上它的 tag：
X-Playserv-Function-Version: ver2
不带版本 header 时，调用会走 latest。如果 header 里指定的 tag 并未上线，调用会以 function_version_not_found 失败 —— 不会悄悄回落到 latest。从另一个 Function 发起时，SDK 用调用上的 target_version 选择版本，而不是 header。
version tag 长度为 3 到 22 个字符，由小写字母、数字和连字符组成，且必须以字母开头 —— 例如 ver2 或 v2-canary。v1 比合法 tag 短了一个字符。
把某个部署从 dev 提升到 prod 时，它的 tag 会一并带过去：带 tag 的来源会以同样的 tag 落在 prod 且不发生流量切换（可用同一个 header 访问）；不带 tag 的来源则成为 prod 新的 latest。
按分支自动部署
Project 可以把 git 分支绑定到 Environment，这样往该分支推送就会自动部署到映射的 Environment —— 例如 main → prod、develop → dev。绑定建立之后，合并到该分支就会触发部署，不需要手动执行 CLI；产生的构建会带着分支和 commit 出现在 Deploys 和 History 视图中，与 CLI 部署一模一样。
分支绑定按 Project 管理（列出、创建、更新、移除），每条绑定把一个分支映射到一个目标 Environment。没有绑定的分支就不会自动部署 —— 在你添加绑定之前，推送到它的提交会被部署流水线忽略。
自动部署和手动 CLI 部署底层用的是同一条流水线 —— 分支绑定只是决定自动化构建落到哪个 Environment。无论部署是由推送触发还是由 CLI 触发，version tag 和提升的行为完全一致。
Bindings 标签页
Functions 一节顶部的 Bindings 标签页是一个覆盖整个 Project 的视图 —— 所有 Function 的所有 env var 汇总在一张扁平表里，列与单个 Function 视图中的相同。
Logs
面向整个 Environment、跨所有 Function 的实时日志流。
左侧面板列出所有 Function 及其未读数。点击即可筛选，用复选框可多选。Mark all / Unmark all 切换全选状态。
每条记录包含：精确到毫秒的时间戳、级别标记（INFO 蓝色 · WARN 琥珀色 · ERROR 红色）、Function 名称和消息内容。带追踪的调用会附上 trace: <id> 后缀 —— 同一次调用产生的所有行共用这个 ID。
流控制项：
调试时把范围筛到单个 Function 并打开 Live —— 你触发调用的同时就能实时看到输出。
History
Project 中任何 Function 经历过的每一次部署 —— 覆盖整个 Project 的部署日志，最新的在最前。
每条记录显示一个状态圆点（绿色 = 成功，红色 = 失败）、带分支和短 commit SHA 的 git 修订、commit 信息、作者、相对时间、改动的 Function 数量以及构建时长。失败的构建会显示 Build failed 标记，并附 View build logs 链接。
用 Time range 和 Environment 下拉框筛选。
History 收录每一次成形的部署 —— 包括失败的构建和没有改动任何 Function 的推送。用 Environment 筛选器把 dev 和 prod 的历史分开看。
下一步
- RPC & Server-side Game Logic —— 运行在 SDK 运行时内部的服务端游戏逻辑，与独立的 Function 是两种不同的模型
- API Key Management —— 支撑 Function bindings 的那些 key 和 secret