增量分析报告：dzs/dzs-price-collector

• 对比区间：76611a2f65039c6da174e89ae35df07100f7a804（base，v1.0.106 tag） → abe48b17b7acb5b7030bb21607ef4ca46a2a80f8（head，v1.0.107）
• 分支：v1.0.107
• 变更性质：纯 CI/CD 流水线重构 + 文档记录。本次未触碰任何 Go / Node 业务逻辑（采集器、调度器、导入器、DB 结构均无改动）。

---

一、变更清单（全量 4 个文件）

结论：这是一次基础设施改动，逻辑上等价于“把镜像内的 Go 编译挪到 CI runner 上执行”，运行镜像内容（二进制）不变。

---

二、质量问题对比（工具真实数据）

• codescan.issues_diff(base → head)：修复 0 条 / 新增 0 条（两版本质量无差异）。
• codescan.quality_list(head)：共 777 条既有问题，全部集中在 browserworker/*.mjs 脚本（高耦合 / 圈复杂度 / 嵌套深度 / 行长 / 重复块等），与本次改动无关，本次未新增也未修复。

注：本次改动落在 YAML / Dockerfile / Markdown，不属于代码质量引擎的静态分析面，因此新增问题为 0 属预期。

---

三、关键改动逐项说明

1. .gitea/workflows/build.yml

• 单 job 串行：原来 build-check（go test/build）与 docker（build+push）各 checkout/装依赖一次，编译跑 2 遍；现合并为 build-push，注释给出实测收益（2:39 → 3:56~5:14 的反向论证，说明“拆两 job 反而更慢”）——设计合理。
• 宿主编译步骤 Build release binaries (host)：在 runner 上执行 5 条 CGO_ENABLED=0 GOOS=linux go build -trimpath -ldflags="-s -w ..."，产出 server/importharvest/coalbackfill/metricimport/healthcheck 到仓库根，再交给 Dockerfile COPY。版本注入 -X main.BuildVersion=${{ gitea.ref_name }} … 与代码一致（已核 main.go 声明了 BuildVersion/BuildTime/GitCommit 三个符号，见下）。
• docker buildx build --cache-from/--cache-to type=local + push 3 次重试：失败会打印完整 build log 并 exit $RC，不再假绿。
• deploy 重构：upgrade 后轮询 containers/search（18×5s=90s）直到容器 running 且 imageName 命中本次镜像，修复了“发完请求就算成功”的假绿；末段探活校验 version 与 tag 一致。
• 移除项：go vet、go build ./...、go mod download、-race 独立步——前两者并入 Quality gate (vet + test)， 仍在 test 中保留。

2. Dockerfile

• 去掉 FROM golang:1.25-alpine AS builder 整段与 --build-arg BUILD_VERSION/BUILD_TIME/GIT_COMMIT，直接 COPY server ./server 等 5 个宿主产物。
• 运行镜像 mcr.microsoft.com/playwright:v1.62.1-noble 保留；entrypoint.sh、HEALTHCHECK /api/v1/health、/app/data 挂载点均未变。

3. 集成一致性核验（已通过）

• main.go 声明 var (BuildVersion = "dev"; BuildTime; GitCommit) 并 buildinfo.Set(...)，buildinfo.Info() 输出键为 version；/api/v1/health 经 HealthCheck 把 buildinfo.Info() 合并进 Data → 响应为 {success, message, data:{status,version,...}}。
• CI 探活脚本 data = d.get('data') if isinstance(d.get('data'),dict) else d; ver = data.get('version') or data.get('build_version') → 能正确取到 version，tag 匹配校验成立。✅

---

四、风险与建议（人工审查，工具未覆盖 CI 语义）

严重度为本报告的人工判定，非引擎评级。

R1【高｜本次改动未闭环】tag 自动发布路“真正的拦路石”未被触碰

• 证据：AGENTS.md / 审计 A-34 明确记录 —— tag v1.0.106 的 CI run 1351 失败在 脚本语法（bash -n / node --check） 步，归因于 3 个 Linux 环境特有的历史遗留失败（credentials.test.mjs 9 通过/1 失败、ui-harvest.test.mjs ERR_MODULE_NOT_FOUND、trusted-browser.test.sh 6 通过/3 失败），并与 v1.0.100（run 1184）同点失败互证。
• 现状：本次重构未改动该步（仍逐一执行 credentials.test.mjs / ui-harvest.test.mjs / trusted-browser.test.sh）。只要 runner 上有 node（cxy-ubuntu 有），这 3 个失败会让整个 job 在“质量门之前的脚本语法步”即失败 → 镜像不构建 → deploy 被 skip。
• 影响：本次重构（宿主编译 + buildx）在实际 tag 触发时可能根本跑不到，“push tag 即自动发布”的目标未达。
• 建议：发版前先修/隔离这 3 个测试（修根因，或明确标记为 known-failing 并对 Linux 差异做条件跳过并留 warning），否则应与 A-34 一样继续走手动构建 + 1Panel upgrade，并在文档中显式声明 tag 路暂不可用。

R2【中｜回退/手工路径断裂 + 文档漂移】

• 新 Dockerfile 依赖构建上下文里已存在的根目录二进制，且不再消费 --build-arg。而 AGENTS.md/审计 A-34 记录的手动发版命令仍是 docker build --build-arg BUILD_VERSION=... -t … . —— 该命令现在会以 COPY failed: file not found: server（--build-arg 被静默忽略）失败。
• docs/CI_CD_SETUP.md 未在本次同步：§1 仍描述旧的三 job 结构（go test && go build、Docker Build & Push、go build ./...），§2 仍写“三 job 全绿 = 升级完成”“curl -f”，与 head 的 2 job（build-push + deploy）、curl -s+JSON code 校验、以及“宿主编译”形态均不符。
• 建议：同步更新 docs/CI_CD_SETUP.md（§1/§2/§6）与 AGENTS/审计中的手动构建命令（补一步宿主编译或改走 docker buildx build 且先产出二进制），避免下一位维护者照旧文档操作即翻车。

R3【中｜buildx 行为依赖 runner 配置】

• docker buildx build … -t "$IMAGE:$TAG" . 未带 --load（也未 --push）。若 runner 的 buildx 默认 builder 是 docker-container 驱动，镜像只进 BuildKit 缓存、不在本地 docker images，随后的 docker tag / docker push 会以 “No such image” 失败。
• 同时 --cache-to type=local,dest=… 的可用性依驱动而定；一旦 cache 导出报错，该错误未被容错包裹（set +e 只对 push 重试生效，但 build 命令本身 RC=${PIPESTATUS[0]} 会非零）→ 直接判定构建失败。
• 建议：确认 runner 默认 builder 驱动为 docker（默认会 load），或显式加 --load；对 --cache-to 的兼容性做一次真机验证。

R4【低】缓存落盘时序与缓存键

• actions/cache 步骤安排在 Build & Push 之前：若该 action 在步骤内（而非 post-job）保存，则 build 步骤写入 /tmp/docker-cache 的新缓存永远不会被保存（每次回到同一初始缓存）。
• 缓存 key 为 hashFiles('Dockerfile','go.sum')，但新形态下 Go 编译已移到宿主，docker 层不再依赖 go.sum，该键维度意义不大。
• 另：COPY server（含构建时间注入的字节会变）使最后一层每次必然失效，buildx 本地缓存收益有限。
• 建议：核对 actions/cache 的保存时机；缓存键可简化为仅 Dockerfile（或去掉）。

R5【低｜信息】新增边界与陈旧注释

• 宿主产物落在仓库根，.dockerignore 未排除这些文件名（已核，符合 COPY 需要）；但副作用是：若本地存在陈旧/异架构的 server 等产物，会被原样打进镜像。CI 为干净 checkout，无此问题。
• 陈旧注释（本次未同步）：main.go 顶部仍写“由 Dockerfile 的 -X … 注入”、buildinfo 注释同；AGENTS.md v1.0.106 条目仍说“Dockerfile 一直在传 -X”。如今版本注入已迁至 CI go build -ldflags，建议顺手更新。
• deploy 由 curl -f 改为 curl -s + JSON code 解析：功能等价（HTTP 错误/非 JSON 体由 || {…; exit 1;} 兜住），仅属行为微调，无明显缺陷。

---

五、结论

• 变更面：CI/CD 形态对齐（宿主编译 + 镜像只打包），Dockerfile 去 builder 段，配套文档记录；无业务代码改动，无新增/修复的静态质量问题（工具 0/0）。
• 正向价值：单 job 串行避免重复编译；deploy 由“发请求即算成功”升级为“轮询到镜像真正切换”；push 失败自动重试并完整落错日志；版本注入链（main.BuildVersion ↔ buildinfo.Info().version ↔ /health ↔ CI 探活）已核验自洽。
• 必须处理：R1 —— 本次没有解决 tag 路失败的真实原因（3 个 Linux 测试），push tag 仍可能在该步失败，“自动发布”目标存疑；R2 —— 手动构建回退路径与 docs/CI_CD_SETUP.md 均未同步，照旧文档操作会直接失败。
• 上线前验证建议：① 推送一个 tag 观察 脚本语法 步是否通过；② 在本机确认 docker buildx 默认驱动能 load 镜像且 type=local 缓存可用；③ 同步 docs/CI_CD_SETUP.md。