解读

面试官想知道你是否能把 Grunt 的构建产物 高效、安全地同步到远端服务器，同时只传输“真正变化”的内容，而不是整包覆盖。国内常见场景是：

1. 前端 CI 产出 dist 目录后，需把静态资源推到 阿里云 ECS、腾讯云 CVM、华为云 OBS、七牛 CDN 或自建 Nginx；
2. 带宽计费、上传时长、回源失败率都是 KPI；
3. 必须兼容 Windows 开发机 + Linux 生产机 的跨平台路径差异；
4. 回滚策略要求保留 最近 3 个历史版本 的硬链或软链。
   因此，回答要围绕“Grunt 如何驱动 rsync 做增量”展开，而不是单纯背 rsync 参数。

知识点

1. Grunt 任务生命周期：init → registerTask → run；
2. grunt-contrib-rsync 插件的底层：spawn 子进程调用系统 rsync，支持 --dry-run、--checksum、--inplace、--link-dest；
3. rsync 增量算法：
   a. 分块校验（rolling checksum + 128-bit MD4）找出差异块；
   b. 服务端按块重组，避免全文件传输；
   c. 配合 --compress-level=9 在公网节省 30~60% 流量；
4. 国内加速技巧：
   • 走 内网 DNS 解析（如 ecs.inner-local）避开公网；
   • 对海量小文件启用 --whole-file --inplace，减少 CPU 消耗；
   • 大文件（>100 MB）用 --bwlimit=8000 防止占满共享带宽；
5. 版本回滚：利用 --link-dest=../last 在远端生成硬链快照，回滚只需改 symlink；
6. 安全：通过 --rsh='ssh -p 922 -i ~/.ssh/id_rsa_aliyun' 指定密钥，避免密码；
7. Gruntfile 中动态读取 process.env.RSYNC_TARGET 实现“一套脚本，多环境”。

答案

我采用 grunt-contrib-rsync 插件，把增量上传拆成三步：

1. 前置校验：在 Gruntfile 里先用 grunt.file.readJSON('.checksum.json') 加载上一次成功上传的校验和，若文件无变化直接跳过任务，节省 CI 时间；
2. 差异计算：配置项里打开 options: { args: ['--checksum', '--archive', '--compress'] }，rsync 会基于 rolling checksum 把本地 dist 目录与远端 /data/www/project 做块级对比，只传输变化的块；
3. 原子发布：上传完成后，在远端执行 --rsync-path='sudo rsync && ln -sfn /data/www/releases/$(date +%s) /data/www/current'，实现 0 downtime 切换。
   整个流程在 GitLab CI 中跑，平均把 1.2 GB 的 dist 目录压缩到 180 MB 增量包，上传时长从 3 分钟降到 18 秒，公网流量费用降低 72%。

拓展思考

1. 如果远端是 对象存储（OSS、COS、OBS） 而非 SSH，可改用 grunt-ali-oss 或 grunt-tencent-cos，利用它们自带的 multipart 分片上传 + ETag 校验 实现“类 rsync”增量；
2. 对 微前端 场景，各子应用独立构建，可在 Gruntfile 里用 grunt.event.on('rsync.done', subApp => {}) 触发 CDN 预热 API，避免首次 404；
3. 当项目达到 10 万级文件 时，rsync 的 file-list 阶段会成为瓶颈，可先把 dist 打成 tar.zst 流，配合 rsync --whole-file --inplace 一次性推送，再在远端解压，兼顾增量与耗时；
4. 安全合规要求 “先审计再上传”，可在 Grunt 任务链中插入 grunt-eslint 与 grunt-sonarqube，只有质量门禁通过才触发 rsync，实现 “构建-质检-增量上传” 一体化。