代码环境
- 仓库：https://github.com/springvortex/spring-cloud-alibaba.git
- 分支：
release/v1.0.0- JDK：
21- Spring Boot：
4.1.1
部署脚本如果只负责“把文件传上去并启动”，很容易掩盖一个危险场景：服务器缺少外置 application.yaml，服务带着镜像内置配置启动，看起来成功了，实际连的是错误环境。
这次脚本只上传模板：
& scp "deploy\config\$module\application.yaml.template" `
"$($Remote):$AppDir/config/$module/application.yaml.template"
然后逐个检查远程运行配置是否存在：
foreach ($module in $modules) {
& ssh $Remote "test -f '$AppDir/config/$module/application.yaml'" *> $null
if ($LASTEXITCODE -ne 0) {
$missingRuntimeConfigs += $module
}
}
如果用户带上了 -Start，脚本不会“顺手”替服务器生成配置，而是直接取消启动：
if ($Start -and $missingRuntimeConfigs.Count -gt 0) {
Write-Host "以下服务缺少运行配置：$($missingRuntimeConfigs -join ', ')"
throw "远程运行配置未生成，已取消启动。"
}
这不方便，但是正确。运行配置可能被运维在服务器上改过，部署脚本无法判断模板里的地址、账号和密文是否适合当前环境。自动覆盖会丢配置，自动放任启动会错环境，两者都比“停下来让人处理”更危险。
.env 也保持同样边界：脚本会传输 .env.example，但不会创建或修改远程 .env。自定义镜像 tag 时只输出提醒：
if ($Tag -ne "1.0.0") {
Write-Host "提醒：当前构建 tag 是 $Tag，请确保远程 .env 中 APP_TAG=$Tag。"
}
经验总结
自动化不等于替人做所有决定。传输产物可以自动，环境配置和密钥要留在部署机；启动前做存在性校验，缺失就停，是部署脚本该有的刹车。
评论
评论由 GitHub Discussions 承载，需要 GitHub 账号登录。