别在页面上找，活动 ID 得从接口拿。展览馆/大赛页面大多是异步渲染，ID 藏在返回体里，页面既不展示也不在 href 上。两个可靠办法：一、接口直取（最稳）。活动列表走 devdata2.huaweicloud.cn/rest/developer/fwdu/rest/developer/user/hdcompetitionservice/v1/competition/get-competition-list，POST，body 带 category_id、statuses、limit、offset（offset 从 1 开始，传 0 会报 HD.66011001 parameter is error）。返回 results[] 每项都有 url_id 与 registered_status，那个 url_id（形如 1300000354）就是活动 ID。请求带登录 cookie，在页面控制台里发即可。二、从路由反推。活动详情页地址里 competition/information/ 的 就是；提交页 information//submission 还能同时拿到赛段。几个已知坑：① 域名必须是 devdata2，写成 devdata 会返回 HD.66020077 Path Invalid；② 列表卡片上的「立即报名」是假按钮，点了只跳回成长中心，别指望从它拿 ID；③ 分页 offset 是序号起点不是页码，翻页用 offset = (page-1)*limit + 1。拿到 ID 后，报名页 competition/raceEnrollment/、组队 information//myteam、交作品 information//submission 都能直接拼出来，不用再绕列表。

补几个实际部署一定会撞到的点，光知道「hash 不用配服务端」容易踩坑。1. history 模式的 404 是服务端问题，不是前端问题。必须把所有未匹配路径回退到入口 HTML：nginx 写 location / { try_files $uri $uri/ /index.html; }。注意别把 /api、/static 一并回退，要单独 location /api { proxy_pass ...; } 放前面，否则接口 404 也返回 HTML，前端拿到一段 HTML 解析 JSON 失败，排查方向全跑偏。对象存储静态托管同理，要配「404 回源 index.html」。2. base 路径。部署在子目录（如 /app/）时，history 模式必须 createWebHistory('/app/')，同时构建的 base 一起改；hash 模式不敏感。这是「本地好、线上白屏」的头号原因。3. 刷新时机与 CDN。history 模式下每个路径都会被 CDN 当独立资源缓存，务必让 HTML 走短缓存或不缓存（Cache-Control: no-cache），静态资源用带 hash 文件名长缓存，否则发版后用户拿旧 HTML 去请求已删除的 chunk，报 Loading chunk failed。4. SSR 与分享卡片。要做 SEO 或微信分享摘要，hash 模式基本没戏（锚点不发给服务端），必须 history + SSR/预渲染；纯内网后台则 hash 更省事，能省掉一堆 404 工单。5. 迁移顺序：先配服务端回退并验证 curl -I /deep/path 返回 200 → 再改路由模式 → 再统一替换外链与埋点（旧带 # 链接做 301 或前端重定向兼容）→ 最后清缓存。顺序错了会出现一批「老链接打不开」的投诉。

先定位是哪一层丢了元数据。npu-exporter 的 pod/namespace/container 三件套不是从 NPU 驱动拿的，而是从容器运行时（CRI）反查的。所以驱动一升级就丢，通常是这几处之一：1. DaemonSet 没有挂 runtime socket。exporter 需要 /run/containerd/containerd.sock（或 /var/run/docker.sock）以及 /var/lib/kubelet/pod-resources。升级驱动时若换了镜像版本、顺带更新了 YAML，很容易把 hostPath 挂载漏掉——此时指标还能出（dcmi 能读卡），只是容器维度全空，表现就是「能看利用率，看不到哪个 pod 在用」。2. 容器模式参数与运行时类型不匹配。老版本靠 -container-mode=true 自动探测，新版本多数要求显式给 --container-runtime-endpoint=unix:///run/containerd/containerd.sock。cgroup v2 环境还要确认 exporter 版本支持 cgv2 路径解析（/sys/fs/cgroup/kubepods.slice/...），老版本按 v1 路径找会静默返回空。3. ascend-docker-runtime / device-plugin 版本要一起动。25.x 驱动配老 device-plugin，NPU 能分配但 label 不上报，exporter 反查时拿不到 pod 归属。三者（driver、device-plugin、npu-exporter）建议按官方配套矩阵一次性对齐。排查顺序：先看 exporter 日志有没有 failed to get pod、CRI 相关报错 → 进容器 ls -l /run/containerd/containerd.sock 确认挂载 → 用 crictl pods 验证 CRI 可达 → 再对比 /var/lib/kubelet/pod-resources 里有没有 NPU 分配记录。三步能定位到具体缺哪一段。补一句：容器元信息也可以不依赖 exporter 反查——用 kube-state-metrics 加 device-plugin 上报的 huawei.com/Ascend910 资源标签做 join，比让 exporter 猜 pod 更稳。

结论先行：选型先定位瓶颈资源，再按「基准压测 → 观察利用率 → 调整」的闭环定规格；一次买到位的成本通常比「小规格起步 + 升配一次」更高。1. 按瓶颈选类型，别看总核数：Web/应用服务用通用计算型（vCPU:内存 1:2 或 1:4）；编译、转码、加解密、CI runner 这类持续吃满 CPU 的选计算型（1:1~1:2）；Redis、MySQL、ES 这类内存驻留型选内存优化型（1:8）；GPU 推理/训练单独看显存而非 CPU。选型的第一个动作是把业务的资源画像写出来：峰值 QPS、平均响应时间、常驻内存（含 JVM 堆外）、磁盘 IOPS、出口带宽，缺哪一项都会在压测时暴露。2. 注意「突发性能型」的 CPU 积分机制：入门型实例靠积分换 CPU 时间，积分耗尽后会限速到基准性能的百分之几十，表现为「白天正常、晚上突然全站变慢」，用 CES 看 CPU 积分余额 指标就能确认。长期跑稳定负载的业务不要用突发型。3. 变慢先查非 CPU 项：磁盘类型（普通 IO / 高 IO / 超高 IO 的 IOPS 与吞吐差一个量级，MySQL 落在普通 IO 上再大的规格也慢）、公网带宽（按带宽计费与按流量计费在峰值场景成本差很大）、以及连接数上限（ELB 与后端 keepalive 配置）。把「慢」直接归因于 CPU 不够是最常见的误判。4. 计费与变更：规格未定时用按需，稳定运行 1~2 个月后按实际利用率比较包年包月与节省计划；升配多数需要先关机，降配同样，所以变更窗口要提前排进发布计划。预留实例/节省计划适合基线负载，突发部分仍用按需。5. 观测闭环：上线后至少看四周 CES 的 CPU 使用率（取 P95 而不是峰值均值）、内存使用率、磁盘读写时延、网络出入带宽。持续 >70% 再升配，长期 20% 再降配，中间区间不要动——频繁变规格带来的停机与配置漂移，成本往往高于那点差价。边界：一次性任务（迁移、批量计算、实验）用竞价实例或函数计算更省；纯演示和教学场景先用开发者空间/KooLabs 环境跑通流程，确认要长期在线再买 ECS。

结论先行：同区域、三张 VPC、网段不重叠，用 VPC 对等连接最省；但要做「网状互通」就必须建 3 条对等连接并逐张路由表验证，不能靠一条链路中转。1. 连通性拓扑：对等连接不传递。生产—测试、生产—办公、测试—办公三条连接缺一不可，且是双向的：每条连接要在两侧 VPC 的路由表各加一条目的网段指向「对等连接」的路由。最常见的故障是只加了本侧路由——A 侧能 ping 通 B、B 侧 ping 不通 A，就是 B 侧路由表没加。验证方法：在两侧各找一台 ECS，用 traceroute -n 看到下一跳是否是对等连接网段，再配合 VPC 流日志（开启后看 ACCEPT/REJECT 记录）确认包到底有没有被安全组丢。2. 安全组与网络 ACL：对等连接放行的是 VPC 之间，主机之间的放行仍然由安全组决定。跨 VPC 访问时源 IP 是对方 VPC 的私网地址，安全组规则要按「对方网段」而不是「对等连接」来写；如果开了网络 ACL（子网级），它是有状态的、规则按序号从小到大匹配，默认最后一条 deny，容易漏。3. 什么时候该上企业路由器（ER）：VPC 数量超过 4~5 张、需要中心化汇聚、需要接专线/VPN/其他区域，或者需要集中做路由策略和带宽管理时，用 ER 把每张 VPC 挂到同一个 ER 上，拓扑从 O(n²) 降到 O(n)，路由只维护一份。三张 VPC 的小规模场景上 ER 属于过度设计，多一层要排查的跳数。4. 网段重叠：普通对等连接无法区分两个相同的私网段，建了也不通，这不是配置问题。可选的处置是：重新规划地址（最稳）、或在重叠的一侧做 SNAT 转换（NAT 网关把源地址改成一个不重叠的地址，代价是丢失源 IP、按连接数计费），或引入支持地址转换的中转 VPC。别把「建了对等连接」当成已打通，验收标准永远是端到端 ping 加业务端口 telnet 都通。5. 落地顺序建议：先出网段规划表（三张 VPC 的 CIDR 与子网），再建连接、再补两侧路由、再按对方网段放安全组，最后逐对验收。跨账号场景还要双方分别发起/接受连接，路由和安全组同样两边都要配。

RAG 降幻觉的机制要说准确：它不提升模型能力，只是把「参数里的记忆」换成「上下文里的证据」。幻觉分两类——知识型（模型不知道硬编）和推理型（逻辑跑偏）。RAG 只对第一类有效，且必须满足两个前提：召回内容真的相关、模型愿意照材料说话。关键在召回质量，不在模型大小。切块策略决定召回粒度：块太大噪声进上下文，模型被无关内容带偏；块太小语义不完整，答案缺前提。按结构切（标题/段落/表格）比按固定字数切稳定得多，再加一层 rerank 把候选压小，比单纯调大 k 有效。提示词要写成「契约」。除了「只依据资料回答」，还要明确：找不到依据时输出固定话术（便于程序判定）、必须给引用编号、多条资料冲突时并列而不是自行融合。冲突场景最能暴露幻觉——模型倾向于编一个「综合结论」出来。三类常见失效：① 检索到了但内容过期，反而比模型参数更旧；② 相似度高的干扰块（同产品不同版本手册）；③ 问题需要跨文档聚合，单块无法回答，模型就自己补。对应解法分别是时间戳过滤、rerank + 元数据过滤、查询改写/多跳检索。可验证性才是落地点。答案带引用、前端能点开原文，用户一秒判断真假；后台抽检「引用是否真的支持该结论」，把不支持的比例当质量指标。没有这套闭环，RAG 只是把「一本正经胡说」换成「带出处的一本正经胡说」。

结论：缩容在技术实现上不是「删节点」而是「重分布」，云上能做是因为管控面把重分布、校验、回滚做成了一次自动化编排；线下 8.2.1 没有这套编排，所以产品层面把入口关掉，只保留扩容。原因拆开看：1）数据面代价不对称。扩容是把新 DN 加进来、把部分分片搬过去，搬完新节点立刻可用；缩容要先把待删节点上的分片搬走，再改 pgxc_class 里的分片映射，任何一步中断都会出现「表定义说数据在某节点、实际数据不在」的不可用状态，必须人工介入。风险等级完全不同，产品不愿把它做成一个按钮。2）分片映射与元数据要全局一致。hash 分布表的 bucket 数、复制表的副本位置、CN 的元数据缓存都要同步刷新，线下多套集群版本混杂时极易做出半成品状态。3）云上有资源池兜底。云上缩容背后有快照、原集群保留 N 小时、失败自动回滚；线下物理机删了就没了，没有回滚面。可行的替代路径（按推荐度）：逻辑集群（elastic cluster）：把多余节点划到逻辑集群但不承载主业务表，物理还在、不占业务资源，需要时再并回来。线下这是最省事的一条。新建小集群 + 逻辑迁移：gs_dump 按 schema/表并行导出（-F c -j 8），新集群建好后 gs_restore 并行导入，最后切连接串。数据量 TB 级、能接受小时级停写窗口时最稳。表级腾挪：冷数据表改「只读 + 归档到 OBS 外表」，减少活跃分片占用，效果上等价于缩容，且不动集群拓扑。不建议的做法：手工 DROP NODE 或直接把机器下线。分片映射不会自动收敛，后续 gs_check 会报一堆 inconsistent，恢复成本远高于重建集群。至于哪个版本支持，要以服务侧的版本路标为准，社区里流传的版本号不可信；如果现在就要减机器，走上面第二条，别等版本。

结论：不是。全量 build 只在「集群拓扑变化」（加减 DN、重分布、集群搬迁）时才必须做；单纯升级 OS 属于「节点替换」场景，做的是按节点补齐该节点承载的分片，不是整个集群重建。先把两件事分清楚，很多人卡在这里：1）gs_replace（节点替换）：OS 升级的标准路径。逐个节点停机重装/替换 OS，重启后走 --replace-state 流程，DWS 会给该节点上的 DN 补齐副本、重建本地数据文件并重新加入集群，其它节点的数据不动。日志里是「节点替换完成、数据重建完成」，耗时与单节点数据量相关，不是全集群扫描。2）gs_expansion / redistribute（扩容重分布）：DN 数量或分片映射变了才需要，这时才出现「全量 build」。升级 OS 不改分片映射，所以理论上不该走这条路。如果现场被要求「升一台 + 全量 build」，通常是三种情况之一，建议先确认再动手：① 该集群本来就少于两副本，或某些表副本缺失，替换后只能靠重建恢复；② 节点重装把 /srv/BigData/mppdb 下的磁盘/RAID 布局改了，DWS 认不出原有数据文件，只能重建；③ 用的是「卸载重装 + 逻辑恢复」的老方案，那本质是重装而不是升级。更稳的落地顺序（线上业务）：先在备节点或从集群上演练一个节点，量出单节点重建耗时，再据此承诺停机窗口；每次只动一个节点，确认 pg_stat_replication 里该 DN 的备机全是 Streaming 状态再动下一个；替换期间该分片读会降级，先确认业务能不能承受；全程锁定业务侧 DDL，避免替换过程中分布键变更导致重建错位；如果停机窗口压不进去，走「新建同版本集群 + gs_dump/gs_restore（或 DRS）逻辑迁移 + 连接串切换」，代价变成迁移数据量，量级可预估。边界：不同补丁包的 OS 白名单不一样，升级前务必用服务侧的版本配套矩阵核对 OS 版本与内核参数（vm.overcommit_memory、透明大页、文件句柄数），这些不匹配的典型表现是「替换后 DN 起不来」而不是数据问题。至于 8.2.1 各补丁之间是走 gs_upgrade 还是服务侧封装的升级向导，差异不小，开工前发个工单确认当前补丁包的支持路径最稳。

一句话区分：蓝绿是「整体切换」，两套完整环境，流量一次性从蓝切到绿；金丝雀是「按比例放量」，新版本先接 1%~5% 流量，看指标再逐步放大。蓝绿适合：版本之间有不可兼容的变更（数据库 schema、协议、外部依赖）、需要秒级回滚、团队没有成熟的指标灰度体系、发布窗口明确。代价是资源要双份，并且切换瞬间所有流量都压到新版本，一旦有问题影响面 100%，所以切换前必须在绿环境跑完整的验证。金丝雀适合：流量足够大（不然 1% 就是几十个请求，没统计意义）、有完善的可观测性（错误率、P99、业务指标）、变更风险集中在性能或个别场景。它能在真实流量下暴露问题，影响面可控；代价是需要流量切分能力（Service Mesh / Ingress 权重 / APIG 灰度）、需要自动化决策（人工盯盘很容易看漏），以及新旧版本要能同时在线，数据库和缓存必须向后兼容。实践里常见的是组合使用：先金丝雀 5% 观察 30 分钟，指标正常再逐步到 100%，同时保留蓝环境一段时间做快速回滚；重大变更（比如换存储引擎）才用完整蓝绿。判断标准可以简化成三条：能不能同时跑两个版本（不能→蓝绿）、有没有足够流量和指标（没有→蓝绿人工验证）、出问题能容忍多大影响面（极小→金丝雀）。两个容易忽略的前置条件：一是回滚预案要包括数据回滚（新版本写了新字段，回滚后旧版本可能读不了）；二是灰度期间配置、缓存 key、消息队列的消费者也要一起灰度，否则只有 Web 层灰度、后台任务全量跑新逻辑，等于没灰度。

核心区别是连接语义：长轮询是「一问一答」的 HTTP 循环，WebSocket 是一次握手后升级成全双工长连接。HTTP 长轮询：客户端发请求，服务端 hold 住不返回，直到有数据或超时才响应，客户端收到后立刻再发下一个请求。优点是实现简单、能穿透几乎全部代理和网关、天然复用现有鉴权；缺点是每条消息都要经历一次完整的 HTTP 请求（头部几百字节起步）、消息延迟取决于「服务端有数据→写回→客户端重连」的往返、连接频繁重建对网关和负载均衡压力大。WebSocket：握手时通过 Upgrade: websocket 切换到 ws/wss 协议，之后双方随时可以推帧，帧头只有 2~14 字节，延迟是单向的。代价是需要网关/负载均衡支持协议升级和长连接（Nginx 要配 proxy_set_header Upgrade、proxy_read_timeout），连接数受文件句柄和内存限制，还要自己做心跳、断线重连、消息序号与补发。选型上：消息频率低（分钟级）、只需要服务端单向通知 → 长轮询或 SSE 就够，别上 WebSocket；双向高频（IM、协同编辑、行情、游戏、在线客服）→ WebSocket；只需要服务端推、不需要客户端上行 → SSE（HTTP/1.1 流式）性价比最高，能自动重连。工程上最容易翻车的是 WebSocket 的重连与消息补偿：网络抖动后连接断了但业务不知道，必须有心跳（ping/pong）+ 客户端指数退避重连 + 服务端按序号补发；长轮询反而因为「每次都是新请求」天然自带重试语义。华为云上如果用 ELB/APIG 承接长连接，要确认空闲超时和最大连接数配额。