CI 是否该覆盖 Windows？（附两个只在 Windows 暴露的可复现缺陷）

[xiaojian94xiaojian]

背景

.github/workflows/check.yml 的两个 job 都是 runs-on: ubuntu-latest。也就是说 Windows 上完全不跑测试，而已有的几个 Windows 缺陷因此一直没被发现 —— 它们只在本地开发者的机器上暴露。

具体例子（都是真实存在、已修的）

① tests/architecture.test.ts 在 Windows 上 2/5 失败，且全是假阳性（PR #79）

out.push({ file: path.relative(ROOT, full) });   // Windows: "packages\backend\src\..."

规则拿它和 posix 串比较（"publication/"、"providers/receipts.ts"）→ 归属匹配全失败，把 53 条合规写入报成违规。修好 ① 之后仍红，因为 path.relative 在 Windows 上不把 / 当分隔符 —— 两个 bug 叠加。

后果不只是"测试红"：这个架构守卫在 Windows 上等于失效，而且 53 条噪音把真问题淹没了。

② tests/media-performance.test.ts 在干净库上必然失败（PR #80）

Error: Queue media.prepare does not exist

队列首次使用时才创建，而 deleteAllJobs 不创建队列。

这两个都是与平台相关的可复现故障，Linux CI 结构上就看不见它们。

建议

给 check job 加一个 Windows 维度，让平台相关的问题在评审阶段就暴露：

  check:
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-latest, windows-latest]
    runs-on: ${{ matrix.os }}

需要一并处理的几处：

• PostgreSQL backup tools 那步只适用于 Linux（apt + pgdg 源）；Windows runner 自带 PostgreSQL，但版本可能不是 17，需要换一种装法或在该步加 if: runner.os == 'Linux'，并在 Windows 上跳过 backup-files 相关用例。
• PostgreSQL service container 在 Windows runner 上不可用（service container 只在 Linux 上支持），需要改成在 Windows 上本地起一个 postgres。
• docker job 保持 Linux（Windows runner 没有 Docker）。

上面两点会让改动比看上去大。如果代价不合适，还有一个更轻的选项：只加一个小的 Windows job，跑那些已确认与平台相关的文件（tests/architecture.test.ts 这类纯静态检查、路径拼装相关的用例），成本低很多，也能挡住这次这两个问题。

想听你们的判断

我可以直接开 PR，但要不要让 CI 覆盖 Windows、以及愿意为此付出多少 CI 时间，取决于你们对 Windows 本地开发的支持程度 —— 这个我不该替你们定。你们倾向哪种（完整矩阵 / 只跑平台相关用例 / 维持现状）？我按结论来做。

---

补一句证据：修完 #79、#80 之后，整套测试在 Linux 容器（Node 24 + pg_dump 17）里是 574 pass / 0 fail；上面两个失败只在 Windows 上出现。

[KKKKhazix]

感谢整理！结论是暂不加 Windows CI：后端测试需要 PostgreSQL 17 和对应版本的 pg_dump，GitHub 托管的 Windows 机器跑不了服务容器；引擎在 Linux 上开发后导出，Windows 问题到开源仓库才暴露，来回成本高。部署文档 已写明：不用 Docker 时支持 Linux 和 macOS，Windows 请用 WSL2 或 Docker。

你提的两个问题：#79 已修（统一路径）；#80 在 #89 之后已不存在。欢迎继续提小而清楚的 Windows 修复。