【免费下载链接】autoskillsOne command. Your entire AI skill stack. Installed.项目地址https://gitcode.com/gh_mirrors/au/autoskills点击查看免费下载导读本文基于 autoskills 仓库中 cloudflare-deploy Skill 的 Smart Placement 模式参考文档系统讲解在 Cloudflare Workers 上利用 Smart Placement 优化后端延迟的六种实战模式数据库访问型 Worker、前后端拆分Service Bindings、外部 API 集成、SSR/API 网关、Durable Objects 协调以及必须避开的 RPC 陷阱。读完本文你将掌握每种模式的完整代码与 wrangler 配置、明确“何时该开 / 何时绝不能开”Smart Placement 的判定标准并学会用placement_status与cf-placement验证优化是否真正生效。Smart Placement 是什么把 Worker 放到离“后端”更近的地方Smart Placement 是一种自动化的 Worker 负载放置优化Cloudflare 会持续分析 Worker 在全局网络上的请求耗时将请求智能路由到更优的数据中心位置而不是机械地总是运行在离终端用户最近的数据中心。当 Worker 的耗时主要来自与后端基础设施数据库、私有 API的多次往返时把 Worker 放到离后端更近的位置就能显著降低整体请求时长。在 cloudflare-deploy Skill 的 SKILL.md 中Smart Placement 被定位为“优化到后端基础设施的延迟”的专门产品与 Argo Smart Routing优化到用户的路径形成互补。该 Skill 的主文档 README.md 给出了清晰的启用判定决策树Does your Worker have a fetch handler? ├─ No → Smart Placement wont work (skip) └─ Yes │ Does it make multiple backend calls (DB/API)? ├─ No → Dont enable (wont help) └─ Yes │ Is backend geographically concentrated? ├─ No (globally distributed) → Probably wont help └─ Yes or uncertain │ Does it serve static assets with run_worker_firsttrue? ├─ Yes → Dont enable (will hurt performance) └─ No → Enable Smart Placement │ After 15min, check placement_status ├─ SUCCESS → Monitor metrics ├─ INSUFFICIENT_INVOCATIONS → Need more traffic └─ UNSUPPORTED_APPLICATION → Disable (hurting performance)一句话概括适用边界应当启用Worker 对后端服务/数据库有多轮往返后端基础设施在地理上集中请求耗时主要被后端延迟而非用户网络延迟主导Worker 承担 API、数据聚合、含数据库调用的 SSR 等后端逻辑且使用fetch处理器。绝不启用仅服务静态内容或缓存响应的 Worker几乎不与后端通信的 Worker纯边缘逻辑鉴权检查、重定向、简单变换没有fetch事件处理器的 Worker仅暴露 RPC 方法或具名入口的 Worker以及开启了run_worker_first true的 Pages/Assets Worker会严重拖慢静态资源分发见后文。基础配置wrangler.jsonc 中的 placement 字段启用 Smart Placement 只需在 wrangler 配置中声明一个字段configuration.md{ $schema: ./node_modules/wrangler/config-schema.json, placement: { mode: smart } }Placement 模式取值Mode行为smart启用 Smart Placement基于流量分析自动优化off显式禁用始终运行在离用户最近的边缘节点不指定默认行为——运行在离用户最近的边缘节点等同于off关闭的方式有两种且效果完全相同显式写{ placement: { mode: off } }或干脆删掉整个placement字段。注意Smart Placement 与“显式放置Explicit Placement”是两套独立功能——mode: smart走自动分析而手动指定region、host、hostname属于显式放置两者互斥不能混用// ✅ 合法 - Smart Placement { placement: { mode: smart } } // ✅ 合法 - 显式放置另一套功能 { placement: { region: us-east1 } } // ❌ 非法 - 二者不可组合 { placement: { mode: smart, region: us-east1 } }硬性要求与局限Wrangler 版本须 ≥ 2.20.0启用后最多需要 15 分钟分析期期间 Worker 仍运行在边缘需要来自多个全球位置的持续流量才能得出有意义的放置结论所有 Workers 套餐Free / Paid / Enterprise均可用Smart Placement 在wrangler dev本地开发中不生效只能在生产部署中激活想本地验证需部署到 staging 环境wrangler deploy --env staging。模式一带数据库访问的后端 Worker这是最直接的场景Worker 本身承担 API 后端职责频繁访问 D1 等数据库。开启 Smart Placement 后Worker 的fetch处理器会被调度到离数据库更近的位置缩短每次查询的网络往返。export default { async fetch(request: Request, env: Env): PromiseResponse { const user await env.DATABASE.prepare(SELECT * FROM users WHERE id ?).bind(userId).first(); const orders await env.DATABASE.prepare(SELECT * FROM orders WHERE user_id ?).bind(userId).all(); return Response.json({ user, orders }); } };对应的 wrangler 配置同时声明 Smart Placement 与 D1 绑定{ placement: { mode: smart }, d1_databases: [{ binding: DATABASE, database_id: xxx }] }从 D1 参考文档 可以看到 D1 查询 API 的语义.first()返回首行或null.all()返回全部行二者都支持.bind()参数绑定天然适合与 Smart Placement 配合——多次查询合并到同一地理位置执行能最大限度摊薄查询延迟。文档同时指出对“数据库密集型 Worker”Smart Placement 通常可带来请求时长 20–50% 的典型降幅详见 api.md 的指标解读章节。模式二前后端拆分Service Bindings全栈应用的最佳架构是拆成两个 Worker前端 Worker 不开启 Smart Placement始终贴近用户提供快速响应后端 Worker 开启 Smart Placement运行在数据库附近。二者通过 Service Binding 串联。前端 Worker 代码——按路径前缀把 API 请求转发给后端// Frontend Worker - routes requests to backend interface Env { BACKEND: Fetcher; // Service Binding to backend Worker } export default { async fetch(request: Request, env: Env): PromiseResponse { if (new URL(request.url).pathname.startsWith(/api/)) { return env.BACKEND.fetch(request); // Forward to backend } return new Response(Frontend content); } };后端 Worker 代码——只做数据库操作// Backend Worker - database operations interface BackendEnv { DATABASE: D1Database; } export default { async fetch(request: Request, env: BackendEnv): PromiseResponse { const data await env.DATABASE.prepare(SELECT * FROM table).all(); return Response.json(data); } };两份 wrangler 配置来自 configuration.md// frontend-worker/wrangler.jsonc —— 不写 placement留在边缘 { name: frontend, main: frontend-worker.ts, services: [ { binding: BACKEND, service: backend-api } ] }// backend-api/wrangler.jsonc —— 开启 Smart Placement { name: backend-api, main: backend-worker.ts, placement: { mode: smart }, d1_databases: [ { binding: DATABASE, database_id: xxx } ] }关于 Service Binding 还有两点值得注意见 bindings 的 patterns.mdService Binding 的 URL 无关紧要——路由靠绑定名binding name而非 hostname/协议所以示例里env.BACKEND.fetch(request)直接转发原始请求即可相比跨区域 HTTP 调用慢、计费、跨区延迟Service Binding 同数据中心直连、零额外 DNS 开销且免费。⚠️ 关键警告只能用 fetch 式 Service Binding不能用 RPC这是本 Skill 反复强调的最高优先级约束Smart Placement 只对基于 fetch 的绑定生效对 RPC 完全不生效。// ❌ RPC - Smart Placement 对后端 RPC 方法无效 export class BackendRPC extends WorkerEntrypoint { async getData() { // 始终运行在边缘Smart Placement 被忽略 return await this.env.DATABASE.prepare(SELECT * FROM table).all(); } } // ✅ Fetch - Smart Placement 生效 export default { async fetch(request: Request, env: Env): PromiseResponse { // 启用 Smart Placement 后运行在 DATABASE 附近 const data await env.DATABASE.prepare(SELECT * FROM table).all(); return Response.json(data); } };原因在于Smart Placement 只能路由fetch请求而 RPC 调用绕过了fetch处理器gotchas.md。受影响的还包括具名入口非 default 导出、队列消费者Queue consumers、定时处理器scheduled handler等其他事件类型。如果后端逻辑已经写成WorkerEntrypoint解决方案是把 RPC 方法改造成 fetch 端点或用带fetch处理器的包装 Worker 中转后者会引入额外延迟非首选。模式三外部 API 集成当 Worker 需要聚合多个第三方 API 的响应时开启 Smart Placement 能让它运行在更靠近这些 API 服务的地理位置配合Promise.all并行请求进一步压降总时长。export default { async fetch(request: Request, env: Env): PromiseResponse { const apiUrl https://api.partner.com; const headers { Authorization: Bearer ${env.API_KEY} }; const [profile, transactions] await Promise.all([ fetch(${apiUrl}/profile, { headers }), fetch(${apiUrl}/transactions, { headers }) ]); return Response.json({ profile: await profile.json(), transactions: await transactions.json() }); } };配套实践参考 bindings/patterns.md密钥通过wrangler secret管理绝不写进配置npx wrangler secret put API_KEY可用cat api-key.txt | npx wrangler secret put API_KEY从文件注入或加--env staging区分环境然后代码里按请求访问env.API_KEY严禁把sk_live_abc123这类值硬编码或塞进vars。并行化独立请求多个互不依赖的后端调用用Promise.all合并这与 Smart Placement 的收益叠加——聚合点离 API 越近每路并行请求的网络开销越小。文档 api.md 指出对于“多次后端 API 调用”的 WorkerSmart Placement 的典型改善幅度为请求时长降低 30–60%若后端在地理上高度集中收益还会更大。模式四SSR / API 网关模式服务端渲染或 API 网关场景同样遵循“边缘做轻活、后端做重活”的拆分原则鉴权与路由贴近用户边缘数据库操作贴近数据Smart Placement。// Frontend (edge) - auth/routing close to user export default { async fetch(request: Request, env: Env) { if (!request.headers.get(Authorization)) { return new Response(Unauthorized, { status: 401 }); } const data await env.BACKEND.fetch(request); return new Response(renderPage(await data.json()), { headers: { Content-Type: text/html } }); } }; // Backend (Smart Placement) - DB operations close to data export default { async fetch(request: Request, env: Env) { const data await env.DATABASE.prepare(SELECT * FROM pages WHERE id ?).bind(pageId).first(); return Response.json(data); } };这一模式把“需要快速响应用户”的逻辑鉴权失败立即 401、HTML 渲染与“需要靠近数据”的逻辑页面内容查询彻底解耦。前端 Worker 留在边缘用户交互保持敏捷后端 Worker 开启 Smart Placement数据库查询的网络往返被压缩。这正是 README.md 推荐的关键架构模式User → Frontend Worker (at edge, close to user) ↓ Service Binding Backend Worker (Smart Placement enabled, close to DB/API) ↓ Database/Backend Service模式五Durable Objects 与 Smart Placement 的配合需要特别澄清一个常见误解patterns.md 明确说明Smart Placement 不控制 Durable Objects 的运行位置。DO 始终运行在其指定区域由 jurisdiction 或智能位置提示决定Smart Placement 真正影响的是协调 Workercoordinator的fetch处理器所在位置——即“谁在调用多个 DO”这个聚合点。因此推荐模式是在聚合多个 DO 数据的协调 Worker 上启用 Smart Placement让它的fetch处理器离 DO 区域更近从而减少多次 DO 调用的网络延迟。// Worker with Smart Placement - aggregates data from multiple DOs export default { async fetch(request: Request, env: Env): PromiseResponse { const userId new URL(request.url).searchParams.get(user); // Get DO stubs const userDO env.USER_DO.get(env.USER_DO.idFromName(userId)); const analyticsID env.ANALYTICS_DO.idFromName(analytics-${userId}); const analyticsDO env.ANALYTICS_DO.get(analyticsID); // Fetch from multiple DOs const [userData, analyticsData] await Promise.all([ userDO.fetch(new Request(https://do/profile)), analyticsDO.fetch(new Request(https://do/stats)) ]); return Response.json({ user: await userData.json(), analytics: await analyticsData.json() }); } };// wrangler.jsonc { placement: { mode: smart }, durable_objects: { bindings: [ { name: USER_DO, class_name: UserDO }, { name: ANALYTICS_DO, class_name: AnalyticsDO } ] } }何时有帮助Worker 的fetch处理器运行在更靠近 DO 区域的位置缩短多次 DO 调用的网络延迟DO 在地理上集中或位于特定司法管辖区jurisdiction时收益最大协调 Worker 需要发起大量串行或并行的 DO 调用时帮助明显。何时没帮助DO 全球分布不存在单一最优 Worker 位置Worker 只调用单个 DODO 调用频率低或已被缓存。补充背景见 durable-objects 的 README.mdDO 通过idFromName()生成确定性 ID、newUniqueId()生成随机 ID分片高吞吐并支持jurisdiction选项满足数据驻留合规如 EU、FedRAMPDO 实例在指定区域内单线程串行处理请求。协调 Worker 的放置优化正是围绕这些 DO 的区域特性展开的。最佳实践清单patterns.md 收尾给出了可直接落地的实践清单拆分全栈应用前端留在边缘后端启用 Smart Placement使用 fetch 式 Service Bindings不要用 RPCRPC 不受 Smart Placement 影响为后端逻辑启用API、数据聚合、数据库操作不要为以下场景启用静态内容、纯边缘逻辑、RPC 方法、以及run_worker_first的 Pages等待 15 分钟以上的分析期并验证placement_status SUCCESS。再叠加两条易踩坑的警示来自 configuration.md 与 gotchas.md① Pages/Assets run_worker_first true是最高频的误配置。Smart Placement 会把包括 HTML/CSS/JS/图片在内的所有请求都路由到远端而静态资源本应永远从离用户最近的边缘分发结果静态资源加载慢 2–5 倍。解决办法按优先级拆分成独立 Worker前端留边缘 后端开 Smart Placement 显式mode: off 设assets.run_worker_first false。// ❌ 错误示范 - 静态资源性能劣化 2-5 倍 { name: pages-app, placement: { mode: smart }, assets: { run_worker_first: true } } // ✅ 正确 - 前端留边缘后端做优化 // frontend-worker/wrangler.jsonc { name: frontend, assets: { run_worker_first: true } // 不写 placement - 运行在边缘 } // backend-worker/wrangler.jsonc { name: backend-api, placement: { mode: smart }, d1_databases: [{ binding: DB, database_id: xxx }] }② 单体全栈 Worker 不要开 Smart Placement。前后端逻辑混在同一个 Worker 里时Smart Placement 会为了后端延迟牺牲用户侧响应时间应拆成两个 Worker前端显式mode: off留在边缘后端mode: smart贴近数据。验证与监控确认优化真的生效启用不等于生效必须通过以下手段验证api.md1. Placement Status APIcurl -X GET https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/workers/services/{WORKER_NAME} \ -H Authorization: Bearer TOKEN \ -H Content-Type: application/json响应中的placement_status字段取值为type PlacementStatus | undefined // 尚未分析 | SUCCESS // 优化成功 | INSUFFICIENT_INVOCATIONS // 流量不足无法决策 | UNSUPPORTED_APPLICATION; // 反而变慢已回退各状态含义undefined字段不存在尚未分析Worker 始终运行在离用户最近的默认边缘位置SUCCESS分析完成Smart Placement 已激活Worker 运行在最优位置可能是边缘也可能是远端INSUFFICIENT_INVOCATIONS请求量不足以做放置决策需要持续的跨区域流量当前仍运行在默认边缘UNSUPPORTED_APPLICATION罕见约 1% 的 WorkerSmart Placement 反而变慢决策已回退始终运行在边缘且在重新部署前不会再次分析。2. cf-placement 响应头BetaSmart Placement 会在响应中附加路由决策头格式为{placement-type}-{IATA-code}// 远端放置Smart Placement 已路由 cf-placement: remote-LHR // 路由到伦敦 // 本地放置默认边缘路由 cf-placement: local-EWR // 留在纽瓦克边缘其中remote-*表示被路由到远端、local-*表示留在默认边缘IATA 代码是离数据中心最近的机场代码。可在代码中读取该头来观测export default { async fetch(request: Request, env: Env): PromiseResponse { const placementHeader request.headers.get(cf-placement); if (placementHeader?.startsWith(remote-)) { const location placementHeader.split(-)[1]; console.log(Smart Placement routed to ${location}); } else if (placementHeader?.startsWith(local-)) { const location placementHeader.split(-)[1]; console.log(Running at edge location ${location}); } return new Response(OK); } } satisfies ExportedHandlerEnv;注意cf-placement是 Beta 功能GA 前可能被移除或调整生产代码不应强依赖它。3. 请求时长指标对比在控制台Workers Pages → [Worker] → Metrics → Request Duration可查看直方图对比两路流量开启 Smart Placement 的 99% 流量vs未优化的 1% 基线流量Smart Placement 会自动把 1% 的请求不做优化地路由出去用于性能对比属预期行为。注意区分两个指标Request duration请求时长是从请求到达至响应送达的总时间含网络延迟Execution duration执行时长是 Worker 代码实际运行时间不含网络等待。衡量 Smart Placement 效果要用请求时长。指标对比含义行动开启 基线Smart Placement 在帮忙保持启用开启 ≈ 基线效果中性可考虑关闭以释放资源开启 基线Smart Placement 在拖后腿用mode: off关闭4. 命令行监控# 部署携带 Smart Placement 配置 wrangler deploy # 查看日志 wrangler tail your-worker-name # 按状态或放置头过滤 wrangler tail your-worker-name --status error wrangler tail your-worker-name --header cf-placement # 通过 API 检查放置状态 curl -H Authorization: Bearer $TOKEN \ https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/workers/services/$WORKER_NAME \ | jq .result.placement_status常见问题的快速排查INSUFFICIENT_INVOCATIONS流量不足。确保 Worker 收到持续的全球流量、等待更长分析时间最长 15 分钟、从多个地理位置发送测试流量并确认 Worker 有fetch事件处理器。UNSUPPORTED_APPLICATION变慢被回退。原因通常是Worker 不做后端调用边缘更快、后端调用已缓存、后端服务全球分布良好、或 Worker 在服务静态资源。对策{ placement: { mode: off } }关闭或改用独立的后端 Worker。没有请求时长指标Smart Placement 未启用、时间不足、流量不足或分析未完成。按“启用 → 等 15 分钟 → 确认placement_status SUCCESS”的链路逐项排查。cf-placement头缺失未启用、Beta 功能被移除、或 Worker 尚未完成分析。延伸阅读Smart Placement 模式参考本文核心文档Smart Placement 总览与决策树Smart Placement 配置详解Smart Placement API 与监控Smart Placement 常见坑D1 数据库参考Service Bindings 模式Durable Objects 参考 与 配置cloudflare-deploy Skill 主文档赞分享【免费下载链接】autoskillsOne command. Your entire AI skill stack. Installed.项目地址https://gitcode.com/gh_mirrors/au/autoskills点击查看免费下载相关推荐autoskills 实战Cloudflare Argo Smart Routing 集成模式全解析autoskills 实战Cloudflare Argo Smart Routing 集成模式全解析 本文基于 autoskills 仓库中 cloudflaautoskills Cloudflare 技能库 Hyperdrive 查询模式解析高并发读、多租户、连接池纪律与 Smart Placement 实战autoskills Cloudflare 技能库 Hyperdrive 查询模式解析高并发读、多租户、连接池纪律与 Smart Placement 实战 在Cloudflare Workers Smart Placement API 实战指南状态查询、cf-placement 头与请求耗时监控Cloudflare Workers Smart Placement API 实战指南状态查询、cf placement 头与请求耗时监控 Smart Pla人工智能AI 技能AI 插件上一篇INAV 飞控板指南FlyingRC F4 Wing MiniFLYINGRCF4WINGMINI目标板特性、规格与限制下一篇如何使用Echo Loop进行科学英语训练8大阶段间隔复习全攻略创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 autoskills 实战：Cloudflare Workers Smart Placement 六大典型部署模式全解析
【免费下载链接】autoskillsOne command. Your entire AI skill stack. Installed.项目地址https://gitcode.com/gh_mirrors/au/autoskills点击查看免费下载导读本文基于 autoskills 仓库中 cloudflare-deploy Skill 的 Smart Placement 模式参考文档系统讲解在 Cloudflare Workers 上利用 Smart Placement 优化后端延迟的六种实战模式数据库访问型 Worker、前后端拆分Service Bindings、外部 API 集成、SSR/API 网关、Durable Objects 协调以及必须避开的 RPC 陷阱。读完本文你将掌握每种模式的完整代码与 wrangler 配置、明确“何时该开 / 何时绝不能开”Smart Placement 的判定标准并学会用placement_status与cf-placement验证优化是否真正生效。Smart Placement 是什么把 Worker 放到离“后端”更近的地方Smart Placement 是一种自动化的 Worker 负载放置优化Cloudflare 会持续分析 Worker 在全局网络上的请求耗时将请求智能路由到更优的数据中心位置而不是机械地总是运行在离终端用户最近的数据中心。当 Worker 的耗时主要来自与后端基础设施数据库、私有 API的多次往返时把 Worker 放到离后端更近的位置就能显著降低整体请求时长。在 cloudflare-deploy Skill 的 SKILL.md 中Smart Placement 被定位为“优化到后端基础设施的延迟”的专门产品与 Argo Smart Routing优化到用户的路径形成互补。该 Skill 的主文档 README.md 给出了清晰的启用判定决策树Does your Worker have a fetch handler? ├─ No → Smart Placement wont work (skip) └─ Yes │ Does it make multiple backend calls (DB/API)? ├─ No → Dont enable (wont help) └─ Yes │ Is backend geographically concentrated? ├─ No (globally distributed) → Probably wont help └─ Yes or uncertain │ Does it serve static assets with run_worker_firsttrue? ├─ Yes → Dont enable (will hurt performance) └─ No → Enable Smart Placement │ After 15min, check placement_status ├─ SUCCESS → Monitor metrics ├─ INSUFFICIENT_INVOCATIONS → Need more traffic └─ UNSUPPORTED_APPLICATION → Disable (hurting performance)一句话概括适用边界应当启用Worker 对后端服务/数据库有多轮往返后端基础设施在地理上集中请求耗时主要被后端延迟而非用户网络延迟主导Worker 承担 API、数据聚合、含数据库调用的 SSR 等后端逻辑且使用fetch处理器。绝不启用仅服务静态内容或缓存响应的 Worker几乎不与后端通信的 Worker纯边缘逻辑鉴权检查、重定向、简单变换没有fetch事件处理器的 Worker仅暴露 RPC 方法或具名入口的 Worker以及开启了run_worker_first true的 Pages/Assets Worker会严重拖慢静态资源分发见后文。基础配置wrangler.jsonc 中的 placement 字段启用 Smart Placement 只需在 wrangler 配置中声明一个字段configuration.md{ $schema: ./node_modules/wrangler/config-schema.json, placement: { mode: smart } }Placement 模式取值Mode行为smart启用 Smart Placement基于流量分析自动优化off显式禁用始终运行在离用户最近的边缘节点不指定默认行为——运行在离用户最近的边缘节点等同于off关闭的方式有两种且效果完全相同显式写{ placement: { mode: off } }或干脆删掉整个placement字段。注意Smart Placement 与“显式放置Explicit Placement”是两套独立功能——mode: smart走自动分析而手动指定region、host、hostname属于显式放置两者互斥不能混用// ✅ 合法 - Smart Placement { placement: { mode: smart } } // ✅ 合法 - 显式放置另一套功能 { placement: { region: us-east1 } } // ❌ 非法 - 二者不可组合 { placement: { mode: smart, region: us-east1 } }硬性要求与局限Wrangler 版本须 ≥ 2.20.0启用后最多需要 15 分钟分析期期间 Worker 仍运行在边缘需要来自多个全球位置的持续流量才能得出有意义的放置结论所有 Workers 套餐Free / Paid / Enterprise均可用Smart Placement 在wrangler dev本地开发中不生效只能在生产部署中激活想本地验证需部署到 staging 环境wrangler deploy --env staging。模式一带数据库访问的后端 Worker这是最直接的场景Worker 本身承担 API 后端职责频繁访问 D1 等数据库。开启 Smart Placement 后Worker 的fetch处理器会被调度到离数据库更近的位置缩短每次查询的网络往返。export default { async fetch(request: Request, env: Env): PromiseResponse { const user await env.DATABASE.prepare(SELECT * FROM users WHERE id ?).bind(userId).first(); const orders await env.DATABASE.prepare(SELECT * FROM orders WHERE user_id ?).bind(userId).all(); return Response.json({ user, orders }); } };对应的 wrangler 配置同时声明 Smart Placement 与 D1 绑定{ placement: { mode: smart }, d1_databases: [{ binding: DATABASE, database_id: xxx }] }从 D1 参考文档 可以看到 D1 查询 API 的语义.first()返回首行或null.all()返回全部行二者都支持.bind()参数绑定天然适合与 Smart Placement 配合——多次查询合并到同一地理位置执行能最大限度摊薄查询延迟。文档同时指出对“数据库密集型 Worker”Smart Placement 通常可带来请求时长 20–50% 的典型降幅详见 api.md 的指标解读章节。模式二前后端拆分Service Bindings全栈应用的最佳架构是拆成两个 Worker前端 Worker 不开启 Smart Placement始终贴近用户提供快速响应后端 Worker 开启 Smart Placement运行在数据库附近。二者通过 Service Binding 串联。前端 Worker 代码——按路径前缀把 API 请求转发给后端// Frontend Worker - routes requests to backend interface Env { BACKEND: Fetcher; // Service Binding to backend Worker } export default { async fetch(request: Request, env: Env): PromiseResponse { if (new URL(request.url).pathname.startsWith(/api/)) { return env.BACKEND.fetch(request); // Forward to backend } return new Response(Frontend content); } };后端 Worker 代码——只做数据库操作// Backend Worker - database operations interface BackendEnv { DATABASE: D1Database; } export default { async fetch(request: Request, env: BackendEnv): PromiseResponse { const data await env.DATABASE.prepare(SELECT * FROM table).all(); return Response.json(data); } };两份 wrangler 配置来自 configuration.md// frontend-worker/wrangler.jsonc —— 不写 placement留在边缘 { name: frontend, main: frontend-worker.ts, services: [ { binding: BACKEND, service: backend-api } ] }// backend-api/wrangler.jsonc —— 开启 Smart Placement { name: backend-api, main: backend-worker.ts, placement: { mode: smart }, d1_databases: [ { binding: DATABASE, database_id: xxx } ] }关于 Service Binding 还有两点值得注意见 bindings 的 patterns.mdService Binding 的 URL 无关紧要——路由靠绑定名binding name而非 hostname/协议所以示例里env.BACKEND.fetch(request)直接转发原始请求即可相比跨区域 HTTP 调用慢、计费、跨区延迟Service Binding 同数据中心直连、零额外 DNS 开销且免费。⚠️ 关键警告只能用 fetch 式 Service Binding不能用 RPC这是本 Skill 反复强调的最高优先级约束Smart Placement 只对基于 fetch 的绑定生效对 RPC 完全不生效。// ❌ RPC - Smart Placement 对后端 RPC 方法无效 export class BackendRPC extends WorkerEntrypoint { async getData() { // 始终运行在边缘Smart Placement 被忽略 return await this.env.DATABASE.prepare(SELECT * FROM table).all(); } } // ✅ Fetch - Smart Placement 生效 export default { async fetch(request: Request, env: Env): PromiseResponse { // 启用 Smart Placement 后运行在 DATABASE 附近 const data await env.DATABASE.prepare(SELECT * FROM table).all(); return Response.json(data); } };原因在于Smart Placement 只能路由fetch请求而 RPC 调用绕过了fetch处理器gotchas.md。受影响的还包括具名入口非 default 导出、队列消费者Queue consumers、定时处理器scheduled handler等其他事件类型。如果后端逻辑已经写成WorkerEntrypoint解决方案是把 RPC 方法改造成 fetch 端点或用带fetch处理器的包装 Worker 中转后者会引入额外延迟非首选。模式三外部 API 集成当 Worker 需要聚合多个第三方 API 的响应时开启 Smart Placement 能让它运行在更靠近这些 API 服务的地理位置配合Promise.all并行请求进一步压降总时长。export default { async fetch(request: Request, env: Env): PromiseResponse { const apiUrl https://api.partner.com; const headers { Authorization: Bearer ${env.API_KEY} }; const [profile, transactions] await Promise.all([ fetch(${apiUrl}/profile, { headers }), fetch(${apiUrl}/transactions, { headers }) ]); return Response.json({ profile: await profile.json(), transactions: await transactions.json() }); } };配套实践参考 bindings/patterns.md密钥通过wrangler secret管理绝不写进配置npx wrangler secret put API_KEY可用cat api-key.txt | npx wrangler secret put API_KEY从文件注入或加--env staging区分环境然后代码里按请求访问env.API_KEY严禁把sk_live_abc123这类值硬编码或塞进vars。并行化独立请求多个互不依赖的后端调用用Promise.all合并这与 Smart Placement 的收益叠加——聚合点离 API 越近每路并行请求的网络开销越小。文档 api.md 指出对于“多次后端 API 调用”的 WorkerSmart Placement 的典型改善幅度为请求时长降低 30–60%若后端在地理上高度集中收益还会更大。模式四SSR / API 网关模式服务端渲染或 API 网关场景同样遵循“边缘做轻活、后端做重活”的拆分原则鉴权与路由贴近用户边缘数据库操作贴近数据Smart Placement。// Frontend (edge) - auth/routing close to user export default { async fetch(request: Request, env: Env) { if (!request.headers.get(Authorization)) { return new Response(Unauthorized, { status: 401 }); } const data await env.BACKEND.fetch(request); return new Response(renderPage(await data.json()), { headers: { Content-Type: text/html } }); } }; // Backend (Smart Placement) - DB operations close to data export default { async fetch(request: Request, env: Env) { const data await env.DATABASE.prepare(SELECT * FROM pages WHERE id ?).bind(pageId).first(); return Response.json(data); } };这一模式把“需要快速响应用户”的逻辑鉴权失败立即 401、HTML 渲染与“需要靠近数据”的逻辑页面内容查询彻底解耦。前端 Worker 留在边缘用户交互保持敏捷后端 Worker 开启 Smart Placement数据库查询的网络往返被压缩。这正是 README.md 推荐的关键架构模式User → Frontend Worker (at edge, close to user) ↓ Service Binding Backend Worker (Smart Placement enabled, close to DB/API) ↓ Database/Backend Service模式五Durable Objects 与 Smart Placement 的配合需要特别澄清一个常见误解patterns.md 明确说明Smart Placement 不控制 Durable Objects 的运行位置。DO 始终运行在其指定区域由 jurisdiction 或智能位置提示决定Smart Placement 真正影响的是协调 Workercoordinator的fetch处理器所在位置——即“谁在调用多个 DO”这个聚合点。因此推荐模式是在聚合多个 DO 数据的协调 Worker 上启用 Smart Placement让它的fetch处理器离 DO 区域更近从而减少多次 DO 调用的网络延迟。// Worker with Smart Placement - aggregates data from multiple DOs export default { async fetch(request: Request, env: Env): PromiseResponse { const userId new URL(request.url).searchParams.get(user); // Get DO stubs const userDO env.USER_DO.get(env.USER_DO.idFromName(userId)); const analyticsID env.ANALYTICS_DO.idFromName(analytics-${userId}); const analyticsDO env.ANALYTICS_DO.get(analyticsID); // Fetch from multiple DOs const [userData, analyticsData] await Promise.all([ userDO.fetch(new Request(https://do/profile)), analyticsDO.fetch(new Request(https://do/stats)) ]); return Response.json({ user: await userData.json(), analytics: await analyticsData.json() }); } };// wrangler.jsonc { placement: { mode: smart }, durable_objects: { bindings: [ { name: USER_DO, class_name: UserDO }, { name: ANALYTICS_DO, class_name: AnalyticsDO } ] } }何时有帮助Worker 的fetch处理器运行在更靠近 DO 区域的位置缩短多次 DO 调用的网络延迟DO 在地理上集中或位于特定司法管辖区jurisdiction时收益最大协调 Worker 需要发起大量串行或并行的 DO 调用时帮助明显。何时没帮助DO 全球分布不存在单一最优 Worker 位置Worker 只调用单个 DODO 调用频率低或已被缓存。补充背景见 durable-objects 的 README.mdDO 通过idFromName()生成确定性 ID、newUniqueId()生成随机 ID分片高吞吐并支持jurisdiction选项满足数据驻留合规如 EU、FedRAMPDO 实例在指定区域内单线程串行处理请求。协调 Worker 的放置优化正是围绕这些 DO 的区域特性展开的。最佳实践清单patterns.md 收尾给出了可直接落地的实践清单拆分全栈应用前端留在边缘后端启用 Smart Placement使用 fetch 式 Service Bindings不要用 RPCRPC 不受 Smart Placement 影响为后端逻辑启用API、数据聚合、数据库操作不要为以下场景启用静态内容、纯边缘逻辑、RPC 方法、以及run_worker_first的 Pages等待 15 分钟以上的分析期并验证placement_status SUCCESS。再叠加两条易踩坑的警示来自 configuration.md 与 gotchas.md① Pages/Assets run_worker_first true是最高频的误配置。Smart Placement 会把包括 HTML/CSS/JS/图片在内的所有请求都路由到远端而静态资源本应永远从离用户最近的边缘分发结果静态资源加载慢 2–5 倍。解决办法按优先级拆分成独立 Worker前端留边缘 后端开 Smart Placement 显式mode: off 设assets.run_worker_first false。// ❌ 错误示范 - 静态资源性能劣化 2-5 倍 { name: pages-app, placement: { mode: smart }, assets: { run_worker_first: true } } // ✅ 正确 - 前端留边缘后端做优化 // frontend-worker/wrangler.jsonc { name: frontend, assets: { run_worker_first: true } // 不写 placement - 运行在边缘 } // backend-worker/wrangler.jsonc { name: backend-api, placement: { mode: smart }, d1_databases: [{ binding: DB, database_id: xxx }] }② 单体全栈 Worker 不要开 Smart Placement。前后端逻辑混在同一个 Worker 里时Smart Placement 会为了后端延迟牺牲用户侧响应时间应拆成两个 Worker前端显式mode: off留在边缘后端mode: smart贴近数据。验证与监控确认优化真的生效启用不等于生效必须通过以下手段验证api.md1. Placement Status APIcurl -X GET https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/workers/services/{WORKER_NAME} \ -H Authorization: Bearer TOKEN \ -H Content-Type: application/json响应中的placement_status字段取值为type PlacementStatus | undefined // 尚未分析 | SUCCESS // 优化成功 | INSUFFICIENT_INVOCATIONS // 流量不足无法决策 | UNSUPPORTED_APPLICATION; // 反而变慢已回退各状态含义undefined字段不存在尚未分析Worker 始终运行在离用户最近的默认边缘位置SUCCESS分析完成Smart Placement 已激活Worker 运行在最优位置可能是边缘也可能是远端INSUFFICIENT_INVOCATIONS请求量不足以做放置决策需要持续的跨区域流量当前仍运行在默认边缘UNSUPPORTED_APPLICATION罕见约 1% 的 WorkerSmart Placement 反而变慢决策已回退始终运行在边缘且在重新部署前不会再次分析。2. cf-placement 响应头BetaSmart Placement 会在响应中附加路由决策头格式为{placement-type}-{IATA-code}// 远端放置Smart Placement 已路由 cf-placement: remote-LHR // 路由到伦敦 // 本地放置默认边缘路由 cf-placement: local-EWR // 留在纽瓦克边缘其中remote-*表示被路由到远端、local-*表示留在默认边缘IATA 代码是离数据中心最近的机场代码。可在代码中读取该头来观测export default { async fetch(request: Request, env: Env): PromiseResponse { const placementHeader request.headers.get(cf-placement); if (placementHeader?.startsWith(remote-)) { const location placementHeader.split(-)[1]; console.log(Smart Placement routed to ${location}); } else if (placementHeader?.startsWith(local-)) { const location placementHeader.split(-)[1]; console.log(Running at edge location ${location}); } return new Response(OK); } } satisfies ExportedHandlerEnv;注意cf-placement是 Beta 功能GA 前可能被移除或调整生产代码不应强依赖它。3. 请求时长指标对比在控制台Workers Pages → [Worker] → Metrics → Request Duration可查看直方图对比两路流量开启 Smart Placement 的 99% 流量vs未优化的 1% 基线流量Smart Placement 会自动把 1% 的请求不做优化地路由出去用于性能对比属预期行为。注意区分两个指标Request duration请求时长是从请求到达至响应送达的总时间含网络延迟Execution duration执行时长是 Worker 代码实际运行时间不含网络等待。衡量 Smart Placement 效果要用请求时长。指标对比含义行动开启 基线Smart Placement 在帮忙保持启用开启 ≈ 基线效果中性可考虑关闭以释放资源开启 基线Smart Placement 在拖后腿用mode: off关闭4. 命令行监控# 部署携带 Smart Placement 配置 wrangler deploy # 查看日志 wrangler tail your-worker-name # 按状态或放置头过滤 wrangler tail your-worker-name --status error wrangler tail your-worker-name --header cf-placement # 通过 API 检查放置状态 curl -H Authorization: Bearer $TOKEN \ https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/workers/services/$WORKER_NAME \ | jq .result.placement_status常见问题的快速排查INSUFFICIENT_INVOCATIONS流量不足。确保 Worker 收到持续的全球流量、等待更长分析时间最长 15 分钟、从多个地理位置发送测试流量并确认 Worker 有fetch事件处理器。UNSUPPORTED_APPLICATION变慢被回退。原因通常是Worker 不做后端调用边缘更快、后端调用已缓存、后端服务全球分布良好、或 Worker 在服务静态资源。对策{ placement: { mode: off } }关闭或改用独立的后端 Worker。没有请求时长指标Smart Placement 未启用、时间不足、流量不足或分析未完成。按“启用 → 等 15 分钟 → 确认placement_status SUCCESS”的链路逐项排查。cf-placement头缺失未启用、Beta 功能被移除、或 Worker 尚未完成分析。延伸阅读Smart Placement 模式参考本文核心文档Smart Placement 总览与决策树Smart Placement 配置详解Smart Placement API 与监控Smart Placement 常见坑D1 数据库参考Service Bindings 模式Durable Objects 参考 与 配置cloudflare-deploy Skill 主文档赞分享【免费下载链接】autoskillsOne command. Your entire AI skill stack. Installed.项目地址https://gitcode.com/gh_mirrors/au/autoskills点击查看免费下载相关推荐autoskills 实战Cloudflare Argo Smart Routing 集成模式全解析autoskills 实战Cloudflare Argo Smart Routing 集成模式全解析 本文基于 autoskills 仓库中 cloudflaautoskills Cloudflare 技能库 Hyperdrive 查询模式解析高并发读、多租户、连接池纪律与 Smart Placement 实战autoskills Cloudflare 技能库 Hyperdrive 查询模式解析高并发读、多租户、连接池纪律与 Smart Placement 实战 在Cloudflare Workers Smart Placement API 实战指南状态查询、cf-placement 头与请求耗时监控Cloudflare Workers Smart Placement API 实战指南状态查询、cf placement 头与请求耗时监控 Smart Pla人工智能AI 技能AI 插件上一篇INAV 飞控板指南FlyingRC F4 Wing MiniFLYINGRCF4WINGMINI目标板特性、规格与限制下一篇如何使用Echo Loop进行科学英语训练8大阶段间隔复习全攻略创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考