前两篇文章分别记录了这轮 A Tour of Go 简体中文重译的两个阶段。
第一阶段，是利用 ChatGPT + GitHub 完成全部 103 个正式课程页面的整页重译，并通过现有的 restore、validator 和 retry 流程，把 ChatGPT 译文纳入原有工程体系。
第二阶段，则继续完成全部 103 页的独立语义质量审核、revision 和 canonical promotion。最终结果为：
A = 103
B/C/D = 0结合整轮审核，我对当前 zh-CN 的内部综合质量评价，也从原来的约 94 分提高到了约 98 分。
但到了这里，其实还有最后一个问题没有回答：
仓库中的 canonical 已经换成新的 ChatGPT 译文，是否就意味着用户打开生产网站时，看到的一定也是这套新译文？
并不能直接这样推断。
因为中间还有：
production release
↓
生产部署
↓
当前运行中的 release
↓
origin
↓
EdgeOne
↓
公网响应任何一层如果仍然使用旧内容，都可能出现：
仓库已经更新，但公网用户看到的还是旧版本。
所以这一篇不再继续讨论翻译模型，也不再重复之前已经写过的 production deployment script 设计过程。
只做最后一件事：
证明这一轮 ChatGPT 103 页新译文，真的已经完整进入生产环境，并且公网返回的就是这一次正式 release 的内容。
一、先确认生产环境到底运行的是哪个 Release
正式部署结束以后，第一步不是马上打开几个浏览器页面查看。
我先确认：
/data/go-tour/current 当前究竟指向哪个 release。
20260818-zh-CN-45f4cad，包含 103 个正式课程页面和 7 个 article；systemd service 为 active，origin 与公网入口均返回 HTTP 200。当前结果：
current release :
/data/go-tour/releases/20260818-zh-CN-45f4cad对应 manifest：
locale : zh-CN
published_at : 2026-08-18T13:22:48Z
pages : 103
articles : 7
transport : http-playground-proxy
local socket : False同时：
service : active
origin HTTP : 200
public HTTP : 200这一步首先证明：
当前运行中的生产版本确实已经切换到了本轮新生成的正式 release。
而不是：
代码提交成功
但 current 仍然指向旧 release或者：
current 已切换
但 go-tour.service 没有正常运行另外还能确认：
local socket : False即正式 release 仍然采用 HTTP Playground proxy，不重新启用本地 /socket 代码执行路径。
二、首页能打开，还远远不够
如果只执行：
curl https://go-dev.shuijingwanwq.com/得到：
HTTP 200其实并不能证明 103 页课程都已经正常上线。
因此下一步直接扩大到完整公网路由验收。
核心入口：
/ 200
/tour/ 200
/tour/list 200
/robots.txt 200
/sitemap.xml 200
/tour/script.js 200正式课程路由：
Formal course routes : 103
HTTP 200 : 103
Failed : 0也就是：
103 / 103全部通过。
这一层回答的是：
新版本部署以后，有没有页面直接出现 404、500 或其他 HTTP 异常？
最终答案是：
没有。
三、该保持关闭的路径，也必须继续关闭
验收并不仅仅检查：
应该成功的 URL 是否成功还应该确认：
不应该公开的 URL 有没有因为这次 release 意外恢复最终检查：
/socket → 404
/socket/anything → 404
/_/share → 404这些结果和当前生产架构一致。
这点尤其重要，因为 A Tour of Go 上游原本存在浏览器与服务端代码执行相关能力，而我的生产环境已经改为独立 Playground 代理。
正常生产链路是：
浏览器
↓
play.go-dev.shuijingwanwq.com
↓
独立 Playground proxy不是：
浏览器
↓
主站 /socket
↓
本地代码执行所以：
/socket → 404并不是功能异常。
恰恰相反，它是这次验收中的预期结果。
四、103/103 HTTP 200 仍然不能证明内容不是旧缓存
到这一步：
103/103 HTTP 200其实仍然没有完全回答本文最重要的问题。
因为 CDN 可以出现这样的情况：
生产 origin 已经更新
↓
EdgeOne 仍然保存旧缓存
↓
用户访问仍然返回 200
↓
但拿到的是上一版内容所以单纯：
HTTP 200并不能证明“新 ChatGPT 译文已经真正到达公网”。
需要进一步比较：
origin 和 public 返回的 article 内容是否完全一致。
五、7 个 Article Endpoint 做 Exact Match
A Tour of Go 当前共有 7 个 .article：
welcome
basics
flowcontrol
moretypes
methods
generics
concurrency这 7 个 article 最终组成全部 103 个正式课程页面。
因此我分别获取：
生产 origin
http://127.0.0.1:3999/tour/lesson/<article>以及：
公网
https://go-dev.shuijingwanwq.com/tour/lesson/<article>然后对响应内容计算并比较 SHA-256。
结果如下。
结果：
welcome exact=True
basics exact=True
flowcontrol exact=True
moretypes exact=True
methods exact=True
generics exact=True
concurrency exact=True最终：
Origin/Public exact match : 7/7这一步比“访问正常”更重要。
它证明：
EdgeOne 公网返回的 7 个 article 与当前正在运行的新 production origin 完全一致。
因此不存在：
origin 已更新
但 CDN 仍然返回旧 article这种情况。
六、再用一组新旧译文 Marker 做直观确认
Exact Match 已经是很强的字节级证据。
但为了让结果更直观，我又挑了一句本轮发生变化的正式译文作为 marker。
新的 ChatGPT 版本中存在：
每个 Go 程序都是由包组成的。而上一版使用的是：
每个 Go 程序都由包构成。最终公网检查：
New ChatGPT marker : True
Old translation : False也就是说：
公网确实已经出现新的 ChatGPT 译文，而旧版对应句子已经不存在。
这一项和前面的：
7/7 exact match结合以后，基本把“是不是还在看旧缓存”这个疑问排除了。
七、页面和译文正常，还要继续验证 Run
A Tour of Go 并不是纯静态教程。
用户在右侧可以直接运行示例代码。
所以如果只检查：
课程页面正常
译文正常但：
Run 已经坏了仍然不能算完整生产验收。
因此这一次继续向真实 Playground proxy 发起一次代码执行请求。
ONLINE_RUN_OK，Format 也成功返回格式化后的代码。Run：
Run HTTP : 200
Run JSON valid : True
Run errors empty : True
ONLINE_RUN_OK : True这并不是只请求一个健康检查 URL。
而是真正提交：
package main
func main() {
println("ONLINE_RUN_OK")
}并确认返回结果中实际包含：
ONLINE_RUN_OK因此可以确认：
公网代码执行链路仍然正常。
八、Format 同样完成真实请求
随后继续测试 Format：
Format HTTP : 200
Format JSON valid : True
Format errors empty : True
ONLINE_FMT_OK : True
Formatted func : True输入故意使用没有正常格式化的代码：
package main;func main(){println("ONLINE_FMT_OK")}最终响应中确认存在规范化后的：
func main() {说明 Format 不是“接口返回了 200 但没有真正工作”。
而是已经实际完成代码格式化。
到这里：
页面
译文
Run
Format四个主要用户可见层面都已经通过真实公网验收。
九、这次为什么没有执行 EdgeOne 全站缓存刷新
这轮发布还有一个和以往稍微不同的地方。
部署完成以后，我并没有立即执行一次：
EdgeOne 全站缓存刷新。
以前遇到过 /tour/script.js 缓存旧版本的问题，所以最初我也有点担心：
新的 103 页译文会不会仍然被 EdgeOne 旧缓存挡住？
但这次最终验收已经直接证明：
Origin/Public exact match : 7/7所以如果没有发现 stale content，再执行一次全站 purge，其实没有实际必要。
随后又查看了不同 URL 的缓存响应头。
tour/script.js 已经存在较长时间的 HIT，而本轮刚访问的课程 URL Age 只有几秒，说明不同 URL 独立形成缓存状态，公网验收本身也可能完成部分 URL 的重新取源与缓存 warming。例如首页：
age: 54712
eo-cache-status: HITtour/script.js：
cache-control: max-age=604800
age: 54709
eo-cache-status: HIT但刚刚参与验收的：
/tour/basics/1只有：
age: 4
eo-cache-status: HIT而：
/tour/lesson/basics也只有：
age: 13
eo-cache-status: HIT这个现象很有意思。
它说明：
EdgeOne 并不存在一个“整个站点要么全部旧、要么全部新”的统一缓存状态。
每个 URL 都可能拥有自己的缓存生命周期。
十、低流量站点下，验收本身可能就在完成缓存 Warming
A Tour of Go 当前访问量还很低。
这意味着某个 EdgeOne 节点在部署以前，很可能根本没有提前缓存全部 103 个课程 URL。
发布完成以后进行：
103/103 公网验收本身就会访问全部课程 URL。
对于此前没有缓存的 URL，实际流程很可能变成：
第一次验收访问
↓
EdgeOne MISS
↓
回源新 production release
↓
返回新内容
↓
写入 EdgeOne cache
↓
后续再次访问变成 HIT所以在这种低流量阶段，公网验收本身可能同时承担了一部分：
cache warming。
这也能够解释为什么后来查看：
/tour/basics/1
/tour/lesson/basics时，它们已经是：
HIT但：
Age只有几秒。
十一、以后不再把“全站 Purge”作为每次发布的默认动作
这次最终形成了一个更适合当前项目的发布习惯：
Deploy
↓
Origin validation
↓
Public validation
↓
Exact-match / marker validation
↓
如果发现 stale URL
→ targeted purge
否则
→ 不主动 purge相比：
每次发布
↓
无条件刷新全站缓存这种方式更容易知道：
缓存到底有没有真的出问题。
如果不管实际情况，每次部署以后都先清缓存，那么其实很难观察 CDN 原本的行为。
而这一次恰好证明：
即使没有执行全站 purge，最终公网仍然已经完整返回新的 ChatGPT release。
所以后续我更倾向于：
先验收，发现明确 stale URL 后再做 targeted purge。
而不是把 CDN purge 当成 deployment 的固定组成部分。
十二、最终验收结果
到这里，这一次 ChatGPT zh-CN 重译的最后一层验收也完成了。
最终可以总结为：
正式 production release
20260818-zh-CN-45f4cad
↓
service active
origin HTTP 200
public HTTP 200
↓
核心入口全部 200
↓
103/103 正式课程路由 HTTP 200
↓
7/7 article
Origin/Public exact match
↓
New ChatGPT marker = True
Old translation = False
↓
Run = 200 / ONLINE_RUN_OK
Format = 200 / ONLINE_FMT_OK
↓
/socket = 404
↓
无需 EdgeOne 全站 purge这也意味着，从最开始重新评估翻译方案，到现在为止，整个链路终于真正闭合：
Translation Engine 实验
↓
选择 ChatGPT
↓
103 页全量重译
↓
语义质量审核
↓
A=103
↓
Canonical Promotion
↓
正式 Production Release
↓
生产部署
↓
103/103 公网验收
↓
7/7 Exact Match
↓
Run / Format 实际验证前两篇解决的是：
新的译文够不够好，以及怎样安全进入正式仓库。
这一篇解决的是最后一个问题：
怎样证明用户此刻从公网访问到的，真的就是这一轮正式发布的 ChatGPT 新译文。
现在这个答案已经有了：
103/103 正常，7/7 exact match，新译文存在、旧译文消失，Run 与 Format 全部通过。
到这里，这一轮 A Tour of Go 简体中文 103 页 ChatGPT 全量重译，可以正式收尾了。
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ 在线学习：A Tour of Go 简体中文版
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
当前第一阶段已完成简体中文版本。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。
发表回复