dzs-price-collector 增量质检报告（v1.0.107）

• 项目：dzs/dzs-price-collector
• 分支：v1.0.107
• 对比区间：base 76611a2f65039c6da174e89ae35df07100f7a804（= v1.0.106）→ head abe48b17b7acb5b7030bb21607ef4ca46a2a80f8
• 变更规模：4 个文件，全部为基础设施与文档（CI 流水线、Dockerfile、AGENTS.md、审计日志），无一行 Go / JS 业务代码改动
• 质检问题对比（codescan_issues_diff，真实数据）：修复 0 条 / 新增 0 条（两版本质量无差异）
• 当前基线（head）：质量问题共 777 条，其中 Critical 0 / High 6（弱加密 md5 ×4、不可达代码 ×2，均位于本区间未改动的文件中）/ 其余为 Low·Medium 可维护性项

说明：本区间代码静态质检无任何增删（工具口径），因此本报告的重点是手工审读基础设施改动后识别出的风险，其严重度由人工判定，并在文中给出证据与置信度。

---

一、变更面

改动意图（据文件头注释）：对齐《持续集成.md》§2.1「宿主编译 + 镜像只打包」，把原来「容器内编译」的形态改为「runner 上编译、Dockerfile 只 COPY」，以缩短构建耗时并修复 tag→构建→部署链路。

---

二、逐项分析

2.1 CI 流水线（build.yml）

• 结构：build-push（串行：gofmt → 脚本语法 → 质量门 vet+test → 宿主编译 → buildx 打包推送）→ deploy（needs: [build-push]），并保留 concurrency 组防止并发部署回退。
• 编译与版本注入（Build release binaries (host)）： CGO_ENABLED=0 GOOS=linux go build -trimpath -ldflags="-s -w -X main.BuildVersion=${{ gitea.ref_name }} -X main.BuildTime=$(date -u +…Z) -X main.GitCommit=${{ gitea.sha }}" -o server .，其余 4 个二进制静态编译。 已核实：main.go（第 53–57 行）确已声明 BuildVersion/BuildTime/GitCommit，-X 注入有效；internal/buildinfo 的 Info() 输出 version 字段（供 deploy 探活校验），链路自洽。
• 打包推送：docker buildx build（本地缓存 --cache-from/--cache-to type=local）→ docker tag → docker push（循环 3 次，含 tee 日志与失败回显）。
• deploy：升级接口校验 code==200 后，轮询 18×5s（最多 90s）确认容器 state=running 且 imageName 含目标镜像，取代旧版「sleep + 单次检查」的假绿形态；末尾保留可选真实探活 + 版本号比对。

2.2 Dockerfile（构建契约变更）

• 移除 builder 段与 --build-arg；COPY server ./server 等改为直接拷贝宿主产物。
• 已核实：.dockerignore 未排除根目录的 server/importharvest/coalbackfill/metricimport/healthcheck（仅排除 bin/、build/、scripts/、tests/、*.md 等），与 Dockerfile 注释「已核对 .dockerignore」一致，COPY 不会落空。

2.3 文档

• AGENTS.md 与审计日志 A-34 忠实记录了 v1.0.106 的发版路径、证据路径、未做项与回滚方式，属档案更新，不引入行为变化。

---

三、风险清单（手工审读结论）

R1【高】tag 流水线的根因未修，v* 仍会在「脚本语法」步失败，deploy 继续被跳过

• 证据链：
  1. 本区间 diff 未触碰 脚本语法（bash -n / node --check） 步骤体（该步骤在两个 hunk 之间，无任何改动）；
  2. 该步仍以 set -e 串行执行 node browserworker/credentials.test.mjs、node browserworker/ui-harvest.test.mjs、bash browserworker/trusted-browser.test.sh；
  3. 审计日志 A-34 明确记载：CI 运行 1351（v1.0.106，sha 76611a2）失败于该步，复现出「与本次改动无关的 3 个历史遗留失败」（credentials.test.mjs 9 过/1 败、ui-harvest.test.mjs ERR_MODULE_NOT_FOUND、trusted-browser.test.sh 6 过/3 败），且 v1.0.100 的 run 1184 同样失败于该步。
• 推论：本次重构只改「编译/打包形态」，没有消除触发失败的那一步，因此打 tag 仍会在同一步中断，build-push 失败 → needs 链使 deploy skipped，tag 路依旧不通（与本次「让 tag 路可用」的目标不符，也是本仓反复警惕的「假绿/假绿修复」形态）。
• 建议（择一或组合）：
  • 真正修复 3 个 Linux 兼容失败（首选，A-34 已登记为独立欠账，应与本改动同批闭环）；
  • 或把无法在 runner 稳定通过的用例显式降级（continue-on-error / 白名单并打印 ::warning::），明确标注「已跳过」，避免整条 tag 路被 3 个历史失败长期堵死；
  • 无论哪种，都应在 runner 上以 v* tag 实跑一次验证「全绿 = 升级完成」不再落空。

R2【中】Dockerfile 构建契约变更，使既有手动/回退构建路径失效

• 证据：新 Dockerfile 无 builder 段、无 ARG BUILD_VERSION/…，改为依赖构建上下文根的宿主编译产物；而 A-34 / AGENTS 记录的唯一可用回退路径是 docker build --build-arg BUILD_VERSION=v1.0.106 --build-arg BUILD_TIME=… --build-arg GIT_COMMIT=… -t … .（不含宿主编译步骤）。
• 后果：该命令会以 COPY failed: file not found: server 失败；即便侥幸绕过，--build-arg 也被静默忽略，镜像里版本号退回 dev（正是 main.go 注释里记过的「链接器静默忽略 -X → 无人知道线上版本」同类事故）。鉴于 R1 使 tag 路仍不可用，实际生产大概率仍走手动路 ⇒ 该路径被本次改动直接打断。
• 建议：同步更新文档中的手动构建步骤（先 go build 出根目录产物，再 docker build），或提供 Makefile/release.sh 把「宿主编译 + 打包」固化，并纳入回退演练。

R3【中】docker buildx build 的产物落地与缓存后端对 runner 的默认 builder 类型敏感

• 证据：改动用 docker buildx build（无 --load、无 --push）后接 docker tag/push，并启用 --cache-to type=local。
  • 若 runner 当前 builder 为 docker-container 驱动：镜像默认只进 buildx 内部存储，不加 --load 则 docker images 中不存在 ⇒ 随后 docker tag/push 报 No such image；
  • 而 type=local 缓存后端在默认 docker 驱动下并不被支持。二者取向相反，文件内未固定 builder，正确性依赖 runner 现场配置。
• 置信度：中（无法从代码判定 runner 的 docker buildx ls 默认 builder）。
• 建议：显式加 --load（或直接用 --push 让 buildx 完成推送）；在 CI 内固定 docker buildx create --use --driver docker-container --name ci；并在 runner 上确认默认 builder 类型后再固化。

R4【低】deploy「升级容器」步丢失 shell: bash 与 set -euo pipefail

• 证据：旧版该步含 shell: bash + set -euo pipefail；新版删除二者，仅靠 runner 默认 shell（多数实现为 bash -e -o pipefail，但 -u 通常不在默认内）。
• 后果：核心失败路径仍有显式 exit 1，风险有限；但 -u 的缺失意味着 ONEPANEL_KEY 等未定义时不会快速失败，属安全网回退。
• 建议：恢复 shell: bash 与 set -euo pipefail，与旧版及本仓「不制造假绿」的口径一致。

R5【低】健康探活版本校验偏宽，存在假绿空间

• 证据：if tag and ver and tag not in str(ver): 失败 —— 当 ver 为空（版本未注入 / 字段改名）时跳过校验。
• 后果：恰好与本仓最痛点的缺陷同源（-X 注入静默失效 → 无版本信息），而校验恰好对「无版本」放行，无法兜住该类回归。
• 建议：ver 为空时判为失败（或至少 ::warning:: 并计入校验结果），确认版本注入真实生效。

R6【低/观察】文件头自定规则「run: | 块内 python 必须单行」未在该文件其它步贯彻

• 证据：文件头新增注释称「多行缩进导致 Gitea YAML 解析失败，tag 不触发」，本次据此把 deploy 的 python 压成单行；但「探活并校验版本」步仍内嵌多行 python（printf '%s' "$BODY" | python3 -c "…多行…"）。
• 判断：要么该规则被夸大（多行并非必然失败），要么该步仍是潜在 YAML 雷。建议统一为单行，或明确该步可安全多行的依据，避免规则自相矛盾。

R7【信息】已核对、判定无问题的点

• .dockerignore 未排除根目录二进制名，与 Dockerfile 注释一致（COPY 不会落空）。
• main.go 已声明 BuildVersion/BuildTime/GitCommit；buildinfo.Info() 输出 version，与 deploy 探活取值一致；go.mod go 1.25.0 与 go-version-file: go.mod 兼容。
• 质量门 vet + test -race 合并合理；单 job 串行减少重复编译，符合注释中的耗时实测口径。
• push 重试逻辑（RC=1 后循环至成功）失败即 exit RC，语义正确；[ "$i" -lt 3 ] && sleep 10 在 i=3 返回非零但处于 set +e 上下文，无害（可读性可优化）。
• Cache docker buildkit layers 的 key 仅含 Dockerfile+go.sum，不含源码；对「层失效」影响有限（buildx 本地缓存按文件内容失效），仅作提示。

---

四、质检问题对比（必须项，真实数据）

数据来源：codescan_issues_diff(project=dzs/dzs-price-collector, branch=v1.0.107, base=76611a2, head=abe48b17)。 因本区间仅改动 CI/Dockerfile/文档，未触达被质检的 Go/JS 源码，故增删为 0 属预期。

当前 head 基线分布：总计 777 条（Critical 0 / High 6 / 其余 Low·Medium）。High 6 条为 cmd/test_mysteel_price/main.go、internal/scraper/mysteel/openapi.go、internal/scraper/mysteel_price/client.go、internal/utils/dedup.go 的 md5 弱算法，以及 cmd/importharvest/main_test.go、internal/metricimport/import.go 的不可达代码 —— 均不在本区间改动范围内，为既有欠账。

---

五、验收建议

1. 以 v* tag 实跑一次 CI（关键）：验证 R1 —— 若仍在「脚本语法」步失败，则本次「恢复 tag 路」的目标未达成，应连同 3 个 Linux 失败一并闭环。
2. 演练回退构建路径：按 R2 更新文档后再实跑一次 docker build（先宿主编译），确认版本号非 dev。
3. 确认 runner buildx 形态：docker buildx ls 复核 R3，并按需加 --load / 固定 builder。
4. 恢复 deploy 步的 set -euo pipefail（R4）、收紧探活版本校验（R5）。
5. 统一 python 单行规则（R6），避免自定规则与实现自相矛盾。

---

附：变更文件清单

.gitea/workflows/build.yml
AGENTS.md
Dockerfile
docs/变更审计日志-2026-09.md