现象里有两类错误，先把它们分开，不然调参数会互相打架：dial tcp ...: connect: connection refused：TCP 三次握手就被拒了，说明请求被发到了一个已经不监听的地址，进程根本没参与。transport is closing：连接已经建立，是拆连接时被对端关掉的。前者是「端点摘除和连接复用对不上」，后者是「已建立的连接被终止」。这两件事要用不同手段治。关于 GOAWAY：nginx 不会主动给 gRPC 客户端发 HTTP/2 GOAWAY 来做排空。上游关连接时它只是把这条上游连接作废，正在这条连接上的流会直接失败。所以「让 nginx 优雅排空」这条路本身不成立，能做的只有两件事：让新请求别再进旧 Pod，让旧连接自己走完。为什么 15 秒 preStop 不够：Pod 变成 Terminating 之后，endpoints 摘除广播和 preStop 是并行发生的。摘除要经过 endpoints/EndpointSlice 更新、每个节点 kube-proxy 改规则、ingress-nginx 监听变更后重生成 upstream，这一圈走完旧 IP 才不再被新连接选中。15 秒经常刚好卡在这个边界上，于是 preStop 结束后进程收到 SIGTERM，GracefulStop 只保护了「已经在处理」的 RPC，而这期间新进来的连接仍可能落到正在退出的进程上。你看到的 30～60 秒窗口，等于 6 个副本串行替换 × 每批的暴露时间，和 maxSurge=1 一次只换一个是对得上的。建议按这四层配：preStop 的 sleep 覆盖端点摘除窗口，一般 30 秒起，按「健康检查间隔 × 不健康阈值 + 10 秒」估；terminationGracePeriodSeconds 要大于 preStop 加上最长 graceful 排空时间，两者别贴着算。上游 keepalive 在 ingress-nginx 里默认就是开的，不用额外开，但要调。这几个参数不是 per-Ingress annotation，是 controller 的 ConfigMap 键（upstream-keepalive-connections 默认 320、upstream-keepalive-requests 默认 10000、upstream-keepalive-timeout 默认 60 秒、upstream-keepalive-time 默认 1 小时），整个 upstream 块是全局的，per-Ingress 版本至今没有。要动的是 upstream-keepalive-requests 和 upstream-keepalive-time。默认一条连接能扛一万个请求、活一小时，意思是旧 Pod 上的连接会被一直复用，暴露窗口被拉长。把它降到 1000 左右、keepalive-time 降到 5～10 分钟，连接会周期性重建，每个 Pod 的暴露时间反而更短。客户端侧：wait_for_ready 只对「发起 RPC 时没有可用连接」生效，已建立的 stream 中途断开它救不了；retryPolicy 也不能替你重发已经写出去的非幂等请求。真正能压掉这批错误的是客户端侧负载均衡（grpc-go 用 dns:/// 名字解析加 round_robin 直连 Pod，少一跳被动断开）加上应用层断流重连与幂等键。另外查一下你那台节点上 IPVS 的 expire_nodest_conn。它如果是 1，后端被摘除时内核会立刻丢掉指向它的已建立连接，表现就是 RST 和 connection refused 混着来；conntrack 里残留的旧映射也会让 SYN 重传打到已关闭的端口。用 conntrack -L -d 旧PodIP> 能在发布过程中直接看到这些残留条目。验证方法（按这个顺序看，能定位到底断在哪一层）：# 1. 摘除时刻和 Pod 状态对照 kubectl get endpointslice -w -o wide -n kubectl get pods -w -o wide -n # 2. 旧 Pod IP 上还有没有连接（最直接的证据） kubectl exec -n ingress-nginx -- ss -tn state established '( sport = :80 or sport = :443 )' # 3. 实际生效的 upstream 配置 kubectl exec -n ingress-nginx -- nginx -T | grep -A6 upstream # 4. 报错落点 kubectl logs -n ingress-nginx | grep -E 'upstream prematurely|GOAWAY|client closed|upstream timed out' # 5. conntrack 残留 conntrack -L -d 旧PodIP>改完怎么回滚：annotation 类的改动删掉对应行再 apply，controller 几秒内 reload；preStop 和 grace 改的是 Deployment，直接 kubectl rollout undo。注意 preStop 调大以后，每次发布、节点驱逐、缩容都会多等这段时间，别为了发布无损把驱逐时间拉到不可接受。还有一个方向值得试：Kubernetes 1.26 起有 terminatingEndpoints 相关的能力，允许流量继续打给 Terminating 的 Pod 直到连接自然结束，能消掉「端点已摘但连接还在」这段黑洞。CCE 1.25 不满足版本前提，短期还是靠 preStop 窗口加客户端重连来兜。

这个现象最常见的根因不是"空间真没了"，而是"该看的角度没看全"。按下面顺序查，基本能定位：先看 inode 是不是耗光：df -i /。inode 耗尽的表现是新建文件/目录直接报 No space，但往已有文件里追加写不受影响——因为追加不分配新 inode。看到对应挂载点 Use% 接近 100% 就是它。这一条最能解释"df 块还有、写却失败"：块没满，满的是 inode 表。再看"删了却仍被进程打开"的文件（注意方向）：用 sudo lsof +L1 列出链接数已归 0（nlink1）但仍被打开的文件。这类文件的数据块仍被占用、df 把它计为"已用"，所以它的典型症状是"df 显示已满、但 du 统计不到、删文件也不释放空间"——和本题"df 显示有空间"恰好相反。因此它通常不是你这个现象的原因，但排查时值得确认一下：把 df 和 du -sh / 对比，若 df 远大于 du，就是它在占着，重启对应进程或 :> /proc//fd/ 截断即可释放（看其他用户进程必须加 sudo）。保留块（reserved blocks）：ext4 默认给 root 保留 5%（tune2fs -l /dev/xxx | grep -i reserved 看数量）。常见误解要澄清：保留块已经计入 df 的 Avail（df 用的是 f_bavail，本来就排除了保留块），所以普通用户看到的 Avail 就是真实可用量，不存在"df 显示 20%、实际只剩 15%"的落差。保留块的唯一症状是：Avail 已经归零时，root 仍能写、普通用户才 ENOSPC。也就是说，它只在空间真的快满（剩余量接近保留块大小）时才让普通用户写不了，而你这种"df 还有 20%"的情况基本可以排除保留块。配额（quota）：如果挂了 user/project quota，超限报的是 EDQUOT（"Disk quota exceeded"），不是 ENOSPC（"No space left on device"）——所以你字面看到"No space"时它概率偏低，但仍值得排除：软配额在宽限期内仍可写、超时后才转 EDQUOT。用 quota -s 或 repquota 确认。tmpfs / 内存盘：若目标目录其实是 tmpfs（/run、/dev/shm 等），它的大小挂载时就固定（默认约 50% RAM，或由 size= 指定），不会随内存压力伸缩。写满分两类：一是触及自身 size 上限直接 ENOSPC；二是没有足够的 RAM+swap 来支撑页分配（同样报 ENOSPC，不是 ENOMEM），cgroup memcg 触顶是后者的一种。确认：df -h /run 看是否到上限，free -h 看 swap。排查顺序建议：df -h（看块）→ df -i（看 inode，命中率最高也最易被忽略）→ 对比 du -sh /（排查 deleted-open 占用的反向症状）→ tune2fs -l（确认保留块量级）→ quota -s（看配额）。补充：想从内核层确认是否真有块分配失败，dmesg 需要 root（kernel.dmesg_restrict=1 时普通用户看不到）；journalctl -k 默认含所有已持久化的启动日志，要看当前启动加 -b，看上一次用 -b -1。

这种「df -h 显示还有空间、却报 No space left on device」的故障，根因几乎都不在"剩余字节数"，而在"文件系统允许写入的条件"没被满足。建议按下面顺序排查，基本都能定位。 1）先确认你写到的到底是不是 / 这个文件系统 很多人只看 df -h /，但服务实际写在 /var、/home、/tmp 等独立挂载点上。用 "df -h 具体文件路径" 看真实所在文件系统；例如写 /var/lib/xxx 就 df -h /var/lib/xxx。同理 /tmp、/run 常被 tmpfs 占满，看 / 是没意义的。 2）inode 耗尽（最常见也最容易被忽略） df -h 只统计字节，不统计 inode。小文件成灾（海量日志、session、缓存碎片）会把 inode 用光，此时字节空间可能还很充足，但新建文件/目录需要 inode，于是报 No space。 确认：df -i /挂载点，看 Inode 使用率是否 100%。 定位：逐层找小文件堆积目录，最直接的是 GNU coreutils 的 `du --inodes -x /path | sort -rn | head`，一步列出 inode 占用最高的目录；也可用 `find /path -xdev -type f | wc -l` 分目录对比文件数。找到后清理或归档。 3）文件已删除但仍被进程占用（空间不释放） rm 删掉文件后，只要持有它的进程没关闭文件描述符、没重启，磁盘块就不会归还。表现就是 df 看着空间少了、du 却对不上、写还报没空间。 确认：lsof +L1 或 lsof | grep deleted，会列出已删仍被占的文件及对应 PID。 处理：重载/重启该进程（如 nginx -s reload、重启 Java 服务），让它释放 fd，空间立即回收。注意重启会"掩盖"现场，所以先记下 PID 和文件再操作。 4）ext 文件系统的保留块（默认 5%） ext2/3/4 默认给 root 保留 5% 数据块。当普通用户/进程把空间写到只剩保留块时，非 root 写入就会失败（No space），而 df 显示"还有约 5% 空间"。root 仍可写。 确认：tune2fs -l /dev/sdX | grep "Reserved block count"，再用 df 看剩余比例是否正好落在 5% 附近。 处理：评估风险后可用 tune2fs -m 0 /dev/sdX 把保留比调小（会牺牲 root 救援空间，谨慎）。注意 tune2fs 仅适用于 ext2/3/4；若根分区是 XFS/btrfs，没有等价的一键保留块开关，不能照此操作。 5）用户/目录配额（quota） 云服务器或容器层可能带配额。用 quota -s 或 repquota 看是否触顶；容器里常见 overlay 层写满而底层没满。 6）临时/内存文件系统（tmpfs）写满 /run、/dev/shm、部分 /tmp 是 tmpfs，占用的是内存+swap，与磁盘无关。往里写大文件会先满 tmpfs。用 df -hT 看 Type 列确认是不是 tmpfs（注意要加 -T 才会显示文件系统类型）。 推荐排查顺序： ① df -h 具体路径，确认真实挂载点 → ② df -i 看 inode → ③ lsof +L1 看删占文件 → ④ tune2fs 看保留块 → ⑤ quota 看配额。 实际中 90% 的这类问题落在第 ② 步（inode）和第 ③ 步（删占文件）。 补充：服务报 No space 时，先别盲目重启，先用上面命令把现场定下来——尤其第 ③ 步的删占文件，重启反而会让空间"看起来回来了"而掩盖真正的问题根因。

只回答第 1、3 问里能用本机 shell 实测确定的部分。 先说结论：`set -e` 不是"任何一条命令非 0 就退出"的全覆盖开关，它有豁免上下文；而脚本**走到最后、没有被 `set -e` 提前终止时**，整体退出码取最后一条命令的结果。这两点叠起来，完全可能出现"中间那条报错了、整体却返回 0"。 我在本机跑了下面几组（每行是独立子进程，记录整体退出码；含 `pipefail` 的那行只在 bash 下测，其余基础用例 bash 与 sh 结果一致）： ```text set -e; false; echo reached exit=1 没有输出 set -e; false | true; echo reached exit=0 输出 reached set -e -o pipefail; false | true; echo reached exit=1 没有输出 set -e; false || true; echo reached exit=0 输出 reached set -e; if false; then :; fi; echo reached exit=0 输出 reached set -e; false && echo x; echo reached exit=0 输出 reached false; true exit=0 set -e; false; true exit=1 ``` 从这几组能确定的事实： - 单独一条命令失败时 `set -e` 会提前终止（第一行 exit=1，倒数第二行 `false; true` 没开 `set -e` 才走到最后得到 0）。所以"取最后一条命令"只在没被提前终止时成立。 - **管道最容易踩**：`set -e` 默认只看管道最后一条命令的返回码，`false | true` 里最后一条是 `true`，于是不退出，后面的 `echo` 照常跑；加 `-o pipefail` 后同一段变成 exit=1。 - 命令出现在 `if` 条件里、被 `||` 接住、或处在 `&&` / `||` 串联的非末尾位置，都属于 `set -e` 的豁免上下文，实测三种都继续执行到 `reached`。这几类不是互斥分类，共同点是这条命令的返回值被用作控制流判断，不再触发提前退出。 - `bash -c` 与 `sh -c` 在上面这几组基础用例里结果一致。 关于你看到的 `echo $?` 是 0：`$?` 只表示**紧挨着它的上一条命令**的退出码，不是整个脚本的状态。若它紧跟在失败命令后面，看到的应是 1；只有在它前面那条命令成功时才看到 0。所以这个数字要结合它插在哪一行来读，单凭一个 0 推不出"中间没失败"。日志里"报错输出后紧接着就是 cp 的输出"，与"失败被豁免、后续命令继续执行"这个模式是吻合的，但具体哪一处触发，得看脚本原文，我不替你猜。 第 3 问能确定的部分：`set -euo pipefail` 比单写 `set -e` 多了管道判定（上面第三行实测）和未定义变量的检查；至于它和前面那几类豁免上下文组合起来会怎样，我没有实测，不下结论。想让关键命令的失败不被静默吞掉，可以直接在该命令后判退出码，例如 `npm run build || exit 1`；实测 `set -e; false || exit 1; echo reached` 以 1 退出、后续不执行。这是单层脚本下的结果，若整段又被外层接住或改写，仍需在你们的流水线里实测确认。 平台怎么判步骤成败、有没有步骤级开关，属于产品行为，我这里没有依据，不下结论。

只回答第 1 问里能用本机实测说明的一点，其余各问涉及 MySQL 8.0 的执行计划与具体优化方案，我不凭印象下结论。 先说结论：索引能快速定位，但**带 OFFSET 的 LIMIT 必须先把前面那 N 行读过去、丢掉，才轮到要返回的 20 行**。索引省的是"从哪儿开始找"，省不掉"跳过 N 行"这个动作本身。 我在本机用 SQLite 造了 120 万行的表（主键 id、另建一个 created_at 索引），同样取 20 行，每个位置交错跑 5 轮取中位数： - offset 0 → 0.0001 秒 - offset 1000 → 0.0001 秒 - offset 20000 → 0.0003 秒 - offset 1000000 → 0.0467 秒 而按 id 直接定位、不跳行的写法，在各个位置都稳定在 0.00005 秒上下。前两个数字已经贴近计时精度，不宜拿去精算倍数；能确定的是**深 OFFSET 的耗时随 offset 明显增长，不跳行的写法基本不随位置变化**。本机 SQLite 的执行计划对这条深 OFFSET 语句显示的是扫描表，并没有因为建了索引就变成"直接定位到第 100 万行"。 这组数字只用来说明 OFFSET 的跳行成本这一件事，不能直接搬到你们 MySQL 实例上当性能数据。单就这个语义而言，换掉 OFFSET 的表达方式才不会从原理上产生"跳过前面 N 行"的开销；只要还用 OFFSET 表达"第 N 页"，这部分成本就存在，索引改善的是定位，不是跳过本身。 至于你们环境里 rows 的含义、联合索引为何没根治、时间范围宽了为何变慢得更早，以及任意页能否压进 100ms，都涉及具体执行计划和数据分布，得在你们实例上取真实扫描行数后实测判断，我这里不替你下结论。

只回答第 1 问里我当天实测能确定的部分，外加第 2 问里一条核对思路；其余涉及 lsof、logrotate 的具体行为和参数我不凭印象下结论，按所用环境的文档核对。 先说第 1 问里最容易踩的一个点：`-mtime +30` 并不是「30 天以前」。我在 GNU find 4.10.0 上造了一组文件，把修改时间分别设成距今 29、30.5、30.99、31.0、31.1、32 天，结果如下： - `-mtime +30` 命中 31.0、31.1、32 天这三个，30.5 和 30.99 天都没命中； - `-mtime 30` 命中的是 30.5 和 30.99 天那两个； - `-mtime +29` 命中 30.5、30.99、31.0、31.1、32 天这五个； - `-newermt '30 days ago'` 只命中 29 天那一个。 原因是 -mtime 把年龄按 24 小时向下取整后再比较，`+30` 表示取整后大于 30，也就是实际要满 31 天。所以「保留最近 30 天」这个需求，用 `-mtime +30` 会多留一天左右；想按精确的 30 天边界切，删除条件要写成 `! -newermt '30 days ago'`。这里 `!` 不能省：不加取反时它选出的是「最近 30 天内」的文件，正是要保留的那些；加了 `!` 才是「30 天以前」、也就是要删的那些。用上面那组样本说，不加取反只选出 29 天那一个，加了取反才选出其余五个。 再补一个实测结果：把一个 40 天前的文件用 touch 改成当前时间后，`-mtime +30` 不再命中它，而 `-newermt '30 days ago'` 会把它算进「最近 30 天」。两种写法看的都是 mtime，mtime 被改过，判断就跟着变。所以清理前先抽查边界日期附近文件的实际时间和内容，别只看命令输出就下结论。 第 2 问我只提一条核对思路：真正执行删除前，用与执行时完全相同的一份筛选条件，把清单连同路径、大小、mtime 一起落盘，人工抽查边界附近的文件，确认没有把该留的算进去；筛选条件不要分两次手写，避免演练和执行用的不是同一份。至于「只删已关闭且超过 30 天的文件」，涉及具体应用怎么打开和轮转日志，得在你们环境里验证，我不凭印象给 lsof 的参数组合或 logrotate 的配置。

只回答第 2 问里能用算术确定的部分，其余几问涉及具体接口参数，我不凭印象给数字，建议以所用接口的文档为准。 先说结论：你那个 `partSize = max(8MB, ceil(fileSize / 9000))` 再向上取整到 MB 的思路是对的，留出约 10% 片数余量也算稳妥。我按字节实算了几组，确认它全程不超 10000 片： - 10 GiB → 8 MiB 一片，1280 片 - 50 GiB → 8 MiB 一片，6400 片（固定 5 MiB 则是 10240 片，正是你遇到的超限） - 70 GiB → 8 MiB 一片，8960 片 - 100 GiB → 12 MiB 一片，8534 片 - 500 GiB → 57 MiB 一片，8983 片 有两个容易踩的边界值得补上。 一是**单位口径要统一**。你写的「50GB / 5MB = 10240」是按 1 GiB = 1024 MiB 算的；换成 1000 进制，50 GB / 5 MB 恰好是 10000 片。同一个"50GB"标称容量，在两套进制下对应的字节数并不相同（50 GiB 是 53687091200 字节，50 GB 是 50000000000 字节），片数也不相同。片数只由实际字节数决定，所以别把界面上显示的容量当成精确字节数直接去除。另外 10000 是零余量地贴着上限，一点余量都不留，风险比留 10% 高。建议全程用字节做判据：文件大小和分片大小都先换成字节再相除，别在 MB/GB 之间混用。 二是**取整方向别写反**。以 100 GiB 为例，`ceil(fileSize / 9000)` 得 11930465 字节（真实商约 11930464.71）：向上取整到 MiB 得 12 MiB、8534 片；向下取整到 11 MiB、9310 片；不取整正好 9000 片。这几种都还在 10000 以内，但向上取整能保证 partSize 不小于基准、片数落在 9000 以内；向下取整会让 partSize 变小、片数变多，一旦把分母改成 10000 就可能直接顶到上限。稳妥写法是算完 partSize 之后，再用 `ceil(fileSize / partSize) = 10000` 回验一次，不满足就把 partSize 再抬一档；这个回验比只依赖公式本身更可靠。 还有一个隐性约束：8 MiB 下限被钳住的那一段，能承载到 8 MiB × 9000，也就是 70.3125 GiB（此时正好 9000 片）。文件再大，`ceil(fileSize/9000)` 才会超过下限并开始抬分片，比如 71 GiB 就变成 9 MiB 一片。这不是错误，但如果要支撑你说的 100GB 以上，最好在代码里明确写出这个切换点，免得有人把下限调大之后忘了同步检查上限。

从连续几天的签到明细看，超过 7 天之后，每条签到记录的标题确实还是「签到第7天」，没有变成第 8 天、第 9 天，和你截图里的现象一致。 要把「标题文字」和「入账金额」分开核。我逐条筛出标题为签到的记录看，每笔都是同样的加分，各自有独立的明细和余额，连续几天都有，没有因为标题停在第 7 天就少一笔。所以至少在我能核到的这些签到记录上，停在 7 的是标题里的天数，加分本身照常。至于其它结算规则是否也受影响，光凭这几笔看不出来，不建议就此下结论。 自查时别看余额总额往上走就断定没问题：同一时段往往还有发布文章、体验、采纳等其它项目的明细一起入账，余额是好几笔叠出来的。更稳的做法是只筛出签到那几条，逐笔确认三点：每天是否都有一条签到明细、每条加的分数是否一致、有没有哪天整条缺失。三点都对得上，基本可排除漏记；如果某天缺了整条记录，那才是需要单独核查的漏记。 提交给运营时，附上出现该现象的日期区间和几条明细截图（保留页面上的时间与分数），比只说「天数不对」更容易定位。

先别急着重复发同一篇，也先别按「漏发」处理。按下面顺序核一遍，基本能分清是延迟、审核状态，还是确实需要找运营。 一、「发布成功通知」不等于「任务判定完成」。成长中心「每日发布文章」的规则原文是「提交发布并审核通过，即可完成任务」。站内信提示发布成功，只说明投稿提交成功；文章详情页能公开访问，只说明内容可见。两者都不代表激励侧已经判定完成，所以任务卡显示未完成，不能直接推出漏发。 二、最可靠的判据是积分流水，不是任务卡。请到积分流水里查有没有一条名为「每日发布文章」的明细，以及对应的余额变化。任务卡状态与积分入账不同步：实测出现过动作已完成、任务卡仍显示未完成，而流水里稍后才出现明细的情况。只盯任务卡容易误判。 三、结算延迟不是分钟级。最近两天的实测：文章上午 9 点多发布，积分当天 10 点多才入账；也有当天早上做的动作，到当天晚上才入账，延迟可达十余小时。所以刚发布后的几个小时里任务卡保持未完成、流水暂时没有明细，属于常见情况，不必立刻重复投稿。 四、同一天只计一次。如果当天还发过别的文章，只有其中一篇计分；为了催积分再补发一篇，并不会把分数补上。 五、什么时候该找运营。等待时间已明显超过你平时观察到的延迟、积分流水里仍始终查不到这条明细时，建议提交核查，并把材料一次给全：文章链接、发布成功站内信（含时间）、积分流水的完整截图。材料齐全能少走几轮沟通。 补充一个记账上的坑：核流水时按每条明细后面的「余额」逐条核对，不要自己按分数加减去推算；以流水里的余额为准，比自己算可靠。

这个现象里最值得先怀疑的，不是并行本身，而是「两个模块的 groupId 真的不同吗」。Maven 子模块如果没有显式写 ，会继承父 POM 的 groupId（version 同理，只有 artifactId 必须自己声明）。多模块工程里两个子模块都叫 model-core，若各自没写 groupId，它们最终的完整坐标就是同一个 groupId:artifactId:version，后 deploy 的覆盖先 deploy 的完全说得通，而且和「谁先落地不确定」正好吻合。您看到的是「同名包覆盖」，本质很可能是同坐标覆盖。先做一次确定性验证，别靠 POM 源文件肉眼判断：mvn -pl 模块A> help:effective-pom | grep -m1 groupId mvn -pl 模块B> help:effective-pom | grep -m1 groupId # 或直接取解析后的坐标 mvn -pl 模块A> help:evaluate -Dexpression=project.groupId -q -DforceStdout再看制品仓库上的实际路径是不是 /model-core//。如果两条 deploy 落在同一个目录，坐标就是相同的。Maven 仓库按完整 GAV 隔离，不同 groupId + 相同 artifactId + 相同 version 本来不该互相覆盖；所以要么坐标其实相同，要么这个仓库的存放/去重规则没有按完整 GAV 走——这一步能把两者区分开。第二个反常点：两条 deploy 都 BUILD SUCCESS。 标准 Maven release 仓的默认部署策略是禁止重新部署（Disable Redeploy），同一个 GAV 再传一次应当直接被拒（常见 400 / 409）。您这里能静默覆盖，说明该 release 仓开了「允许重新部署」。建议把它改成禁止覆盖：这样冲突会从「下游偶发拉错包」变成「第二次 deploy 当场失败」，问题立刻可见、可定位，也不会污染已经发出去的版本。按您列的三个问题：同 artifactId 多 groupId 能否隔离 / 有没有项目级命名空间：先用 effective-pom 和仓库实际路径确认真实坐标。是否提供项目级命名空间隔离、以及开关在哪，需要以所用制品仓库的实际策略页为准，我不替您猜控制台选项；但只要完整 GAV 唯一，标准 Maven 仓库就不会互相覆盖。并行 stage 里的版本锁 / 互斥：不建议把它当根治手段。锁只能保证先后顺序，保证不了「坐标不同」。更稳的组合是：release 仓禁止覆盖 + 把 deploy 阶段从并行 stage 里拿出来串行执行（构建仍可并行，产物先落到工作区，最后统一上传一次）。这样既保留并行速度，又让写入单点化。拆成独立 repo：不是解决这个现象的必要条件。它解决的是权限边界和发布节奏，代价是拆 5 个仓、父 POM 与 dependencyManagement 重构、版本联动改动，改造量明显大于前两步。建议先做「坐标唯一 + 禁止覆盖 + 串行上传」，跑稳了再评估要不要拆仓。补充两条可复现的收尾检查：一是在流水线里把每次产物的 SHA-256 与 Git commit 一起打到日志/制品描述上，下游拉包时校验，能直接发现「版本号一样但内容不是同一份」；二是固定 release 版本号时，让构建号只作为元数据而不写进 GAV，避免为了绕冲突又破坏可复现性。顺序上建议：effective-pom 验证 → 给每个模块显式声明不同 groupId（或给 artifactId 加服务前缀）→ release 仓改为禁止覆盖 → deploy 串行化。前三步通常就能让这个偶发问题彻底消失。