没有不值得去解决的问题,也没有不值得去学习的技术!

A Tour of Go 多语言翻译项目:修复手机端首页顶栏标题换行,并完成真机验证

图 4:发布生产并刷新 EdgeOne 缓存后,再次通过真实手机访问,顶栏项目名称已经完整保持在一行,最终移动端验收通过。

作者:

在

A Tour of Go 多语言翻译项目

图3:访问过去的 Go Tour 简体中文站 tour.go-zh.org 时,当前已经无法正常建立连接。

(1) 从「A Tour of Go 中文版」这个搜索词开始:我决定做一个持续维护的 Go Tour 中文版

本地运行的 A Tour of Go「Methods continued」课程页面,左侧为课程说明,右侧为 Go 代码编辑器及运行结果。

(2) A Tour of Go 中文版项目设计冻结:从 101 页到 103 页,从 Gin 转向 Cobra CLI

A Tour of Go 中文版开发实战:英文基线、在线运行与 101 页上游同步体系

(3) A Tour of Go 中文版开发实战:英文基线、在线运行与 101 页上游同步体系

go-tour-i18n 项目完成首个简体中文课程页面 welcome/1 的整页翻译、结构校验和本地预览。

(4) A Tour of Go 多语言翻译项目实录:完成首个 zh-CN 页面翻译闭环

图 1:DeepSeek 官方更新日志显示,本次只更新 DeepSeek-V4-Flash,DeepSeek-V4-Pro API 与 APP、Web 模型均未更新

(5) A Tour of Go 中文翻译项目进展:完成前 8 页、修复 present 语法,并暂缓 DeepSeek 对比

图 1:generics/1 简体中文页面本地预览

(6) 一个页面重试五次:使用 GLM-5.2 翻译 A Tour of Go 时遇到的 Token 与 Present 结构问题

图 1:methods/16 简体中文页面浏览器预览

(7) A Tour of Go 中文翻译实录:如何只翻译教学代码注释,而不破坏 Go 代码

图 2:A Tour of Go methods/20「练习:错误」中文候选页面最终渲染效果

(8) A Tour of Go 多语言翻译:当正确的中文语序被受保护标记顺序校验误判

图 3:methods/24 中文页面,静态代码、Bounds 行内代码和链接内的 image.Rectangle 均正确渲染

(9) A Tour of Go 中文翻译完成 7 个代表页校准:最后 3 页又发现了哪些真实问题

图 2:首批 10 个普通页面经过试跑与流程校准后全部进入 ready

(10) A Tour of Go 多语言翻译项目:首批 10 个普通页面试跑,从 2 个 blocked 到全部 ready

图 2:flowcontrol/6 最终中文页面,return 与 v 为适应自然中文语序发生整体换位

(11) A Tour of Go 中文翻译第二批实跑:从 Inline Code 顺序误判到历史响应重新验证

图 1:flowcontrol/6 首次原始输入实验直接通过统一自动校验

(12) A Tour of Go 多语言翻译项目:从 swap 问题重新审视 Token 保护,原始输入与最小保护的一次真实实验

图 7:moretypes/1 最终中文页面预览。左侧课程正文、静态代码块、行内代码和教学注释均正常渲染,右侧官方 Go 示例继续保持原样。

(13) A Tour of Go 多语言翻译实战:第三批 10 页全部 Ready,继续校准 Protected Token 的结构角色

图 4:上游源码确认共有 103 个课程页面,zh-CN 最终达到 ready=103、pending=0、blocked=0

(14) A Tour of Go 多语言翻译项目:zh-CN 103 个课程页面全部 ready,课程正文翻译阶段完成

图 4:GitHub 与 ChatGPT 已成功连接

(15) ChatGPT 连接 GitHub 实测:让 AI 直接读取 go-tour-i18n 仓库参与译文审核

图 3:中文 Go 术语校准完成后,将确定的译法写入 zh-CN glossary

(16) 为什么 channel 最终选择“通道”:A Tour of Go 中文术语统一的一次实践

图 1:技术含义基本正确,但“返回一个返回……”已经明显影响阅读,因此仍被列入 C 类修订

(17) 103 页逐页审核后,只返修 16 页:A Tour of Go 中文正文发布前质量审计

图 2:中文课程页面以及已经完成本地化的编辑器控制区

(18) A Tour of Go 多语言翻译项目:公共 UI 本地化完成,从课程译文走向完整中文界面

图 2:完整 zh-CN 正式投影成功生成,103 个课程页面被重新组装为 7 个 .article

(19) 从 103/103 ready 到完整站点验收:A Tour of Go 中文版补齐正式投影与课程元数据本地化

图 3:从 production bundle 独立启动的 A Tour of Go 简体中文页面,课程正文、公共 UI 和官方 Go 示例均已进入最终发布形态。

(20) A Tour of Go 多语言翻译项目:103 页全部完成后,我终于生成了可独立部署的 zh-CN Production Bundle

图 1:A Tour of Go 简体中文版正式生产页面,远程运行已经成功输出“Hello, 世界”。

(21) A Tour of Go 多语言翻译项目:zh-CN 正式上线,从生产发布到 go.dev Playground 的完整部署记录

图 1:新生产域名 go-dev.shuijingwanwq.com 已正常访问,Go 示例远程运行成功

(22) A Tour of Go 多语言翻译项目:从 go-tour 到 go-dev,完成 EdgeOne、Nginx 与 HTTPS 生产域名迁移

图 1:A Tour of Go 多语言翻译项目正式生产首页

(23) A Tour of Go 多语言翻译项目正式上线:从项目首页、公共 Footer 到生产发布元数据的完整收尾

图 3:GA4 g/collect 请求返回 HTTP 204,并携带当前课程页面地址,确认 Google Analytics 已产生真实事件上报

(24) A Tour of Go 多语言翻译项目:接入 Google Analytics 与百度统计,从 systemd 注入到 EdgeOne 与真实上报验证

图 1:生产环境 robots.txt 与 sitemap.xml 已正确对外提供,Sitemap 共包含 104 个规范 URL。

(25) A Tour of Go 中文站上线后:补齐 robots.txt、Sitemap,并完成五大搜索引擎提交

图 4:发布生产并刷新 EdgeOne 缓存后,再次通过真实手机访问,顶栏项目名称已经完整保持在一行,最终移动端验收通过。

(26) A Tour of Go 多语言翻译项目:修复手机端首页顶栏标题换行,并完成真机验证

图 3:生产自动部署脚本第一次真实运行时,systemd 已经显示 active,但首次 localhost 探测仍然得到 HTTP 000;随后连续 3 次同时满足 active + HTTP 200 后,脚本才判定部署成功,并继续完成公网 HTTP 200 验收。这次真实运行验证了连续应用层健康检查的必要性。

(27) A Tour of Go 多语言翻译项目:从一次 203/EXEC 故障到生产自动部署脚本落地

图 1:阿里云生产环境访问 go.dev Playground 时出现 TLS 握手超时

(28) A Tour of Go 多语言翻译项目:为 Playground 搭建独立的 ZgoCloud 执行代理

图 3:清除 /tour/script.js 缓存后,Run 已直接请求 ZgoCloud /compile 并返回 HTTP 200

(29) A Tour of Go 多语言翻译项目:将生产 Run / Format 切换到 ZgoCloud 执行节点

【图 1:微信中运行 Go 示例时出现 Error communicating with remote server.】

(30) A Tour of Go 中文版手机端运行与格式化偶发失败排查:从间歇性报错到补强 Nginx 可观测性

【图 4:向 golang-dev 公开邮件列表发送 Playground 使用告知邮件并投递成功】

(31) A Tour of Go 多语言项目:为 Playground 代理增加唯一 User-Agent,并主动告知 Go 官方

【图 3:百度剩余 9 个核心 URL 提交成功,remain 归零】

(32) A Tour of Go 搜索引擎收录实测:从 Google 自然索引到百度主动提交与 Bing IndexNow

【图 1:当前正式中文 methods/24 页面,右侧示例代码运行成功】

(33) A Tour of Go 中文翻译完成后,我为什么重新评估 minimal-protect 翻译模式

【图 3:5 个页面 Request SHA256 完全一致,但 Response SHA256 全部不同】

(34) A Tour of Go 翻译实验:更多原始上下文为什么没有更好?从 157 个保护标记到 30 次重复盲评

图 3:3 个代表页 × 4 个评审模型,共 12 次匿名评审的完整排名与第一名票数。

(35) A Tour of Go 翻译质量再评估:minimal-protect 未达预期后,我开始比较 ChatGPT、Codex 与 GLM-5.2

图 2:GitHub 中的 chatgpt-zh-CN-008 重译批次。一个 Batch 同时保存 inputs、raw-responses、candidates、validation 和 retry 记录,GitHub 成为 ChatGPT 与本地翻译流水线之间的数据交接层。

(36) 没有 OpenAI API,我如何用 ChatGPT + GitHub 完成 A Tour of Go 103 页全量重译

图 1:103 个正式课程页面完成最终语义质量审核,结果为 A=103、B/C/D=0,同时不存在缺失、重复或额外页面。A/B/C/D 是本轮项目内部语义质量分级,并不是自动结构 validator 的结果。

(37) 103 页翻完还不能发布:A Tour of Go ChatGPT 译文的语义审核与 Canonical Promotion

图 3:7 个 article endpoint 的 production origin 与 EdgeOne 公网响应全部 exact match,同时新的 ChatGPT 译文标记存在,旧版译文标记已经消失。

(38) 103/103 与 7/7 Exact Match:A Tour of Go ChatGPT 新译文的最终线上验收

【图 2:upstream source preview】

(39) A Tour of Go 多语言翻译项目首次实现 upstream 同步机制:从一次性翻译到长期维护

图 2:A/B/C/D 质量评级规则,展示正式质量 rubric 与 Promotion gate。

(40) A Tour of Go 多语言翻译项目引入 Translation Quality Review:从自动验证到 AI 翻译质量控制

图 4:翻译后 Playground Example,展示中文注释与保持不变的 Go 代码结构。

(41) A Tour of Go 多语言翻译项目实现 Playground Example 本地化:从代码注释翻译到完整学习体验

图 5:公网页面验证广告脚本输出

(42) A Tour of Go 多语言翻译项目接入广告系统:从 AdSense 专用配置到通用 HTML 注入架构

图 3:百度统计单页应用设置

(43) go-dev 单页网站接入统计与 Google AdSense Auto Ads 验证记录

图 1:GitHub 仓库中的多语言翻译项目结构

(44) A Tour of Go 多语言翻译项目:选择日语作为第二语言并启动翻译验证

图 5:模型身份描述不一致

(45) A Tour of Go 多语言翻译项目中的 AI 协作异常排查:一次长期工程会话失效分析

【图 1:ChatGPT GitHub 写入流程调整说明截图】

(46) go-tour-i18n 翻译流程调整:从 ChatGPT GitHub 写入到本地 artifact 导入

图 4 展示了本次异常状态。

(47) go-tour-i18n 翻译自动化流程复盘:已验证的 ChatGPT 翻译能力在新任务中的稳定性问题

【图 6:全部评审结束以后才读取 secret key,完成最终揭盲】

(48) A Tour of Go 翻译质量再评估:Codex High 已接近 ChatGPT High,我决定调整默认翻译引擎

图 4:ja-JP 生产课程页实际运行 Go 示例

(49) A Tour of Go 日语版正式上线:第二门语言 ja-JP 完成生产发布

图 1:ja-JP 上线以后,先提交“新增语言标准化流程”

(50) A Tour of Go 多语言扩展复盘:为第三门语言建立标准化流程

图 1:课程正文结束以后,页面左侧仍然存在大块视觉空白,但 AdSense 并没有在这里插入展示广告。

(51) A Tour of Go 明明有大片空白,为什么 AdSense 就是不显示展示广告?

图 2:golang/website 当前的 _content/tour/。课程内容、静态资源和模板都在这个上游目录中持续维护。

(52) 为了 AdSense,要不要放弃 SPA?A Tour of Go 页面架构的一次取舍

图 4:最终的手动课程广告真实展示在课程内容区域内,而不是 footer 之后。

(53) 保留 SPA 以后,广告应该放在哪里?从 AdSense 预览到方案 B

图 1:Google Search Console 中,多个不同的 A Tour of Go 课程 URL 被判断为“重复网页,用户未选定规范网页”。

(54) SPA 的 SEO 老问题:为什么最后还是给 103 个 A Tour of Go 课程页生成了 Prerender HTML

图 2:方案 B 生产环境中,源码已经正常,但课程主体高度异常缩短,footer 提前进入第一屏。

(55) 从源码空白到 AdSense 高度污染:A Tour of Go 方案 B 的生产收尾

图 1:A Tour of Go 德语版 de-DE 已正式运行在生产环境

(56) A Tour of Go de-DE 上线复盘:第三门语言用了约 16 小时,下一门如何压到 8 小时?

图 1:fr-FR 首次 production 验收完成后,我没有立即开始 ko-KR,而是先连续完成新增语言与首次生产流程的优化

(57) 法语版上线后,我没有马上开始韩语:A Tour of Go 新增语言流程的一轮完善与简化

图 1:根据 ko-KR 期间 76 次 Git 提交估算实际工作时间

(58) 原本预计 6 小时,最后用了约 16~18 小时:A Tour of Go 韩语版上线复盘

图 2:英文 source 与当时发生 validation failure 的 ko-KR candidate 对比

(59) Validator 报错,到底该改译文还是改规则?一次 A Tour of Go 韩语翻译实战

图 2:法语 A Tour of Go 仓库目前已经归档,页面仍保留 553 Commits 和 61 Contributors 的历史

(60) 从法语 553 次提交到韩语两代离线:A Tour of Go 社区翻译为什么难以长期维护

【图 4:es-ES 首次 Production 收口后连续完成的流程优化 commit】

(61) 从 es-ES 首次上线复盘:我把 A Tour of Go 新增语言的 Production 流程又收敛了一轮

图 1:旧公网验收链路连续出现 curl 28 超时,最终导致 public-machine 阶段失败

(62) A Tour of Go Production 公网验收踩坑:从跨境 SOCKS 链路改为 zgocloud direct

图 1:两次 Production Machine Acceptance 都已经通过,但 Headless Chrome 分别在 / 和 /tour/ 判定页面没有完成渲染

(63) 页面明明能打开,为什么 Headless Chrome 仍然判定 Production 失败?

图 3:Bing 从 Google Search Console 中识别到新的 it-IT 站点,并同时发现已有的 1 个 sitemap

(64) GSC → Bing Webmaster Tools:多语言站点如何减少重复验证

图 3:英文站 3 小时内出现 565 个 Cloudflare 来源 URL

(65) IndexNow 实战:手工提交长期不显示,Cloudflare Crawler Hints 却很快出现在 Bing Webmaster Tools

【图 1:A Tour of Go 项目首页目前的语言版本列表】

(66) 从 nl-NL 到 tr-TR:A Tour of Go 连续上线三门语言后,我又优化了哪些流程

【图 4:Go local 页面中已经出现 French、German、Korean、Simplified Chinese】

(67) 从邮件无人回复到进入 Go 官方 Go local:我的 4 个 A Tour of Go 翻译站终于被收录

图8:最终只保留一把启用的新 API Key

(68) 腾讯云 EdgeOne API 自动化:从 CAM 子用户到最小权限 API Key 的完整配置

【图 7:Production Release Batch 最终汇总】

(69) 从同步 Go 官方上游到一个命令发布 10 个语言站:A Tour of Go Production 流程的再次收敛

【图 3:Cloudflare Smart Tiered Cache 已启用】

(70) Cloudflare 缓存 HIT 很快,MISS 却不稳定:回源阿里云杭州的一次真实优化

【图 3:简体中文站 Support 页面】

(71) 广告之外,社区项目如何长期活下去?我给 A Tour of Go 多语言项目加了 Support

图5:评论成功发布

(72) 从 Go Weekly 到 Reddit、DEV 和 Go Forum:第一次系统推广 A Tour of Go 多语言项目

【图 4:RTL 桌面课程布局修复后的效果】

(73) 第一次把 A Tour of Go 做成 RTL:阿拉伯语版本上线,以及我踩过的几个坑

最近在继续完善 A Tour of Go 多语言翻译项目的生产站点时,我使用真实手机访问首页,发现了一个桌面端并不明显的问题:

顶部导航栏中的“A Tour of Go 多语言翻译项目”在手机上放不下,最后一个“目”被挤到了第二行。

这个问题本身不复杂,但整个处理过程还是很有代表性:从真实手机发现问题,到定位移动端 CSS,再到 360px 与 320px 宽度的取舍,最后发布生产并处理 EdgeOne 缓存,才真正完成闭环。

本文记录这次手机端首页顶栏问题的处理过程。


一、真实手机上发现标题换行

项目首页顶部包含 Logo 和项目名称:

Plaintext
A Tour of Go 多语言翻译项目

桌面浏览器下没有明显问题,但在真实手机中打开生产站点后,标题发生了换行。

图 1:真实手机访问首页时,顶栏项目名称发生换行,最后一个“目”被挤到第二行,说明桌面端正常并不代表真实移动端布局没有问题。
图 1:真实手机访问首页时,顶栏项目名称发生换行,最后一个“目”被挤到第二行,说明桌面端正常并不代表真实移动端布局没有问题。

从截图可以看到,第一行已经占满顶部栏:

Plaintext
A Tour of Go 多语言翻译项

最后一个:

Plaintext
目

单独掉到了第二行。

而顶部栏本身高度是固定的,因此第二行已经接近超出可用空间。

首页主体本身并没有明显异常,问题基本可以确定只存在于顶部导航栏。


二、定位移动端 CSS

首页顶部模板本身很简单,结构大致为:

CSS
<header class="bar top-bar site-header">
    <a href="/"><img src="/images/site-logo.png" class="site-logo" alt=""></a>
    <a class="logo" href="/">{{ui "site.title"}}</a>
</header>

项目名称来自公共 UI 文案:

Plaintext
A Tour of Go 多语言翻译项目

继续检查 CSS 后,问题集中到了手机端媒体查询。

原来的移动端标题样式中存在:

CSS
.site-header .logo {
    font-size: 1em;
    white-space: normal;
    line-height: 20px;
}

其中最关键的是:

CSS
white-space: normal;

也就是说,移动端明确允许这个标题自动换行。

对于较短标题,这个设置没有什么问题。

但“A Tour of Go 多语言翻译项目”同时包含英文和中文,而且前面还有 Logo,占用的横向空间比较多,所以在真实手机宽度下刚好触发了换行。


三、没有直接大幅缩小字体

最简单粗暴的修复方式当然是继续缩小字体。

例如直接从:

CSS
font-size: 1em;

降低到一个非常小的值。

这样即使 320px 宽度可能也能强行塞进去。

但我最后没有采用这种思路。

原因是这个项目从一开始就是按照多语言方向设计的。

目前第一阶段只有简体中文,但未来如果增加其他语言,站点标题长度并不会固定。

如果为了当前中文标题在极窄设备上绝对保持单行,而不断压缩字体,那么最后很可能得到一个“技术上不换行,但实际很难看”的顶栏。

所以这次我选择先解决正常手机宽度下的真实问题,而不是无限追求最窄设备兼容。


四、最终采用的 CSS 调整

最终修改比较克制。

一方面减小 Logo 与标题之间的间距:

CSS
.site-header .site-logo {
    margin-right: 0.75rem;
}

另一方面稍微降低标题字号,并禁止自动换行:

CSS
.site-header .logo {
    font-size: 0.9em;
    white-space: nowrap;
    line-height: 20px;
}

对应提交为:

Plaintext
a4d4dca
fix: 修复首页手机端顶栏标题换行
图 2:最终的手机端顶栏 CSS 修复。缩小 Logo 与标题之间的间距,适当降低移动端标题字号,并禁止标题换行。
图 2:最终的手机端顶栏 CSS 修复。缩小 Logo 与标题之间的间距,适当降低移动端标题字号,并禁止标题换行。

这里没有改变桌面端样式,只针对:

CSS
@media (max-width: 600px)

范围内的移动端布局进行调整。

这符合这次问题的实际范围,也避免因为修手机端而影响已经正常的桌面页面。


五、先在 360px 下验证

代码修改后,我首先使用 Firefox 的响应式设计模式模拟手机宽度。

测试宽度为:

Plaintext
360px

在这个宽度下,顶部标题已经能够完整保持一行:

Plaintext
A Tour of Go 多语言翻译项目

Logo、标题和顶部栏高度也都保持正常。

图 3:在 Firefox 响应式设计模式下使用 360px 宽度验证,顶栏标题已经能够保持单行显示。对于更极端的 320px 宽度,没有继续通过大幅缩小字号来强行适配。
图 3:在 Firefox 响应式设计模式下使用 360px 宽度验证,顶栏标题已经能够保持单行显示。对于更极端的 320px 宽度,没有继续通过大幅缩小字号来强行适配。

这里还有一个值得记录的边界。

我继续测试了:

Plaintext
320px

在 320px 下,当前标题仍然比较紧张,最后部分存在被裁切的可能。

最初我也考虑过要不要继续为 320px 调整。

但最后决定停止。


六、为什么没有继续针对 320px 优化

这个决定主要基于三个考虑。

1. 360px 已经覆盖当前更实际的手机使用场景

这次真实手机本身的问题已经能够通过当前方案解决。

继续针对更窄宽度缩小字体,实际收益开始明显下降。

2. 项目未来还会扩展其他语言

现在标题是:

Plaintext
A Tour of Go 多语言翻译项目

未来如果增加其他语言,标题长度很可能不同。

如果现在针对某个固定中文字符串精确压缩到 320px,很容易变成一次性的特殊适配。

3. 可读性比绝对单行更重要

响应式设计并不是:

所有设备宽度下,所有文本都必须强制保持完全相同的布局。

更合理的目标应该是:

在主要设备范围内保持正常体验,同时避免为了极端边界破坏整体可读性。

因此这次最终把 360px 作为当前简体中文首页比较实际的移动端边界,没有继续扩大 CSS 特殊处理。


七、提交并发布生产

确认本地表现后,我提交了这次修改:

Plaintext
a4d4dca
fix: 修复首页手机端顶栏标题换行

随后生成新的简体中文 production release。

当时项目状态仍然保持:

Plaintext
ready=103
pending=0
blocked=0
pages=103
articles=7

也就是说,这次发布本质上只是站点样式调整,没有改变已经完成的 103 个课程页面翻译状态。

发布后,源站已经能够返回新的 CSS。

但真实手机再次打开页面时,我却发现:

页面看起来仍然像修改前一样。


八、源站已经更新,手机却仍然显示旧 CSS

进一步检查后发现,问题已经不在应用本身。

桌面和移动端请求使用的 CSS 文件内容一致,源站也已经是新版本。

真正影响手机显示的是腾讯云 EdgeOne 缓存。

也就是说,实际链路变成了:

Plaintext
Git 中 CSS 已更新
→ production release 已更新
→ Go Tour 源站已更新
→ EdgeOne 仍然缓存旧静态资源
→ 手机继续看到旧样式

这也是 CDN 环境中一个很容易产生误判的地方。

如果只看手机:

修改没有生效。

但如果只看源站:

修改明明已经生效。

两个结论其实都没有错,因为看到的是链路中的不同层。

最终我手工刷新了 EdgeOne 缓存。


九、真实手机最终验证通过

缓存刷新之后,再次使用真实手机访问:

Plaintext
https://go-dev.shuijingwanwq.com/

顶部标题已经完整显示为单行:

Plaintext
A Tour of Go 多语言翻译项目

Logo、标题、顶栏高度也都恢复正常。

图 4:发布生产并刷新 EdgeOne 缓存后,再次通过真实手机访问,顶栏项目名称已经完整保持在一行,最终移动端验收通过。
图 4:发布生产并刷新 EdgeOne 缓存后,再次通过真实手机访问,顶栏项目名称已经完整保持在一行,最终移动端验收通过。

到这里,这个手机端问题才算真正完成。

不是:

Plaintext
代码改完

也不是:

Plaintext
本地 360px 看起来正常

而是:

Plaintext
真实手机发现问题
→ CSS 定位
→ 本地响应式验证
→ 发布生产
→ CDN 缓存处理
→ 真实手机重新验收

完整闭环。


十、这次问题带来的几个小结

这次只是一个很小的顶部标题换行问题,但还是留下了几个值得记录的经验。

1. 响应式设计最终还是需要真机验证

浏览器响应式模式非常适合快速定位和调试。

但它更适合回答:

这个 CSS 调整大概率是否正确?

真正上线以后,仍然应该让真实设备回答:

用户实际看到的结果是否正确?

尤其是字体、浏览器 UI、设备缩放、CDN 缓存等因素,都可能让真实环境和开发模拟存在差异。

2. 不要为了最极端宽度无限堆特殊规则

320px 下继续压字体当然可以做到。

但从维护角度看,这很可能只是开始。

以后换一个语言、更长一个标题,又需要继续调整。

相比之下,这次接受一个合理的移动端边界,保持 CSS 简单,长期维护成本更低。

3. 多语言项目应该尽量避免依赖固定字符串长度

这次虽然暂时通过 nowrap 解决了简体中文首页问题,但它也提醒我:

顶栏设计不能永远假设项目名称长度固定。

第一阶段只有 zh-CN,当前方案足够。

未来真正增加其他语言后,如果出现明显更长的项目名称,更合理的处理方式可能是重新考虑移动端 Header 的信息架构,而不是继续一点点压缩字体。

这属于未来语言扩展真正发生以后再处理的问题,没有必要现在提前建设复杂方案。

4. CDN 缓存也是前端发布链路的一部分

对于接入 CDN 的生产站点:

Plaintext
源站正确

并不等于:

Plaintext
用户立刻看到正确内容

静态 CSS、JavaScript 和 HTML 都可能继续由边缘缓存提供。

所以以后类似样式发布,如果出现:

Plaintext
源站已经更新
浏览器却还是旧样式

应该优先区分:

Plaintext
应用问题
源站问题
CDN 缓存问题
浏览器本地缓存问题

而不是立即重新修改代码。


十一、一个 CSS 修复又暴露了另一个问题

这次文章暂时只记录手机端顶栏本身。

不过在发布这个小小的 CSS 修复过程中,还意外遇到了另一个更值得单独记录的问题:

新 release 上传到服务器以后,因为目录权限异常,go-tour.service 一度出现 status=203/EXEC,生产站点返回 502。

虽然最后成功回滚并修复,但这个经历让我重新审视了当前仍然依赖较多人工步骤的 production 发布流程。

随后我又花了一轮时间,把上传、权限归一化、SHA-256 校验、原子切换、连续健康检查和失败回滚整理成了一份 production 自动部署脚本。

而且第一次真实运行自动部署脚本时,还观察到了一个很有意思的现象:

Plaintext
systemd 已经 active
但 localhost 第一次仍然 HTTP 000

直到随后连续 3 次 HTTP 200,才真正判定应用稳定。

这部分已经完全超出了本文的手机端 CSS 主题,我准备单独整理下一篇文章。


总结

这次 A Tour of Go 多语言翻译项目手机端首页顶栏问题,最终只修改了很少的 CSS:

CSS
.site-header .site-logo {
    margin-right: 0.75rem;
}

.site-header .logo {
    font-size: 0.9em;
    white-space: nowrap;
    line-height: 20px;
}

但真正完成一次生产问题修复,依然经历了:

Plaintext
真机发现
→ 定位 CSS
→ 360px 验证
→ 评估 320px 边界
→ 控制修改范围
→ 提交
→ 发布
→ 排查 CDN 缓存
→ 真机最终验收

最终结果已经达到这次调整的目标:

在当前主要手机宽度下,顶部“A Tour of Go 多语言翻译项目”能够完整保持单行显示,同时没有为了极端窄屏增加更多特殊 CSS。

对于这个长期维护的多语言项目来说,我越来越倾向于这样的处理原则:

先解决真实存在的问题,保留足够简单的实现;未来真正出现新的语言和新的布局需求时,再根据实际情况扩展。

而不是为了尚未出现的边界,把一个简单问题提前做成一套复杂系统。

A Tour of Go 中文站上线后:补齐 robots.txt、Sitemap,并完成五大搜索引擎提交 A Tour of Go 多语言翻译项目:从一次 203/EXEC 故障到生产自动部署脚本落地

A Tour of Go 多语言翻译项目

本系列完整记录 A Tour of Go 多语言翻译项目从架构设计、整页翻译、结构保护、自动校验,到生产发布与后续维护的实际开发过程。

项目入口:
✅ Brazilian Portuguese — Português (Brasil)
✅ Dutch — Nederlands
✅ French — Français
✅ German — Deutsch
✅ Italian — Italiano
✅ Japanese — 日本語
✅ Korean — 한국어
✅ Simplified Chinese — 简体中文
✅ Spanish — Español
✅ Turkish — Türkçe
✅ 项目源码:GitHub:shuijingwan/go-tour-i18n

项目正在持续扩展更多语言版本,并长期维护翻译质量、生产发布与后续更新。项目属于非官方社区多语言翻译项目,与 Go 官方无隶属或授权关系。