确定性构建：让交付物可被第三方验证

可复现构建是一种信任机制

当交付物是纯静态产物时，「我这边构建通过了」不构成验证。更可靠的形态是：任何人在相同输入下都能得到逐字节一致的产物，并用哈希确认。这对技术品牌尤其重要——能被第三方独立验证的工程，才谈得上工程可信。

三个必须固定的输入

1. 依赖树：使用锁文件固定 patch 版本，CI 用 npm ci 而非 npm install。
2. 运行时：固定 Node 大版本并记录实际版本号，避免不同环境下的解析差异。
3. 构建输入：内容文件、配置、环境变量清单化，禁止读取未登记的隐式状态。

node:        22                    # 示例内容 · 需核实
lockfile:    package-lock.json
install:     npm ci
build:       npm run build
entry:       src/** + content/**
output:      dist/

产物校验清单

构建完成后，除了「成功退出」，还应自动断言产物形态：页面是否齐全、元信息是否唯一、是否混入未登记的资源请求、是否存在客户端脚本。这类检查成本很低，却能挡住绝大多数「构建成功但交付不对」的情况。

检查项	断言方式	失败后果
页面齐全	路径清单比对	阻断发布
元信息唯一	每页 title / canonical 各一	阻断发布
外部请求	产物中出现第三方域名	阻断发布
客户端脚本	产物中出现脚本标签	阻断发布

回滚也应当是确定性的

静态托管最大的优势是回滚简单：保留不可变的历史产物，一键切回上一版，无需处理数据库或会话状态。前提是每次构建的产物可标识、可归档——这也是把哈希写进发布记录的原因。

小结

确定性构建不解决业务正确性，它解决「交付的是不是我们以为的那份东西」。本文只讨论工程流程，文中版本与路径均为示意。

示例内容 · 需核实。