docs(deploy): 部署停机写实 —— 「秒级重启」实测是 ~16 秒

README 原文「期间 service 秒级重启」会让人以为一两秒,实测三次都在 15.97~16.86s。
force-recreate 不是滚动更新,就是停旧起新,中间必然有真空期。

补三点容易误解的:
  · build 阶段不影响服务(老容器一直跑)→ 部署总耗时长短与停机无关
  · 影响面:API 报错、刷新即恢复;登录态不掉(JWT 在浏览器);无数据风险
  · 要真零停机得网关层蓝绿,不在本脚本范围

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

deploy/README.md

@@ -21,7 +21,16 @@ ssh <server> && cd /opt/pac
 bash deploy/deploy-prod.sh
 ```
 
-`git pull` → build → force-recreate → 验证(镜像 ID 一致 / 迁移无 pending / health 200 / web 200),任一不过即失败。只动代码,**不碰数据**。期间 service 秒级重启。
+`git pull` → build → force-recreate → 验证(镜像 ID 一致 / 迁移无 pending / health 200 / web 200),任一不过即失败。只动代码,**不碰数据**。
+
+⚠️ **期间有约 16 秒停机**(2026-08-04 实测三次:15.97 / 16.86 / ~16s,0.5s 间隔探 `/health`)。
+`force-recreate` **不是**滚动更新 —— 它就是停旧容器、起新容器,中间必然有真空期。
+build 阶段不影响服务(老容器一直跑),停机只发生在重建那一刻,所以**部署总耗时长短与停机无关**。
+
+影响:那 16 秒内 API 报错、工作台加载失败,刷新即恢复;登录态不掉(JWT 在浏览器),无数据风险
+(迁移由 pac-migrate 单独跑完才起 service,写操作要么已完成、要么失败可重试)。建议挑非高峰时段。
+
+要真正零停机得引入网关层蓝绿切换(两套容器 + 上游切换),不在本脚本范围内。
 
 > 改了 `NEXT_PUBLIC_*`(前端 build-time 变量)必须走本脚本重 build;只改后端 `.env` 用 `docker compose -f docker-compose.prod.yml restart pac-service` 即可。