从浏览器 IDE 部署到 Vercel 或 Netlify

最明显的情况是机器不方便或禁止安装 CLI。Chromebook、学校机房电脑或受管控的公司桌面可以打开浏览器标签页，却不一定能装 Node.js、Git 和提供商 CLI。浏览器 IDE 已经在编辑环节去掉了这些要求。部署通常是最后一步，会把开发者送回终端；把它留在同一个标签页里，闭环就形成了：编辑、预览、发布都不需要本地工具链。第二种情况是速度。落地页、原型或客户演示可能先需要网址，再需要仓库或 CI 流水线。浏览器面板发布当前快照并告诉你它在哪上线。便利有边界。这是直接上传，不是部署流水线。它不监听分支、不运行测试，也不在环境之间提升构建；那些工作属于提供商的 Git 集成或 CI。浏览器路径服务于第一个网址，而不是整个发布流程。

Deploy 对话框是覆盖在两个提供商 API 之上的轻量控制层。点击 Deploy now 时，GB Coder 生成与 Download ZIP 相同的文件包。这个细节很重要：不存在另一条可能漏掉样式表或忘记外部库的打包路径。普通项目会变成 index.html、style.css、script.js 和 README。React 或 Vue 项目会变成 Vite 结构的文件树，包含 index.html、package.json、vite.config.js、.gitignore、README 以及 src/ 下的源码。对话框的包摘要会在任何内容离开标签页之前显示准确的文件数和未压缩大小。Vercel 在其部署端点以行内 JSON 接收文件。Netlify 以原始请求体接收 ZIP。Vercel 会构建或提供项目；Netlify 会把上传的文件作为手动部署发布。中间没有 LadeStack 服务器，你的机器上也不会运行 CLI。浏览器是客户端，提供商是主机，令牌是唯一凭证。一键描述的是界面，不是工作量：打包、上传、远程处理和 TLS 仍然按顺序发生。

文件包不同，是因为两类项目需要不同处理。普通 HTML/CSS/JavaScript 项目没有 package.json。Vercel 被指示不使用框架，并把文件作为静态站点提供。Netlify 会按原样发布 ZIP，这对静态文件同样适用。没有东西需要安装或编译，所以首次部署通常很快。React 或 Vue 项目包含生成的 package.json、Vite 配置和源码。在 Vercel 上，提供商会识别 Vite、安装依赖、运行生产构建并发布输出。这是真实的云端构建，不是浏览器里的模拟，所以可能需要一分钟以上。Vercel 使用的也是 package.json 中记录的版本，而不是编辑器里碰巧加载的版本。Netlify 的手动 ZIP 部署不会运行构建命令，因此同一个 Vite 源码树会按上传原样发布，而不会被编译。在 Netlify 上使用 React 或 Vue 时，请使用提供商的 Git 集成；Netlify 的一键路径只发布静态输出。外部库和注入设置已经反映在文件包中。如果 Vercel 构建依赖私有包、原生二进制或构建镜像无法访问的服务，即使本地预览正常，构建也会失败。日志会告诉你属于哪种情况。

两个提供商都使用个人访问令牌认证。这不是提供商密码，也不是 GB Coder 账户。对话框会链接到所选提供商的令牌页面，并用通俗语言说明权限范围。Vercel 令牌可以向账户或团队能访问的所有项目发布；如果有团队范围的令牌，就用它。Netlify 令牌作用于账户能访问的站点，因此除非有更窄的选项，否则应把它视为账户级。为此用途创建令牌，设置尽可能短的有效期，并在项目不再需要时从提供商处撤销。GB Coder 在启用 Deploy now 前会检查令牌是否存在、文件包是否在本地限制内。令牌默认只保存在标签页内存中。Remember on this device 是可选操作：在安全上下文中，令牌会先用 AES-GCM 封装再写入 localStorage；否则对话框会警告，记住它将以明文存储。权限范围和撤销才是最重要的控制。

打开项目，然后从工具栏选择 Deploy；窄屏上它在溢出菜单里。默认选中 Vercel，Netlify 只差一次点击。项目名称会从当前项目预填。GB Coder 会把它转成小写，把无效字符换成连字符，并显示将要请求的主机名，例如 your-project.vercel.app。粘贴令牌，决定是否记住，然后检查文件包摘要。如果文件数或大小超限，对话框会说明问题并保持按钮不可用。点击 Deploy now。提供商会创建项目或站点，接收文件包并开始处理部署。部署就绪后，成功界面会显示公开网址、文件数量、上传大小、耗时，以及用手机打开页面的二维码。Copy URL 和 Visit site 用于交付，Build logs 打开提供商自己的日志视图。Netlify 站点名是全球唯一的，所以请求的名字可能已被占用。此时提供商会分配另一个名字，GB Coder 报告实际在线的地址，而不是你输入的那个。

进度条会经过打包、上传、构建、安全配置和就绪几个阶段。在 Netlify 上，“构建”标签表示提供商正在处理，并不代表运行构建命令。这是客户端报告，不是提供商的预测。百分比在前两个阶段快速上升，然后在提供商完成远程工作期间停在 100 以下。这是有意为之：远程工作时间无法预测，一个冲到 99% 的进度条只会撒谎。GB Coder 每 1.5 秒轮询提供商，并在状态变化时更新消息。上传请求有两分钟超时。面板在部署轮询三分钟后停止等待，并指向仪表板，因为即使浏览器不再盯着，部署也可能完成。取消、关闭对话框或按 Escape 会中断进行中的请求和轮询循环。如果提供商已经接受部署，部署可能在它那边继续；不要把取消当成回滚，先去仪表板确认。部署失败时，提供商的日志才是权威来源。

Deploy again 会回到表单，不会立刻重发上一个文件包。这很有用，因为项目可能已经改变、名称需要调整，或者令牌过期了。随后 Vercel 和 Netlify 会沿不同路径抵达同一地址。Vercel 针对命名项目创建部署，并以生产为目标。用相同项目名重复部署会更新该项目，而且生产别名优先于部署专属网址，所以你分享的地址通常保持稳定。Netlify 需要站点 ID 才能更新现有站点，而不是新建一个。GB Coder 会把该 ID 以清理后的站点名为键存进 localStorage。如果你清除了浏览器存储、换了浏览器、改了名字或在 Netlify 删除了站点，下一次部署就找不到旧站点，只能新建。因此重命名 Netlify 项目可能会把旧站点留在账户里。两家提供商都在仪表板中保留部署历史、自定义域名、访问控制和回滚；GB Coder 面板只暴露上传和公开网址。这里的每次部署都是生产部署，没有分支预览或环境选择器。

请求离开标签页前会执行两个限制：900 个文件和 64 MB 未压缩内容。它们低于提供商自身的上限，以免巨大上传在浏览器会话中途失败。媒体较多的站点应把大图和视频放在 CDN 或 Git 里，而不是项目文件包中。错误按原因区分。401 表示令牌被拒绝；403 通常表示缺少账户或团队权限；413 或 429 表示负载过大或提供商限流；422 表示项目被判为无效；5xx 通常是临时问题。在 Vercel 上，框架构建失败不一样：上传成功了，构建失败了，所以应该读日志，而不是粘贴新令牌。Vercel 构建如果需要环境变量，是另一道边界。部署对话框没有环境变量编辑器。请在 Vercel 的项目设置中配置值，然后再次部署；首次构建可能在项目创建之前就失败。Netlify 的手动 ZIP 路径没有构建步骤，因此这不适用。三分钟轮询上限不是部署失败，只是等待失败。

部署路径是直接的：浏览器用你的令牌调用 api.vercel.com 或 api.netlify.com。没有代理保存凭证，使用这个面板也不需要 LadeStack 账户。令牌默认仅限会话，只有在安全来源中选择记住时才用 AES-GCM 封装。这能防止令牌在浏览器配置文件备份或支持包中以可读形式出现，但不能防止标签页打开期间同源运行的恶意代码。使用可用的最窄令牌，设置过期时间，并在工作完成后从提供商处撤销。所有权跟随令牌：项目或站点创建在拥有它的提供商账户中，受该提供商条款、配额、日志和计费约束。GB Coder 仍然本地优先，但部署是把项目显式导出给提供商。提供商接收站点的源码，结果默认是公开 HTTPS 网址；密码保护、SSO 和自定义域名属于提供商功能。如果浏览器配置文件是项目唯一存放处，请保留 ZIP 或 GitHub 副本。

当任务是把小站点快速上线时，用这条路径：落地页、作品集、课堂演示、供客户评审的原型或静态文档页。项目已经在 GB Coder 里，而替代方案是导出 ZIP、打开终端、在别人的机器上配置 CLI 时，它也很合适。它不适合单体仓库、带数据库的服务端渲染应用、需要私有仓库凭证的构建、通过分支预览和审批发布的团队，或超出上传限制的资源。那些属于提供商的 Git 集成、CI 流水线或桌面环境。两种方式可以共存：在浏览器里起草和迭代，当项目值得保留历史时把源码推送到 GitHub，让 CI 发布生产构建。实用流程很短：在手机宽度检查预览，查看文件包摘要，部署，在第二台设备上打开公开网址，保存构建日志。想尝试的话，打开 /app/projects 的项目仪表板，创建或打开项目，然后选择 Deploy。设置参考在文档中。