最近在继续完善 A Tour of Go 多语言翻译项目的生产站点时，我使用真实手机访问首页，发现了一个桌面端并不明显的问题：
顶部导航栏中的“A Tour of Go 多语言翻译项目”在手机上放不下，最后一个“目”被挤到了第二行。
这个问题本身不复杂，但整个处理过程还是很有代表性：从真实手机发现问题，到定位移动端 CSS，再到 360px 与 320px 宽度的取舍，最后发布生产并处理 EdgeOne 缓存，才真正完成闭环。
本文记录这次手机端首页顶栏问题的处理过程。
一、真实手机上发现标题换行
项目首页顶部包含 Logo 和项目名称：
A Tour of Go 多语言翻译项目
桌面浏览器下没有明显问题，但在真实手机中打开生产站点后，标题发生了换行。
从截图可以看到，第一行已经占满顶部栏：
A Tour of Go 多语言翻译项
最后一个：
目
单独掉到了第二行。
而顶部栏本身高度是固定的，因此第二行已经接近超出可用空间。
首页主体本身并没有明显异常，问题基本可以确定只存在于顶部导航栏。
二、定位移动端 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 文案：
A Tour of Go 多语言翻译项目
继续检查 CSS 后，问题集中到了手机端媒体查询。
原来的移动端标题样式中存在：
.site-header .logo {
font-size: 1em;
white-space: normal;
line-height: 20px;
}
其中最关键的是：
white-space: normal;
也就是说，移动端明确允许这个标题自动换行。
对于较短标题，这个设置没有什么问题。
但“A Tour of Go 多语言翻译项目”同时包含英文和中文，而且前面还有 Logo，占用的横向空间比较多，所以在真实手机宽度下刚好触发了换行。
三、没有直接大幅缩小字体
最简单粗暴的修复方式当然是继续缩小字体。
例如直接从：
font-size: 1em;
降低到一个非常小的值。
这样即使 320px 宽度可能也能强行塞进去。
但我最后没有采用这种思路。
原因是这个项目从一开始就是按照多语言方向设计的。
目前第一阶段只有简体中文，但未来如果增加其他语言，站点标题长度并不会固定。
如果为了当前中文标题在极窄设备上绝对保持单行，而不断压缩字体，那么最后很可能得到一个“技术上不换行，但实际很难看”的顶栏。
所以这次我选择先解决正常手机宽度下的真实问题，而不是无限追求最窄设备兼容。
四、最终采用的 CSS 调整
最终修改比较克制。
一方面减小 Logo 与标题之间的间距：
.site-header .site-logo {
margin-right: 0.75rem;
}
另一方面稍微降低标题字号，并禁止自动换行：
.site-header .logo {
font-size: 0.9em;
white-space: nowrap;
line-height: 20px;
}
对应提交为：
a4d4dca
fix: 修复首页手机端顶栏标题换行
这里没有改变桌面端样式，只针对：
@media (max-width: 600px)
范围内的移动端布局进行调整。
这符合这次问题的实际范围，也避免因为修手机端而影响已经正常的桌面页面。
五、先在 360px 下验证
代码修改后，我首先使用 Firefox 的响应式设计模式模拟手机宽度。
测试宽度为：
360px
在这个宽度下，顶部标题已经能够完整保持一行：
A Tour of Go 多语言翻译项目
Logo、标题和顶部栏高度也都保持正常。
这里还有一个值得记录的边界。
我继续测试了：
320px
在 320px 下，当前标题仍然比较紧张，最后部分存在被裁切的可能。
最初我也考虑过要不要继续为 320px 调整。
但最后决定停止。
六、为什么没有继续针对 320px 优化
这个决定主要基于三个考虑。
1. 360px 已经覆盖当前更实际的手机使用场景
这次真实手机本身的问题已经能够通过当前方案解决。
继续针对更窄宽度缩小字体，实际收益开始明显下降。
2. 项目未来还会扩展其他语言
现在标题是：
A Tour of Go 多语言翻译项目
未来如果增加其他语言，标题长度很可能不同。
如果现在针对某个固定中文字符串精确压缩到 320px，很容易变成一次性的特殊适配。
3. 可读性比绝对单行更重要
响应式设计并不是：
所有设备宽度下，所有文本都必须强制保持完全相同的布局。
更合理的目标应该是：
在主要设备范围内保持正常体验，同时避免为了极端边界破坏整体可读性。
因此这次最终把 360px 作为当前简体中文首页比较实际的移动端边界，没有继续扩大 CSS 特殊处理。
七、提交并发布生产
确认本地表现后，我提交了这次修改：
a4d4dca
fix: 修复首页手机端顶栏标题换行
随后生成新的简体中文 production release。
当时项目状态仍然保持：
ready=103
pending=0
blocked=0
pages=103
articles=7
也就是说，这次发布本质上只是站点样式调整，没有改变已经完成的 103 个课程页面翻译状态。
发布后，源站已经能够返回新的 CSS。
但真实手机再次打开页面时，我却发现：
页面看起来仍然像修改前一样。
八、源站已经更新，手机却仍然显示旧 CSS
进一步检查后发现，问题已经不在应用本身。
桌面和移动端请求使用的 CSS 文件内容一致，源站也已经是新版本。
真正影响手机显示的是腾讯云 EdgeOne 缓存。
也就是说，实际链路变成了：
Git 中 CSS 已更新
→ production release 已更新
→ Go Tour 源站已更新
→ EdgeOne 仍然缓存旧静态资源
→ 手机继续看到旧样式
这也是 CDN 环境中一个很容易产生误判的地方。
如果只看手机：
修改没有生效。
但如果只看源站：
修改明明已经生效。
两个结论其实都没有错，因为看到的是链路中的不同层。
最终我手工刷新了 EdgeOne 缓存。
九、真实手机最终验证通过
缓存刷新之后，再次使用真实手机访问：
https://go-dev.shuijingwanwq.com/
顶部标题已经完整显示为单行：
A Tour of Go 多语言翻译项目
Logo、标题、顶栏高度也都恢复正常。
到这里，这个手机端问题才算真正完成。
不是：
代码改完
也不是：
本地 360px 看起来正常
而是：
真实手机发现问题
→ CSS 定位
→ 本地响应式验证
→ 发布生产
→ CDN 缓存处理
→ 真实手机重新验收
完整闭环。
十、这次问题带来的几个小结
这次只是一个很小的顶部标题换行问题，但还是留下了几个值得记录的经验。
1. 响应式设计最终还是需要真机验证
浏览器响应式模式非常适合快速定位和调试。
但它更适合回答：
这个 CSS 调整大概率是否正确？
真正上线以后，仍然应该让真实设备回答：
用户实际看到的结果是否正确？
尤其是字体、浏览器 UI、设备缩放、CDN 缓存等因素，都可能让真实环境和开发模拟存在差异。
2. 不要为了最极端宽度无限堆特殊规则
320px 下继续压字体当然可以做到。
但从维护角度看，这很可能只是开始。
以后换一个语言、更长一个标题，又需要继续调整。
相比之下，这次接受一个合理的移动端边界，保持 CSS 简单，长期维护成本更低。
3. 多语言项目应该尽量避免依赖固定字符串长度
这次虽然暂时通过 nowrap 解决了简体中文首页问题，但它也提醒我：
顶栏设计不能永远假设项目名称长度固定。
第一阶段只有 zh-CN，当前方案足够。
未来真正增加其他语言后，如果出现明显更长的项目名称，更合理的处理方式可能是重新考虑移动端 Header 的信息架构，而不是继续一点点压缩字体。
这属于未来语言扩展真正发生以后再处理的问题，没有必要现在提前建设复杂方案。
4. CDN 缓存也是前端发布链路的一部分
对于接入 CDN 的生产站点：
源站正确
并不等于：
用户立刻看到正确内容
静态 CSS、JavaScript 和 HTML 都可能继续由边缘缓存提供。
所以以后类似样式发布，如果出现：
源站已经更新
浏览器却还是旧样式
应该优先区分：
应用问题
源站问题
CDN 缓存问题
浏览器本地缓存问题
而不是立即重新修改代码。
十一、一个 CSS 修复又暴露了另一个问题
这次文章暂时只记录手机端顶栏本身。
不过在发布这个小小的 CSS 修复过程中，还意外遇到了另一个更值得单独记录的问题：
新 release 上传到服务器以后，因为目录权限异常，
go-tour.service一度出现status=203/EXEC，生产站点返回 502。
虽然最后成功回滚并修复，但这个经历让我重新审视了当前仍然依赖较多人工步骤的 production 发布流程。
随后我又花了一轮时间，把上传、权限归一化、SHA-256 校验、原子切换、连续健康检查和失败回滚整理成了一份 production 自动部署脚本。
而且第一次真实运行自动部署脚本时，还观察到了一个很有意思的现象：
systemd 已经 active
但 localhost 第一次仍然 HTTP 000
直到随后连续 3 次 HTTP 200，才真正判定应用稳定。
这部分已经完全超出了本文的手机端 CSS 主题，我准备单独整理下一篇文章。
总结
这次 A Tour of Go 多语言翻译项目手机端首页顶栏问题，最终只修改了很少的 CSS：
.site-header .site-logo {
margin-right: 0.75rem;
}
.site-header .logo {
font-size: 0.9em;
white-space: nowrap;
line-height: 20px;
}
但真正完成一次生产问题修复，依然经历了：
真机发现
→ 定位 CSS
→ 360px 验证
→ 评估 320px 边界
→ 控制修改范围
→ 提交
→ 发布
→ 排查 CDN 缓存
→ 真机最终验收
最终结果已经达到这次调整的目标：
在当前主要手机宽度下，顶部“A Tour of Go 多语言翻译项目”能够完整保持单行显示，同时没有为了极端窄屏增加更多特殊 CSS。
对于这个长期维护的多语言项目来说，我越来越倾向于这样的处理原则：
先解决真实存在的问题，保留足够简单的实现；未来真正出现新的语言和新的布局需求时，再根据实际情况扩展。
而不是为了尚未出现的边界，把一个简单问题提前做成一套复杂系统。
需要长期技术维护或远程问题排查？
我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。
如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：
- ✅ PHP / Laravel / Yii2 老项目无人维护
- ✅ Go / Gin 后端接口需要排查或优化
- ✅ WordPress 网站访问慢、报错或插件冲突
- ✅ Nginx / MySQL / Redis / Linux 服务器异常
- ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
- ✅ 需要长期远程技术支持或兼职维护
更多介绍请查看：关于我 & 合作
微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan
发表回复