Windsurf Cascade App Deploys 应用部署教程

想用 Cascade 把网页项目部署上线？说实话，真正容易卡壳的往往不是敲“部署”俩字，而是搞不清项目能不能正常构建、看不懂部署状态，还有公开页面打不开的时候找不到对的排查路子。跟着步骤走完，你不仅能拿到一个可分享的公开站点，还能搞懂怎么认领项目、查构建记录、恢复部署配置。

先提个醒：App Deploys 现在还是测试功能，主要用来预览和分享项目，别直接拿来跑带敏感数据的生产业务哈。目前它用的部署服务商是 Netlify，支持 Next.js、React、Vue、Svelte 以及静态 HTML、CSS、Ja vaScript 项目。部署的时候，项目代码会先传到 Windsurf 的服务器，再通过其服务商账户完成构建和发布。

先带你认一下 App Deploys 浮层：火箭图标对应部署功能，右侧的

用来发起部署， 是打开历史记录的入口。标题旁的 BETA 标记也说明这个入口仍处于测试阶段。

部署前先把三个条件查清

进到项目根目录，先跑项目原本的构建命令；常见 Ja vaScript 项目可以试 npm run build。成功标志很简单：命令正常跑完，并且生成了构建产物。要是这一步就报错，先自己把依赖、脚本或框架配置的问题修好——远端部署可不会帮你跳过本地构建的毛病。

App Deploys 会上传项目文件，还会生成公开访问入口。提交前一定要检查一遍环境变量、测试密钥、内部地址和个人数据，确认仓库里没有不该往外放的内容。要是项目必须依赖私有网络、付费资源或服务端机密，还是先换用受控的正式部署方案。

免费方案每天可部署 1 次，同时保留 1 个未认领站点；Pro 方案每天可部署 10 次，同时保留 5 个未认领站点。团队版和企业版要连接团队的 Netlify 账户时，入口由团队管理员开启。看不到团队部署选项，先找管理员检查 Team Settings，别一个劲反复发起部署。

从 Cascade 发起第一次部署

第一步：让 Cascade 识别项目并生成配置

在 Windsurf 桌面端打开目标项目，进到 Cascade 对话区。输入“将这个项目部署到 Netlify”这类明确指令就行，就让 Cascade 先处理当前项目。界面出现部署配置已分析的状态，并开始创建 netlify.toml。要是 Cascade 没识别出框架，先检查当前工作区打开的是不是真的项目根目录，还有 package.json、构建脚本和框架目录齐不齐全。

你看这张画面里，右侧先出现“Deployment config analyzed”，下面才进到创建配置文件的状态。看到这两个节点，就说明 Cascade 已经从普通对话切换到实际部署流程了。

第二步：确认文件上传和构建已经排队

还是在同一条 Cascade 部署对话里看状态卡片就行。等着项目文件上传完成，上传过程中别关工作区，也别重复发起部署。状态卡片显示文件已全部上传、应用构建已排上队，并在回复里给出公开站点地址。要是上传数量卡着不动，先检查网络和单个文件大小；要是构建没进队列，就回到上一条配置状态，核对构建命令、发布目录和 netlify.toml。

这张图右上角的上传计数已经走完了，紧接着就显示构建排队；正文区域同时给出了框架、子域名和上传结果。到这一步才算“部署请求已交给服务商”，可不等于页面已经构建成功哈。

第三步：打开公开页面检查真实结果

在 Cascade 部署结果里找公开站点地址，或者从 App Deploys 的历史记录进到对应项目也行。打开页面之后一定要实际操作两下，别光看地址生成了就完事。页面能正常载入，样式、脚本和路由都和本地预览一致。要是页面空白、资源缺失或者刷新子路由后报错，就回到构建日志检查发布目录、静态资源路径和路由重写配置。

这里的部署结果已经在 Windsurf Preview 中打开了。判断成没成功的时候，至少要检查首屏内容、一次按钮或输入操作，还有一个非首页路径；光弹出个浏览器窗口可证明不了应用功能正常。

公开后别漏掉认领和配置文件

部署完成后会同时提供公开地址和认领入口。重要项目最好尽快认领到自己的 Netlify 账户里，这样才能直接查看服务商构建日志、管理站点设置并长期保留项目。未认领部署可能过段时间就被删除，别把未认领地址当成稳定的长期发布地址用。

项目根目录里的 windsurf_deployment.yaml 存着项目 ID、框架这些再次部署需要的信息。后续更新的时候，还是在原项目里让 Cascade 更新部署就行；成功标志是新构建沿用原站点，而不是又创建一个不相干的项目。要是它误把子域名当成项目 ID，你就明确要求它读取配置文件里的 project_id。

页面打不开时按可见信号排查

出现 Site not found

打开刚生成的公开页面就行。先确认错误画面是不是明确写着 Site not found。修复之后同一个页面能显示应用内容。先从部署历史认领站点，再查看构建日志；把实际日志交给 Cascade 分析，比只说“打不开”更容易定位构建命令、依赖或发布目录的问题。

这类页面是明确的失败信号，别当成是域名还没生效就一个劲刷新。官方排查方向首先指向构建失败和部署记录。

构建失败但没有明确代码提示

回到 Cascade 的构建状态页面，或者去已认领站点的服务商日志里找。得找到第一条真正导致退出的错误，别只看最后一行的失败摘要。本地构建和远端构建用相同命令后都能通过。依次检查本地构建、框架推荐目录、netlify.toml、环境变量和发布目录。框架代码本身的错误得在本地修复，App Deploys 不负责替代框架调试。

部署配置丢失或项目 ID 无法识别

打开 App Deploys 的部署历史，在对应项目右侧展开更多菜单。选择 ，把下载到的配置文件放回当前项目根目录就行。配置文件里能找到和历史项目对应的项目 ID，Cascade 再次部署时能识别原项目。要是历史记录里也找不到项目，先确认站点是否已经认领、是不是登录了同一账户，再决定要不要创建新部署；别凭空填写项目 ID。

菜单里的 Download config file 就是恢复入口。它旁边还有删除操作，排查的时候可别误点删除，不然本来能恢复的历史记录就被清掉了。

完成检查

• 本地构建命令正常结束，依赖和发布目录都没报错。
• 项目里没有密钥、内部地址或不该公开的数据。
• Cascade 显示配置分析完成、文件上传完成和构建已排队。
• 公开页面能打开，首屏、交互和非首页路径都检查过了。
• windsurf_deployment.yaml 保存在项目根目录，后续更新能沿用原项目。
• 重要部署已经认领；出现失败时能从部署历史找到构建日志或下载配置。