ESA Pages 体验之旅

这个系列起于一个很小的需求：把 Nuxt 写的搜索页放到公网。页面可以静态部署，但调用上游需要保护 API Key，收藏需要持久化，邮箱验证码又需要共享状态和邮件服务。我希望这些能力尽量留在阿里云上，同时少维护一台长期运行的服务器，于是开始尝试 ESA Pages。

Pages 能把静态页面和函数放在同一个部署项目中，浏览器通过同源 /api/* 调用后端。这个结构适合起步，但接入 Node SDK 后，问题逐渐出现在构建、模块加载和平台配额上。本地 Node 能执行的代码，不一定能直接交给边缘运行时。

九篇文章按选型、交付、存储、排障和运行管理的顺序展开，沿用同一个项目的输入、产物与实测记录。读者可以顺序了解部署过程，也可以按遇到的具体问题查阅。

九篇文章

篇目	讨论的问题
1．为什么选择 ESA Pages	从项目需求解释选型，再区分站点套餐、Pages 项目、函数路由与域名证书。免费版能覆盖什么、哪些费用另算，都需要按资源层次判断。
2．部署静态页面和 API	Nuxt 静态产物和函数入口怎样分别交付，为什么有了 npm 依赖仍需要构建，以及 ncc、esbuild、资源搬运和独立目录验收各自负责什么。
3．ESA CLI 的构建配置	检查 CLI 的 browser 解析、Node 模块外置名单和二次打包，再解释 ESM 中保留 require 的原因，以及应用自行构建、CLI 跳过打包的边界。
4．小项目的存储选型	比较 ESA KV、TableStore 和不同形态的 Supabase。除了存储账单，还要核对访问方式、原子操作、地域与适配工作量。
5．修复 TableStore SDK 的变量声明错误	从严格模式下的报错追到发布包，核对 npm 与 GitHub 代码差异，用可追踪补丁修复，并说明上游更新后怎样验证和移除补丁。
6．检查 ESA 的运行环境	解释本地执行器与真实节点的差异，追踪兼容层为什么访问 navigator、Deno 等对象，并用探针确认具体 API，而不是只判断宿主名称。
7．适配 Node.js 依赖	当目标平台缺少依赖需要的能力时，比较原生模块、兼容实现和传输适配；模块能加载之后，还要继续检查真实数据的编解码与业务行为。
8．四次 fetch 限制下的接口设计	用邮箱认证比较框架、HTTP 数据接口与完整认证服务的请求数，再讨论批读、条件消费、部分写入恢复，以及旧账号、会话和收藏的兼容。
9．缓存、防刷与日志	说明 Cache API 的复用条件、缓存键与权限边界，记录 WAF 配置的实际结果，并整理日志、告警、灰度、回滚与数据恢复还需要补齐的机制。

从哪里开始读

准备评估 ESA Pages，可以先读第 1、2 篇，确认产品范围和交付方式，再根据数据需求阅读第 4 篇。这样能在接入 SDK 之前，先判断平台与项目是否合适。

已经遇到构建或启动错误，可以先对照第 3 篇检查产物，再读第 6、7 篇核对宿主能力。构建成功、模块加载成功和业务执行成功是三项不同的结果；缺少变量声明这一类 SDK 自身问题则在第 5 篇单独排查。

需要增加登录、写入多条数据或调用多个外部服务时，第 8 篇提供了完整流程的计数与恢复案例。第 9 篇继续讨论应用上线后的费用控制和故障定位。

怎样看待实验结论

系列主要依据 2026 年 10 月的项目实现、官方资料和隔离实验。具体篇章保留工具版本、原始数据、配套源码与验证范围；选型和修复结论应结合这些条件阅读。

本机 HTTP 协议替身、真实云存储、ESA 调试入口和正式站点分别提供不同证据。例如调试入口曾成功执行超过文档预算的请求，但项目仍按公开的四次预算设计；原生模块适配的隔离实验，也不等于生产构建已经切换。

把应用放上 Pages，需要同时确认交付物、宿主能力和外部服务的访问约束。保留具体输入、最终产物和真实执行结果，才能在平台或依赖升级后重新验证，而不是继续依赖一次「本地能跑」。