简体中文
EnglishSurge 能和哪些构建工具或工作流配合使用?
更新时间
Surge 可以配合 Grunt、Gulp、npm run 脚本、Git Hooks，以及 Jekyll 和各类静态站点生成器使用。它的定位是“增强你已经在用的工具”，而不是替换它们：你继续用原有构建流程生成静态文件，再把产物交给 Surge 发布。判断是否适合自己，关键看两点：你的项目最终能否输出纯静态文件，以及你希望部署发生在构建流程的哪一步。
支持的构建工具与接入方式
| 工具/工作流 | 接入方式 | 适合的场景 |
|---|---|---|
| Grunt | 安装 grunt-surge 插件，之后使用 grunt deploy |
已有 Grunt 构建链，想把部署做成一个 task |
| Gulp | 将 surge 作为 devDependency 安装，在 Gulpfile 中使用 | 已有 Gulp 流程，部署作为其中一个步骤 |
| npm run 脚本 | 安装 Surge CLI，在 package.json 的 scripts 中调用 | 不想引入额外插件，用最少的依赖完成部署 |
| Git Hooks | 在推送时触发部署 | 希望每次 push 到 GitHub 就自动上线，且不想手动切换分支 |
| Jekyll | 本地编译后发布到 Surge | 用 Jekyll 生成站点，想避开分支管理和插件限制 |
| 静态站点生成器 | 通过 Surge CLI 部署生成结果 | 手写 HTML/CSS/JS，或使用高度定制的生成器 |
| Node.js | 把 Surge 构建进自己的工具 | 需要把部署能力封装进自研脚本或平台 |
为什么这些工具都能接进来
Surge 的核心入口是 CLI：在项目目录里输入 surge 并回车，它会要求你确认项目路径和域名，然后上传并返回发布地址。例如：
$ surge
project: path/to/my-project
domain: my-project.surge.sh
upload: [ ============ ]
Success! Published and running at my-project.surge.sh
因为部署动作被压缩成一条命令，任何能执行命令的构建工具都可以把它串进自己的流程里。Grunt 用插件封装，Gulp 和 npm scripts 直接调用，Git Hooks 则在推送事件上触发同一条命令。
部署后默认带哪些能力
每个 Surge 项目都包含这些特性，接入构建工具后同样生效：
- 免费的自定义域名支持
- surge.sh 子域名的免费 SSL
- 单页应用（SPA）的 pushState 支持
- 自定义 404.html 页面
- 通过 CLI 的无障碍部署
- 跨域资源共享（CORS）支持
这些能力对前端项目比较实用：SPA 路由不会因为刷新而 404，自定义错误页可以直接放在静态目录里。
怎么选：按你现有的流程决定
- 已经在用 Grunt：装 grunt-surge，把部署变成一个 task，改动最小。
- 已经在用 Gulp 或 npm scripts：把 surge 装成 devDependency，在原有脚本里加一步即可，不必额外学插件。
- 希望 push 即上线：用 Git Hooks，省去手动部署和分支切换。
- 用 Jekyll 或静态站点生成器：本地编译出静态文件，再用 CLI 发布，不需要为部署改变生成方式。
- 想把部署嵌进自研工具：Surge 提供 Node.js 层面的集成方式，可以构建进自己的工具链。
如果你的项目无法输出纯静态文件，或者部署必须依赖服务端运行时，Surge 的这套集成方式就不适用。