rsync是最小可行发布的最稳起点，只传差异、支持排除与原子替换；需用--archive--compress--delete及--exclude过滤敏感文件，--dry-run预检，路径结尾/影响同步内容或目录本身。

用 rsync 做最小可行发布，别碰 FTP 或手动 scp

直接覆盖线上文件风险高，rsync 是 Linux 自动化部署最稳的起点。它只传差异、支持排除、能原子替换，比写一堆 scp + ssh 命令靠谱得多。

常见错误是漏加 --delete 导致旧文件残留，或没用 --exclude 踩进 .git / node_modules 上传陷阱。

• 必须加 --archive --compress --delete：保留权限+压缩传输+清理目标冗余文件
• 敏感文件用 --exclude='.env' --exclude='config/local.php' 显式过滤
• 上线前先试运行加 --dry-run，看清楚哪些文件真会被删/改
• 路径结尾加不加 / 影响极大：src/ 同步内容，src 同步目录本身

用 ssh 免密 + authorized_keys 限制命令，别存密码脚本

自动化部署本质是远程执行，但硬编码密码或用 expect 模拟交互等于埋雷。SSH 密钥 + command= 限定是最小权限解法。

典型翻车点：私钥权限设成 644 被 SSH 拒绝；或者没在 authorized_keys 里锁死命令，导致密钥泄露后整台服务器裸奔。

• 服务端 ~/.ssh/authorized_keys 每行开头加 command="/path/to/deploy.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding
• 客户端私钥必须 chmod 600，公钥上传后检查服务端 sshd_config 是否允许 ForceCommand
• 部署脚本里别写 cd /var/www && git pull 这类操作——git 在远程执行需提前配置 core.sshCommand 避免密钥代理失效

systemd 管理部署后服务重启，别用 kill -9 或裸 bash 循环

发布完代码只是半程，服务进程怎么平滑拉起才是关键。用 systemd 不仅能定义启动依赖、资源限制，还能让 journalctl -u myapp 直接查部署后的日志。

容易被忽略的是 Type=notify 和 Restart=on-failure 的组合——应用自己发 sd_notify 信号才算真正就绪，否则 systemd 可能误判进程已启动。

• 服务文件里写 ExecStart=/usr/bin/npm start 前，确认 WorkingDirectory 指向最新发布的目录（比如 /var/www/myapp/current）
• 用 ln -sfn /var/www/myapp/releases/20240512 /var/www/myapp/current 做软链切换，再 systemctl reload myapp
• 避免在 deploy.sh 里写 kill $(cat pidfile) ——systemd 会接管 PID，手动杀可能触发重复启动

用 git archive 替代 git clone，跳过 .git 和历史开销

线上机器不需要 Git 历史，git clone 拉整个仓库既慢又占空间，还可能因分支状态混乱导致部署错版本。直接导出干净快照更可控。

坑在于没指定 --format=tar 或忘记 --prefix，结果 tar 包解压后文件散在根目录，覆盖出问题。

• 本地打包：git archive --format=tar --prefix=myapp/ HEAD | gzip > deploy.tar.gz
• 远程解压：ssh user@prod "mkdir -p /tmp/deploy && tar -xzf - -C /tmp/deploy"
• 配合 rsync 用 --delete-after：先同步新文件，再删旧文件，减少服务中断窗口

真正难的不是脚本写多长，而是每次发布前确认三件事：软链指向对不对、systemd unit 文件里 WorkingDirectory 没写死旧路径、rsync 排除列表有没有漏掉新加入的调试文件。