05 — 未来挑战与方向¶
本章从平台演进与架构责任两层面，归纳在 Cloudflare + TypeScript 路线上会持续遇到的挑战，以及官方产品动向中可观察的方向。具体数值仍以 Workers limits 为准。
1. 挑战：在限制内做「正确的拆分」¶
- CPU 与内存上限不会消失，只是随商务与产品上移（例如付费计划可将单次 CPU 上限提高到文档所述范围）。架构师需要持续回答：哪些逻辑留在边缘，哪些必须 Queues / 外部批处理 / 数据库侧完成。
- 并发与共享受限状态：isolate 模型决定了「进程内状态」不可靠；DO、Workflows、D1 等是不同一致性/成本权衡的工具，选型复杂度上升。
2. 挑战：Node 兼容的期望管理¶
- 生态上大量 npm 包默认 Node；
nodejs_compat与兼容日期能覆盖常见场景，但不是 100% Node。团队需要建立「依赖评审」习惯，避免在边缘引入不可移植库。
参考：Node.js compatibility — Workers runtime
3. 挑战：可观测性与故障归因¶
- 边缘运行使「本地复现」更难；需要熟练使用 Workers Logs、Trace、CPU profiling、Logpush 等（官方在 Error 1102 排错路径中有列举）。
- 多服务 RPC（Service Bindings）链路下，跨 Worker 的延迟与错误传播需要统一 request id 与结构化日志约定。
4. 挑战：安全、合规与数据驻留¶
- 边缘全球分布是优势，也可能是数据合规讨论焦点（何类 PII 可过 Worker、日志落哪里、密钥如何轮转）。
- 供应链安全（npm、第三方 Wasm）在沙箱内依然要审计：isolate 防的是租户间隔离，不替代代码安全审查。
5. 发展方向（基于公开文档与 changelog 的归纳）¶
下列为观察性归纳，非承诺：
-
Workers 与 Pages 能力收敛到「带静态资源的 Workers」
迁移文档与全栈路由文档强化了这一叙事：统一功能面与可观测性。 -
更长的 CPU 时限与更清晰的计费护栏
Changelog 与 limits 文档反映平台在接纳更重边缘工作负载的同时，用limits、套餐维度控制账单风险。 -
类型与多环境人机工程
wrangler types覆盖多 environment、RPC 类型生成，降低 TS 项目在平台上的「配置—代码」漂移。 -
平台 API 与 SDK 成熟
Beta REST API + TypeScript SDK 暗示：企业内「基础设施即代码」与「应用发版」分离会更常见。 -
AI 相关运行时能力
Workers AI、Vectorize、AI Gateway、AI Search 等与数据面绑定加深了架构选择，详见 06 — 数据层、AI、向量与 RAG；配额与计费需单独跟踪 Workers AI limits 等页面。
6. 对本专题读者的行动清单¶
- 每季度复核 limits / pricing / compatibility_date。
- 新建项目默认开启
wrangler types与 CI 中的类型检查。 - 为 Worker 建立 SLO：P95 CPU、错误率、子请求数；接近阈值即触发架构复盘。
- 对「可能要迁出边缘」的逻辑提前抽象接口，降低锁定风险。