Windsurf Cascade App Deploys 应用部署教程
想用 Cascade 把网页项目部署上线？说实话，真正容易卡壳的往往不是敲“部署”俩字，而是搞不清项目能不能正常构建、看不懂部署状态，还有公开页面打不开的时候找不到对的排查路子。跟着步骤走完，你不仅能拿到一个可分享的公开站点，还能搞懂怎么认领项目、查构建记录、恢复部署配置。
先提个醒：App Deploys 现在还是测试功能，主要用来预览和分享项目，别直接拿来跑带敏感数据的生产业务哈。目前它用的部署服务商是 Netlify，支持 Next.js、React、Vue、Svelte 以及静态 HTML、CSS、Ja vaScript 项目。部署的时候，项目代码会先传到 Windsurf 的服务器，再通过其服务商账户完成构建和发布。
先带你认一下 App Deploys 浮层：火箭图标对应部署功能，右侧的
Deploy
View history
部署前先把三个条件查清
项目得能在自己电脑上正常构建。
npm run build。成功标志很简单：命令正常跑完，并且生成了构建产物。要是这一步就报错，先自己把依赖、脚本或框架配置的问题修好——远端部署可不会帮你跳过本地构建的毛病。
代码得适合公开预览。
账户额度得够用。
从 Cascade 发起第一次部署
第一步：让 Cascade 识别项目并生成配置
入口位置：
主要动作：
成功标志：
netlify.toml。失败处理：
package.json、构建脚本和框架目录齐不齐全。
你看这张画面里，右侧先出现“Deployment config analyzed”，下面才进到创建配置文件的状态。看到这两个节点，就说明 Cascade 已经从普通对话切换到实际部署流程了。
第二步：确认文件上传和构建已经排队
入口位置：
主要动作：
成功标志：
失败处理：
netlify.toml。
这张图右上角的上传计数已经走完了，紧接着就显示构建排队；正文区域同时给出了框架、子域名和上传结果。到这一步才算“部署请求已交给服务商”，可不等于页面已经构建成功哈。
第三步：打开公开页面检查真实结果
入口位置：
主要动作：
成功标志：
失败处理：
这里的部署结果已经在 Windsurf Preview 中打开了。判断成没成功的时候，至少要检查首屏内容、一次按钮或输入操作，还有一个非首页路径；光弹出个浏览器窗口可证明不了应用功能正常。
公开后别漏掉认领和配置文件
部署完成后会同时提供公开地址和认领入口。重要项目最好尽快认领到自己的 Netlify 账户里，这样才能直接查看服务商构建日志、管理站点设置并长期保留项目。未认领部署可能过段时间就被删除，别把未认领地址当成稳定的长期发布地址用。
项目根目录里的 windsurf_deployment.yaml 存着项目 ID、框架这些再次部署需要的信息。后续更新的时候，还是在原项目里让 Cascade 更新部署就行；成功标志是新构建沿用原站点，而不是又创建一个不相干的项目。要是它误把子域名当成项目 ID，你就明确要求它读取配置文件里的 project_id。
页面打不开时按可见信号排查
出现 Site not found
入口位置：
主要动作：
成功标志：
失败处理：
这类页面是明确的失败信号，别当成是域名还没生效就一个劲刷新。官方排查方向首先指向构建失败和部署记录。
构建失败但没有明确代码提示
入口位置：
主要动作：
成功标志：
失败处理：
netlify.toml、环境变量和发布目录。框架代码本身的错误得在本地修复，App Deploys 不负责替代框架调试。
部署配置丢失或项目 ID 无法识别
入口位置：
主要动作：
Download config file
成功标志：
失败处理：
菜单里的 Download config file 就是恢复入口。它旁边还有删除操作，排查的时候可别误点删除，不然本来能恢复的历史记录就被清掉了。
完成检查
- 本地构建命令正常结束，依赖和发布目录都没报错。
- 项目里没有密钥、内部地址或不该公开的数据。
- Cascade 显示配置分析完成、文件上传完成和构建已排队。
- 公开页面能打开，首屏、交互和非首页路径都检查过了。
windsurf_deployment.yaml保存在项目根目录，后续更新能沿用原项目。- 重要部署已经认领；出现失败时能从部署历史找到构建日志或下载配置。
