系列帖子
此前，我已经完成了 A Tour of Go 多语言项目的 Playground 浏览器直连调整，让浏览器中的“运行”和“格式化”请求通过独立的 Playground 代理转发到 Go 官方服务。
相关部署过程可以参考：
A Tour of Go Playground 浏览器直连代理相关记录
这套链路上线并稳定运行以后，我又注意到了一个之前没有专门处理的问题：
第三方网站调用 Go Playground 时，官方希望调用方使用一个唯一的 User-Agent，以便识别请求来源，并提前与官方联系说明。
因此，这一次没有再调整 Playground 的整体架构，而是补齐调用方身份标识，并向 Go 官方公开邮件列表发送了一封简单的使用告知邮件。
一、先确认 Go Playground 对第三方调用的要求
Go Playground 官方页面在 “About the Playground” 中明确说明，Playground 并不只供 Go 官方自己使用，也欢迎其他网站使用这项服务。
不过官方同时提出了几个要求：
- 第三方使用前先与他们联系；
- 请求中使用唯一的 User-Agent，方便识别调用方；
- 服务本身应该对 Go 社区有益。
对于现在的 go-tour-i18n 来说，这几个条件其实比较契合。
项目本身就是一个面向 A Tour of Go 的社区多语言翻译项目，目前首先提供简体中文版本，后续还计划继续扩展其他语言。
因此，我认为最需要补上的并不是新的代理功能，而是让 Go 官方在看到这些请求时，可以明确知道：
这些 /compile 和 /fmt 请求来自 go-tour-i18n 项目。
二、User-Agent 应该代表整个多语言项目
最开始需要决定的，是 User-Agent 到底写什么。
如果只是考虑当前已经上线的简体中文版，可以使用类似：
go-tour-i18n-zh-CN/1.0但这样并不适合这个项目的长期定位。
go-tour-i18n 从架构设计开始就是一个多语言项目，zh-CN 只是第一阶段交付的语言。以后如果增加其他语言，这些语言仍然会属于同一个项目，也可能共用同一套 Playground 代理基础设施。
因此最终没有把具体语言写入 User-Agent，而是统一采用：
go-tour-i18n/1.0 (+https://github.com/shuijingwan/go-tour-i18n)这里：
go-tour-i18n表示项目身份；1.0作为当前代理调用身份版本；- GitHub 仓库地址则可以让服务端管理员看到请求以后，直接了解这个项目是什么。
同样，我也没有把当前代理服务器或具体基础设施名称写进 User-Agent。
服务器以后可能迁移，但项目身份不应该因为服务器变化而变化。
三、在 ZgoCloud Playground 代理中统一覆盖 User-Agent
当前生产 Playground 主链路是：
浏览器
→ play.go-dev.shuijingwanwq.com:8443
→ ZgoCloud Nginx Playground 代理
→ play.golang.org实际使用的两个接口分别是：
/compile
/fmt检查现有 Nginx 配置后发现，此前并没有显式设置 User-Agent。
这种情况下，浏览器自己的 User-Agent 会继续被代理转发到 play.golang.org。
这虽然不影响 Run 和 Format 功能本身，但对于 Go 官方来说，请求看起来更像来自各种不同浏览器，而不是一个稳定的第三方项目。
因此分别在 /compile 和 /fmt 的代理配置中增加：
proxy_set_header User-Agent "go-tour-i18n/1.0 (+https://github.com/shuijingwan/go-tour-i18n)";这样，无论用户实际使用 Firefox、Chrome 还是其他浏览器，最终从 Playground 代理发往 Go 官方的请求都会使用同一个项目级身份。
/compile 和 /fmt 两处统一设置 go-tour-i18n User-Agent】这次没有顺便把两个 location 抽取成公共 include，也没有调整其他代理结构。
原因很简单：
当前目标只是补充 User-Agent。
为了增加一行请求头而扩大 Nginx 重构范围，没有必要。
四、修改完成后重新做生产验收
修改生产 Nginx 配置以后，首先重新执行配置检查：
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful随后确认目标 User-Agent 在最终配置中一共出现：
2也就是 /compile 和 /fmt 各一处。
接下来重新进行实际功能测试。
Compile
测试程序正常执行并返回：
ua-ok同时：
Status: 0
VetOK: true说明编译和运行链路保持正常。
Format
/fmt 同样返回 HTTP 200，并成功把测试 Go 代码格式化，响应中的错误信息为空。
除了截图中的核心验证以外，这次还重新确认了原来的访问控制：
/compile、/fmt的OPTIONS请求仍然返回 204；- 正确 Origin 的 CORS 响应正常；
- 非允许 Origin 仍然返回 403；
- GET 请求
/compile、/fmt仍然返回 405。
因此，这次新增 User-Agent 没有改变之前已经部署完成的接口行为。
五、向 Go 官方公开邮件列表主动说明使用情况
完成生产配置以后，还有一件事情需要处理。
既然 Go Playground 官方页面明确写了第三方使用者应该先联系他们，那么仅仅设置 User-Agent 还不算完整。
官方页面提供的联系地址是：
golang-dev@googlegroups.com这是一个公开邮件列表。
因此，我使用站点自己的：
admin@shuijingwanwq.com发送了一封简单的英文邮件。
邮件主题为：
Go Playground usage by the go-tour-i18n project邮件中主要说明了几件事情：
go-tour-i18n是一个 A Tour of Go 社区多语言翻译项目；- 当前已经提供简体中文版本，未来计划支持更多语言；
- 项目使用
/compile和/fmt调用 Go Playground； - 已经为这些请求设置唯一 User-Agent；
- 项目用于 Go 学习和社区本地化。
使用的 User-Agent 也在邮件中明确列出：
go-tour-i18n/1.0 (+https://github.com/shuijingwan/go-tour-i18n)邮件最终显示投递成功。
这里我特意把事情控制得比较简单。
这封邮件只是按照 Playground 页面要求，告知第三方服务的实际使用情况和身份，没有把其他域名、商标或者品牌方面的问题混到同一封邮件中。
这样不同问题之间的边界也更加清楚。
六、为什么我认为这一小步值得补上
从纯技术角度看，不设置这个 User-Agent，Compile 和 Format 一样可以正常工作。
事实上，此前整个 Playground 代理已经稳定运行。
但生产服务除了“现在能不能工作”，还需要考虑：
上游看到这些请求时，能不能知道它们是谁发来的。
现在统一设置以后：
浏览器 User-Agent
↓
ZgoCloud Playground Proxy
↓
统一覆盖
↓
go-tour-i18n/1.0
↓
play.golang.org无论未来项目有多少种语言，也无论用户使用什么浏览器，对 Go Playground 来说，这些请求都有一个稳定的项目身份。
如果未来服务策略、流量管理或者接口使用规则发生变化，一个能够被识别的社区项目，显然比一批无法判断来源的浏览器请求更容易说明情况。
当然，这并不意味着设置 User-Agent、发送邮件以后，Playground 接口就获得了永久不变的保证。
它解决的是另一个问题：
作为第三方调用者，按照官方公开说明把自己的身份和用途说明清楚。
七、当前 Playground 调用链状态
经过这一次补充以后，当前生产状态可以概括为：
A Tour of Go 浏览器
↓
play.go-dev.shuijingwanwq.com:8443
↓
ZgoCloud Nginx Playground Proxy
↓
User-Agent:
go-tour-i18n/1.0
(+https://github.com/shuijingwan/go-tour-i18n)
↓
play.golang.org
↓
/compile
/fmt目前已经完成：
/compile生产转发；/fmt生产转发；- CORS 限制；
- 请求方法限制；
- 独立 Playground 域名；
- HTTPS；
- 唯一项目级 User-Agent；
- Go 官方公开邮件列表使用告知；
- Compile / Format 生产回归验证。
至此，Playground 代理这一部分除了“能够正常运行”以外，也补上了第三方调用身份这一层。
结语
这次改动实际上只有两行 Nginx 配置。
但它解决的是一个容易在最初部署阶段被忽略的问题：
第三方服务调用公共上游时，不应该只考虑请求是否成功，也应该考虑如何让上游明确识别自己的身份。
对于 go-tour-i18n 来说，使用项目级而不是语言级 User-Agent，也提前为后续多语言扩展留出了空间。
简体中文只是目前的第一种语言。
以后无论再增加多少 locale，只要仍属于 go-tour-i18n 项目，这个 Playground 调用身份就可以继续保持稳定。
A Tour of Go 多语言翻译项目
本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验，到生产发布与后续维护的实际开发过程。
项目入口：
✅ 在线学习：A Tour of Go 简体中文版
✅ 项目源码：GitHub：shuijingwan/go-tour-i18n
当前第一阶段已完成简体中文版本。项目属于非官方社区多语言翻译项目，与 Go 官方无隶属或授权关系。
发表回复