前面几位把“买多大、怎么算账”讲得很全了，我补一个没人细展开的环节：规格定下来之后，怎么在控制台把“换规格”“扩磁盘”“设告警”真正落地。5 楼、6 楼都提过 ECS 支持变更规格，这里把操作步骤和命令写全。一、变更规格：先关机，再变更1. 动手前先备份：控制台 → 云备份（CBR）或云硬盘备份，给系统盘、数据盘各做一次备份；确认没有正在跑的定时任务和未提交的写操作。2. 关机：弹性云服务器 → 选中实例 → 关机。变更规格要求实例处于关机状态（以控制台实际提示为准）。3. 变更规格：实例详情页 → 更多（或操作列）→ 变更规格，选目标规格提交，等实例状态回到“关机”后再开机。4. 开机后核对：nproc 看 vCPU 数，free -g 看内存，确认与目标规格一致；再检查业务进程、监听端口是否正常。注意事项：- 不能跨 CPU 架构变更规格（x86 与鲲鹏 ARM 之间不能直接变更，跨架构要重建实例、迁移数据）。- 包年包月升配通常涉及补差价，具体金额以费用中心账单为准；按需实例变更后按新规格单价计费。- 变更前记下当前规格、弹性公网 IP、云硬盘挂载关系，万一要回退有据可查。二、磁盘满了先扩盘，不用换规格磁盘是独立资源，容量或 IOPS 不够先扩云硬盘，通常不用动实例规格：1. 控制台 → 云硬盘 → 选中数据盘 → 扩容，输入新容量并提交。2. 进系统扩展文件系统。先看类型和挂载点：df -T /data。- ext4 且是分区盘：先扩分区再扩文件系统：growpart /dev/vda 1，然后 resize2fs /dev/vda1。- xfs：xfs_growfs /data。- 如果磁盘没有分区、直接整盘格式化，跳过 growpart 那步，直接对设备扩文件系统。（若提示找不到 growpart，先安装 cloud-utils-growpart，以系统实际包名为准。）3. 验证：df -h /data 看容量是否变大；再确认数据库/日志恢复写入，没有再报磁盘满。注意事项：扩容只增不减，操作前先备份；系统盘扩容后同样要在系统内扩展文件系统才生效，光在控制台扩完还不够。三、让监控替你盯着升降配在云监控 CES 里建告警规则，阈值可参考前面几楼的经验值：- CPU 使用率 > 80% 持续 5 分钟；- 内存使用率 > 85% 持续 5 分钟；- 磁盘使用率 > 80%；- 磁盘读写时延持续偏高。通知绑短信/邮件，在 CES 告警规则里配置接收人。收到告警先按“磁盘先扩盘、CPU/内存先看瓶颈”的顺序处理，别等业务超时了才去翻监控。一句话总结：前面几楼帮你定“买多大”，这楼补“买了之后怎么改、怎么扩、怎么让它自己提醒你”。

补充 1 楼的落地方案。1 楼的方向是对的：循环里直接调历史数据接口扛不住，改成“应用侧分页拉取”；下面是分页接口和调用侧的具体做法，供实施参考： 1. 分页接口的形态（建议）入参至少包含：设备标识、起止时间（startTime/endTime）、页大小（pageSize，建议先取 100~500 条，压测后再调）、页码或游标（page/pageToken，游标优先，避免深翻页偏移漂移）。出参至少包含：本页数据、是否有下一页（hasMore）或下一页游标（nextToken）、本页条数。接口内部按时间升序返回，保证分页边界不丢不重。服务端做限流保护：单次查询时间窗上限（例如一次最多查 1 小时/1 天，按数据密度定）、单设备并发上限；超限返回明确错误码，不要静默截断。 2. 调用侧循环的写法按时间窗切片：把要查的总时段切成小窗（如每 30 分钟一段），每窗内再分页；先跑一个设备、一个小窗验证通过后再全量。循环终止条件：hasMore 为 false 或 nextToken 为空即停；同时加“空页保护”——连续两页返回 0 条就停，防止死循环；再加总页数/总时长上限兜底。失败重试：单页失败只重试该页（指数退避，如 1s、2s、4s，最多 3 次），重试后仍失败就记录断点（设备+时间窗+游标）后跳过，不要从头重跑。 3. 容易再踩的两个坑不要把分页拉取又放回 LinkFlow 脚本里循环：脚本侧的调用次数上限还在，分页逻辑放应用侧服务里做，LinkFlow 只触发一次任务或按设备分发。大结果集先落库/落文件再处理，不要全放内存里攒；处理完一页就写一页，断点可续。 不确定、需按现场核实的一点：LinkFlow 与这套历史数据接口在矿鸿项目侧的具体参数名、页大小上限和错误码，我没法从帖子信息里确认，请以平台实施文档/接口定义为准；上面的时间窗、页大小数值是建议初值，压测后以实测能稳定跑通的值为准。

先说结论：提供的 rpm 里如果确实没有 ffmpeg 和 opencv，就走源码交叉编译，按 2 楼说的文档里“如何使用交叉编译器编译开源软件”那一章的框架做；不要直接在 x86 编译机上 apt/yum 装一份 opencv，那是给本机用的，链接到 MDC 板卡上会报错。第一步，先确认 rpm 里到底有没有，避免白走源码这条路：rpm -qa | grep -iE 'opencv|ffmpeg'同时在提供的 rpm 清单/目录里再搜一次 opencv、ffmpeg（包括 -devel 包）。我没有你这份清单，无法替你确认 1.1.027 版本是否补了这两个库的 rpm——如果找到了对应的 aarch64 rpm，优先用 rpm 装。第二步，源码交叉编译，顺序是先 ffmpeg、后 opencv（opencv 开 WITH_FFMPEG 要先有 ffmpeg）：1. 用已搭好的 MDC 交叉编译环境，确认工具链可用，例如 aarch64-linux-gnu-gcc --version 能正常输出；工具链名和 sysroot 路径以你那份《编译环境搭建指南》为准，不同版本可能不同。2. ffmpeg：./configure --enable-cross-compile --cross-prefix=aarch64-linux-gnu- --arch=aarch64 --target-os=linux --sysroot=交叉编译环境的 sysroot> --prefix=安装目录>make -j$(nproc) && make install3. opencv：准备一个工具链文件，关键是三行：CMAKE_SYSTEM_NAME 设为 Linux、CMAKE_SYSTEM_PROCESSOR 设为 aarch64、C/C++ 编译器分别设为 aarch64-linux-gnu-gcc / aarch64-linux-gnu-g++，并把 CMAKE_FIND_ROOT_PATH 指向 sysroot；然后：cmake -DCMAKE_TOOLCHAIN_FILE=工具链文件> -DCMAKE_BUILD_TYPE=Release -DWITH_FFMPEG=ON -DBUILD_opencv_python2=OFF -DBUILD_opencv_python3=OFF -DBUILD_TESTS=OFF -DBUILD_PERF_TESTS=OFF -DBUILD_EXAMPLES=OFF make -j$(nproc) && make install如果 ffmpeg 那步还没做，WITH_FFMPEG 先改成 OFF，等 ffmpeg 编好再回头开 ON。第三步，部署和验证：把编译出的 .so 拷到板卡运行环境的库目录，跑 ldconfig，或临时 export LD_LIBRARY_PATH=板卡上的库目录>；用 file 检查 .so 是 aarch64 而不是 x86_64，再用一个最小的读视频/读图程序在板卡上跑通。另外提醒一个版本口径：正文写的是 MDC 610 1.99.220，1 楼又写 1.1.027-0000000T1，两处不一致，工具链和 sysroot 路径建议按 1.1.027 那份文档核对一遍。

1 楼的思路是通用的排查方法，我补充一些 OBS 上新手最容易踩的具体坑，都是能提前避开的。1. 桶名全局唯一，区域选定后不能改桶名在全平台唯一，别人建了同名桶，你就建不了。桶名 3~63 个字符，只能用小写字母、数字、连字符（-）和点（.），不能写成 IP 地址的样子。区域（Region）建桶时选定后不能改，想换区域只能新建桶再迁移对象。建议先定好就近区域和桶名规范（按用途、项目、环境分级），再建桶。2. 默认私有，浏览器直接打开对象链接报 403新桶默认是私有的，对象 URL 在浏览器里直接打开会提示没有访问权限，这是正常的，不是链接错了。需要临时让别人下载时，不要把整个桶改成公共读：可以用 SDK 的临时签名 URL（例如 ObsClient 的 createSignedUrl，obsutil 也有 sign 命令，设置过期时间），过期自动失效；或者只对单个对象配桶策略授权。公开桶一旦打开，桶内对象都可能被匿名拉取，一定要慎用。3. 403 报错要查两层权限：IAM 策略和桶策略只给账号配了 IAM 权限还不够，读写还受桶策略（Bucket Policy）控制；跨账号或匿名访问还要看桶 ACL 和委托。建议按这个顺序排查：① IAM 用户/用户组有没有 OBS 操作权限；② 桶策略是否允许该账号和这个操作；③ 匿名或跨账号场景是否配了桶策略、委托。给人临时授权尽量用临时安全凭证或委托，不要直接把主账号的 AK/SK 交出去。4. 前端直传报跨域错误在浏览器里用 JS、Fetch 或 SDK 直接向 OBS 传对象，报跨域错误很常见。解决办法是进控制台的桶-权限控制-跨域资源共享（CORS），按需配置允许的来源（Origin）、请求方法（GET、PUT、POST 等）和请求头。只配桶策略、没配 CORS，前端直传照样跨域失败。5. 分段上传的碎片会一直计费大文件分段上传中途失败或取消后，未完成的“碎片”（未完成的分段上传）不会自动消失，会继续占用存储并计费。定期去控制台的“碎片管理”清理未完成的分段上传，或者给桶配生命周期规则自动清理碎片。6. 开了版本控制，删除只是打“删除标记”开启版本控制后删除对象，只是写入一个删除标记，历史版本还保留并继续计费，不是真的删掉。要彻底删掉历史版本，需要去版本管理里删除历史版本，或用生命周期规则定期清理历史版本。没开版本控制时删除是真的删除，动手前注意备份。7. 存储类别选错，取回慢还要收恢复费标准、低频访问、归档的读取费用和取回时效不同，低频和归档取回要等待，还要另外付数据取回费。热数据如果误存进归档类，访问会卡，还会多出费用。按访问频率选存储类别；放错的可以通过对象迁移或生命周期规则转回标准存储。8. 内容类型和下载文件名上传时没指定 Content-Type，文件链接在浏览器里打开可能直接显示而不是下载，中文文件名还可能乱码。上传时在控制台或 SDK 里设置对象的 Content-Type；需要浏览器下载时，再设置 Content-Disposition 为 attachment；文件名建议用英文或做 URL 编码。基本建议：动手前先在控制台确认桶状态与权限，关键操作先用测试桶走一遍完整流程，再动生产数据；涉及存储类别、碎片、版本、数据取回这些费用项，先到费用中心核对一遍再操作。

楼上几位把坑列得很全了，我不再重复清单，只补一段我实际在跑的操作：先用 obsutil 在命令行把上传、下载、删除走通，确认没问题再动生产桶。控制台点来点去出了问题不好定位，命令行能直接看到报错。1. 装 obsutil，AK/SK 从控制台右上角账号 → 我的凭证里取，别写进代码和公开仓库。obsutil config -i=你的AK -k=你的SK -e=https://obs.cn-north-4.myhuaweicloud.com-e 是桶所在区域的 endpoint，必须和桶的区域一致，不确定就去桶概览页抄，别凭印象填。区域写错，命令直接连错地方，报 403 时先查这里。2. 先在测试桶把上传、下载、删除走一遍，都通了再去生产桶建同样的结构：obsutil mb obs://my-test-bucketobsutil ls obs://my-test-bucketobsutil cp ./index.html obs://my-test-bucket/site/index.htmlobsutil cp obs://my-test-bucket/site/index.html ./obsutil rm obs://my-test-bucket/site/index.html -f整个目录传加 -r。大文件 obsutil 会自动分段上传，断网后续传，比控制台拖文件稳。3. 浏览器直传先配 CORS，配完先拿 curl 验，别直接去调前端：curl -H "Origin: https://你的前端域名" -I https://桶名.obs.cn-north-4.myhuaweicloud.com/site/index.html回包里有 Access-Control-Allow-Origin 才算生效。没有就按这个顺序查：规则到底保存了没有、来源域名写没写错（多一个斜杠都不行）、请求的 endpoint 是不是这个桶的区域。4. 临时给人下载单个文件，别去改桶策略：obsutil sign obs://桶名/对象名，签的时候设好过期时间，过期自动失效，比事后回来删策略干净。5. 生命周期一次配好，别等账单慢慢变贵：测试桶我一般直接配三条——30 天后转低频访问存储、90 天后过期删除、7 天清理未完成的分段上传。第三条最容易被忽略：分段上传中途断了，碎片还留在桶里计费，不清就是一直在交钱。

前面 3、5、6 楼的坑列得很全了，我不重复列清单，只补一段能直接照着跑的操作：obsutil 命令、桶策略收窄、CORS 验证、生命周期三条规则。一、装 obsutil，把上传下载走命令行（比控制台点来点去稳）AK/SK 从控制台右上角账号 → 我的凭证里取，别写进代码和公开仓库。obsutil config -i=你的AK -k=你的SK -e=https://obs.cn-north-4.myhuaweicloud.com（-e 是桶所在区域的 endpoint，要和桶的区域一致；不确定就去桶概览页抄。）obsutil mb obs://my-test-bucketobsutil ls obs://my-test-bucketobsutil cp ./index.html obs://my-test-bucket/site/index.htmlobsutil cp obs://my-test-bucket/site/index.html ./obsutil rm obs://my-test-bucket/site/index.html -f整个目录传加 -r；大文件 obsutil 会自动分段上传，断网后续传。先在测试桶把上传、下载、删除走一遍，再动生产桶。二、只给必要前缀公开读，别整桶公开做静态网站、公开图片时：桶 → 权限控制 → 桶策略，动作只选 GetObject，资源范围只写到对象前缀（比如 site/*），不要直接把桶改成公共读。临时给人下载用临时 URL：对象右键分享，或 obsutil sign obs://桶名/对象名，设好过期时间。三、浏览器直传先配 CORS，再调前端桶 → 权限控制 → 跨域资源共享（CORS）：来源填前端的完整域名，方法勾 GET、PUT、POST、HEAD，允许的头填 *，暴露的头加 ETag。配完先用 curl 验：curl -H "Origin: https://你的前端域名" -I https://桶名.obs.cn-north-4.myhuaweicloud.com/site/index.html回包里有 Access-Control-Allow-Origin 才算生效；没有就是规则没保存、域名写错，或者走错了 endpoint。四、生命周期一次配好，防账单慢慢变贵桶 → 对象管理 → 生命周期管理 → 创建规则，测试桶建议三条：30 天后转低频访问存储、90 天后过期删除、7 天清理未完成的分段上传。开了版本控制再加一条删除历史版本——只删对象会打删除标记，旧版本还在计费。删桶前先清空对象和历史版本。上线前自查（照着勾一遍）：1. 桶的区域、endpoint、SDK 里写的区域是同一个；2. 桶默认私有，公开读只放到了必要前缀；3. 对象名/前缀按业务/环境/用途定好再上传，上传后改路径等于重新传；4. 分段上传碎片、版本控制、生命周期三项状态确认过；5. AK/SK 没进代码和仓库，生产用最小权限的 IAM 用户或临时凭证。一句话：新手坑大多不是上传本身，而是权限、区域、命名和清理没在建桶时定好；上面这四组操作走一遍，基本一次避开。

先说结论：链路已经通了，问题不在连通性，在平台侧的进度同步。2楼把路由自查讲得很全了，我只补充他没提到的两点：一个是你截图里已经有的关键证据，一个是人工复核具体怎么提。一、你截图里已经有一个“实验完成”的证据你的实验报告页最后一步写着“ping命令成功，路由条目生效，对等连接生效。至此本实验完成！”，但外层实验页的进度条还停在80%。报告页内部已经判定最后一步完成，外层进度没同步——这说明卡在平台侧的检测/同步上，不是你的操作问题。申请人工复核时，把实验报告页这张截图和外层进度80%的页面截图并排附上，对比最有说服力。二、补一个核对点：对等连接本身的状态去VPC控制台→对等连接，找到这条peering-test，看状态是不是“已接受”。误点【暂不添加路由】不影响连接本身，但如果这条连接处于待接受或异常状态，手动补的路由再对也触发不了检测。同时确认两端路由的“下一跳”确实指向这条peering-test（而不是另一条同名或旧的对等连接）。从你的路由表截图看，两端都对，复核前再确认一次状态列就行。三、人工复核这样提（按这个清单一次给全，避免来回问）通过ICT大赛官网公布的大赛技术支持/客服入口提交（具体入口名称我不确定，以大赛官网当前公布的为准）。附上：实验名称（华为ICT大赛云赛道KooLabs VPC对等连接实验）、实验编号（从实验页面或实验报告里复制）、操作账号和区域，以及你已经保存的截图：ping完整结果、对等连接、两端路由表、实验报告页“至此本实验完成”、外层进度80%的页面。四、两点提醒1. 如果实验还在进行中、资源还没释放，在复核完成前先别点“结束实验”或释放资源，资源一释放，检测程序就读不到状态，复核也没法做。2. 我没法确认KooLabs的检测是定时轮询还是在点“结束实验”时才跑最终判定，所以“再等10~30分钟”只能复述2楼的说法。如果等到剩余时间结束仍未更新，就按上面清单直接提人工复核，不用反复改路由——链路已经是通的，再改路由帮不上忙，反而可能改坏。

SWR 的权限要分两层配，很多人只配了一层就以为配完了：第一层是 IAM（谁能进 SWR、能做什么操作），第二层是 SWR 组织/仓库层面（这个身份能看到、能推拉哪个组织下的哪个仓库）。两层都要对上，缺一层就会 403 或 unauthorized。 一、先定分工，别共用主账号 AK/SK推镜像、拉镜像、管仓库分开建 IAM 用户（或用户组），按最小权限给。主账号只做管理员和应急，日常 CI 推镜像用一个只有推权限的专用账号，线上 CCE 拉镜像用一个只有拉权限的专用账号。这样轮换凭证、出了问题也好定位，不会一改就全断。不要把长期 AK/SK 写进代码仓库、镜像层、启动脚本或公开的 CI 日志里，泄露后第一时间在 IAM 里禁用/删除并重新生成。 二、IAM 侧：给人/给服务配 SWR 权限在 IAM 里建用户组（例如 swr-push、swr-pull），把人加进组，权限挂在组上而不是逐个人挂，后续加人直接进组。推镜像的组给 SWR 的上传/建仓类权限；拉镜像的组只给拉取/查看类权限，不要给删除、改公开属性这类写权限。注意：以下两点我没有在你这条帖子里看到你的具体配置，所以按“以控制台当前显示为准”处理——SWR 预置策略的具体名称、以及组织授权的入口位置，不同区域/版本可能有差异，配置时以控制台里 SWR 对应的策略列表和组织页实际显示为准，不要凭记忆照抄策略名。跨账号、跨项目拉镜像时，先确认目标账号的 IAM 侧是否真的有该区域 SWR 的权限，再查 SWR 侧，别只查一边。 三、SWR 侧：组织和仓库的可见范围SWR 按组织（Organization）归集仓库：先在 SWR 控制台确认镜像属于哪个组织、哪个仓库、哪个区域，区域错了，权限对了也拉不到（表现为 manifest unknown / not found，而不是 403）。私有仓库默认必须登录认证才能拉；如果你希望别人免登录拉取，要确认仓库是否被设成了公开属性——不要为了排障临时把私有仓库改公开，公开后任何人拿到地址都能拉，事后也容易忘记改回去。一个仓库只放一类用途的镜像（例如业务镜像和基础镜像分开组织），权限出问题时影响面小，也方便按组织做审计。 四、拉取侧：CCE/ECS 上怎么用这套权限CCE 拉私有镜像要在 Pod 所在命名空间配 imagePullSecrets，凭证就是上面那个只给拉权限的 IAM 用户的 AK/SK（docker login 的用户名格式按 SWR 文档给出的 region@AK 形式），并在 Pod 或 ServiceAccount 上引用；只配了 IAM、没配 imagePullSecrets，kubelet 仍然会报 unauthorized，这一步 2 楼已经讲过，这里不再展开。本地 docker login 时先确认登录的 SWR Endpoint 和镜像所属区域一致，区域不一致时换 Endpoint，不要反复换账号试。凭证失效、轮换后要同步更新 imagePullSecrets 和 CI 里的凭证，旧凭证留在 Secret 里会导致“昨天能拉、今天突然 unauthorized”。 五、出问题时按这个顺序查，少走弯路1. 先看报错原文：unauthorized/authentication required 是认证/凭证问题；403 是有身份但无权限；manifest unknown 是镜像名、tag、区域错了。2. 再看 IAM：这个用户/组到底有没有该区域 SWR 的对应操作权限，策略有没有限定到错误的组织或项目。3. 再看 SWR 侧：组织、仓库名、公开/私有属性有没有错。4. 最后看拉取侧：imagePullSecrets 有没有挂到正确的命名空间和 ServiceAccount，Endpoint、区域有没有写错。5. 排障时不要贴出 AK/SK、完整签名或 Token，只贴脱敏后的错误码、区域、组织/仓库名和操作步骤。 一句话总结：SWR 权限 = IAM 管“谁能做什么”+ 组织/仓库管“能动哪个仓库”+ 拉取侧正确带上凭证，三处对齐才算配好。

补充一个可以直接照做的判定表和操作清单，前面几楼的原则不再重复。 一、先拿数：到控制台看什么1. 华为云控制台 → 云监控服务 CES → 云服务器监控，选你的实例，时间范围拉 1-2 周，看 CPU 使用率、内存使用率、磁盘使用率、网络出入速率的峰值，不要只看平均值。2. 实例内辅助定位：top 看 CPU 和内存，vmstat、iostat 看磁盘和等待，ss 看连接数。单次快照不作数，连续一周的曲线才作数。3. 记下三组数和出现时间：峰值 CPU、峰值内存、峰值带宽/磁盘 IOPS，以及峰值是定时任务还是真实流量。 二、一个算例判定表（数字是示例，不是推荐值）假设现有 4 核 8G，连续两周数据如下，决策就按表走：- CPU 峰值 55%、内存峰值 70%、业务还在增长：CPU 还有余量，不急着升核；内存已到 70%，优先考虑同系列内存比例更高的规格，或者横向加实例，而不是直接把核数和内存一起翻倍。- CPU/内存峰值长期低于 20%：先降一档观察一到两周，再决定是否继续降，不要一次降到底。- 只有某个时段（例如每天 20:00-22:00）冲高，其余时间很低：不要按峰值买常驻规格，用弹性伸缩组在高峰时扩容、低谷时缩容，基线部分再用包年包月。- 磁盘或带宽先满、CPU 还很低：瓶颈不在核数，升级核数是浪费，先看磁盘类型/IOPS 和带宽计费方式。 三、变更和复盘的操作清单1. 变更前：先做云服务器备份或快照，并确认备份可恢复；选一个业务低谷窗口操作。2. 变更时：按控制台提示操作，多数规格变更要求先关机再变更，具体是否需要关机以当前控制台提示为准（不同实例类型可能不同，我未在你的实例上实测）。3. 变更后：观察一到两周，同时看三项——CPU/内存峰值、业务响应时间、错误率，任一项恶化先回滚再分析，不要只看监控变绿就收尾。4. 每月复盘一次：到费用中心看账单，清理长期闲置的实例、未挂载的云硬盘、未使用的弹性公网 IP，这些关机后仍可能继续计费。5. 容易踩的坑：只按平均值选型；把峰值翻倍买大；把有状态服务放进可中断实例；伸缩组不设最大实例数，导致高峰费用失控；升配后不复盘，低负载一直按高规格付费。 一句话：用峰值定容量、用瓶颈定规格族、用计费分层和伸缩削峰、用变更前备份和变更后观察收尾。

先定位：第二次节点到底进没进不要先怀疑控件本身，先看流程轨迹/日志里第二次查密节点有没有被执行到：1. 在流程测试日志里找第二次查密节点的进入记录和退出分支。能找到进入记录，说明流程走到了，问题在节点内部或它的出参；找不到，说明第一次收号结束后的分支就走偏了，问题在第一次节点之后的连线或条件。2. 对照提问者圈出的打印位置：第一次收号结束时打印了什么变量值，第二次节点进入时（如果进了）打印的入参是不是同一个值。入参是空、还是上一次的值原样传下来，这一步能区分“没进来”和“进来但入参不对”。重点查：第二次结果是不是被第一次的结果覆盖了帖子说第二次是赋值/引用第一次查密复合 Cell 的结果，这里是最可疑的一处：1. 打开第二次查密复合 Cell 的配置，逐项核对它的出参变量名：是不是和第一次的出参用了同一个变量名，导致第二次还没收号，变量里就已经是第一次的值；或者第二次的赋值动作发生在收号之前，把第一次的结果先写了进去。2. 在第二次节点前后各加一个打印（或看现有日志）：收号前变量值、收号后变量值。如果收号前变量已经有值、收号后值没变，说明第二次收号根本没把新结果写进来，流程按旧值/空值走了失败分支。3. 和能正常跑的密码修改流程逐项对照同一处配置：出参变量名、赋值时机（收号前还是收号后）、引用方式（直接引用还是复制一份）。两个流程“同样写法”不等于同一处配置，重点对变量名和赋值顺序这两行，截图并排贴出来比对。再对照收号参数：位数、超时、结束键如果第二次节点进了、变量也没被覆盖，再查收号本身的参数，拿密码修改流程的同一组参数做对照表：1. 收号位数：第二次要求几位，第一次输完密码后有没有多按或少按一位，导致位数没凑够就超时。2. 超时时间：第二次的收号超时是不是设得比第一次短，第一次播报加输入的时间一长，第二次还没输完就超时走了失败分支。3. 结束键：第二次的结束键（比如 #）和第一次是否一致，用户按的键有没有被当成结束键提前截断。4. 超时分支和失败分支指向哪里：这是解释“直接播报本次服务结束并挂机”的关键一环——如果超时/失败分支直接连到了结束服务节点，现象就和描述完全对上。把第二次节点的超时、失败、异常三个出口分别指到哪里列出来，错接的那个就是病根。和密码修改流程的对照清单发布前按这张表逐项打勾，勾完还没找到差异，再贴日志请原帖补充：- 第二次查密节点是否进入（轨迹/日志有无进入记录）- 第二次出参变量名是否与第一次重名，赋值在收号前还是收号后- 收号前变量值、收号后变量值（日志实测）- 收号位数、超时时间、结束键（与密码修改流程逐项对照）- 超时/失败/异常三个出口分别指向哪个节点- 第一次收号结束后的连线条件，是否可能直接跳到结束服务一句话收尾第一次能用、第二次挂机，先别换控件：大概率是第二次节点的出参变量被第一次的结果覆盖了，或者超时/失败出口错接到了结束服务；按上面“进没进、变量变没变、出口指到哪”三步查，查到哪一步对不上，改那一处。