Tailwind 移动端检查常见错误和修复顺序

Tailwind 移动端问题经常不是某一个 class 写错，而是检查顺序错了。新手容易先修看起来最明显的地方，比如给容器加 overflow-hidden，或者把字号改小。结果当前截图好了，其他页面却被裁掉、按钮变难点、桌面端也受影响。

这篇文章整理常见错误和修复顺序。完整流程见 用 Codex 检查 Tailwind 移动端样式，短表版见 Tailwind 移动端检查清单。

适合谁

适合已经发现 Tailwind 页面在手机上出问题的新手。问题可能是横向滚动、导航遮挡、按钮太小、卡片不换行、图片变形、表单字段挤在一起。

也适合接小网站修复单的人。客户反馈通常很模糊，你需要先复现，再判断严重程度，而不是立即大改。

不适合谁

不适合在大型共享组件库里随意改 class 的人。共享组件影响范围大，修复前要确认哪些页面使用它。

也不适合只靠 Codex 直接重写布局。AI 可以提供建议，但真实视口、真实内容和客户素材必须人工验证。

风险提醒

移动端修复最常见风险是隐藏问题。overflow-hidden、固定高度、绝对定位、负 margin 都可能让问题暂时消失，却让用户看不到内容。

做项目时还要注意客户验收。客户说“手机不好看”，可能包含品牌图、文案长度、CTA 位置、表单可用性和加载速度。报价前要拆成明确检查项。

具体步骤

第一步：复现并截图

先拿到问题页面、视口宽度、设备和截图。没有复现就不要修。客户如果只说“手机有问题”，先请他提供截图或具体页面。

第二步：判断问题类型

把问题分成溢出、遮挡、尺寸、堆叠、交互、内容六类。溢出看宽度和长内容；遮挡看 sticky 和 fixed；尺寸看按钮和输入框；堆叠看 grid 和 flex；交互看菜单和表单；内容看客户真实素材。

第三步：检查断点方向

Tailwind 默认是 mobile first。先看无前缀 class 是否适合小屏，再看 sm:、md:、lg: 是否逐步增强。很多错误来自默认写成桌面布局，移动端只能硬挤。

第四步：小步修复

每次只改一个组件或一个问题。修导航就不要顺手改 hero，修卡片堆叠就不要改全站 spacing。用 Codex 时，要求它说明影响范围和需要验证的视口。

第五步：复查关联页面

如果改的是共享组件，要检查所有引用页面。至少看首页、服务页、联系页和客户指定页面。修复后重新保存截图。

常见错误清单

第一类是只看桌面端。第二类是用隐藏溢出代替解决布局。第三类是断点反了，默认样式不适合手机。第四类是按钮点击区域太小。第五类是长文案没有测试。第六类是忽略真实图片比例。

第七类是没有记录视口宽度。客户下次反馈时，你不知道自己测过什么。第八类是修复范围过大，把样式任务变成重做页面。

修复顺序示例

如果页面横向滚动，先找撑宽元素。常见原因包括固定宽度、长单词、grid 不换行、图片没有 max-w-full。不要第一步就给 body 加隐藏溢出。

如果导航遮挡内容，先检查 header 高度、sticky/fixed 定位和页面 padding。修完后测试菜单打开和关闭状态，不要只看初始状态。

交付记录怎么写

交付记录包括：问题截图、修复位置、修改摘要、验证视口、仍需客户确认的素材和未覆盖设备。可以放进 模板库，或合并到 小网站交付检查 的最终报告里。

如果客户要求继续扩展范围，用 报价计算器估算新增检查和修复时间，再用 Proposal 生成器整理说明，发送前人工复核。

如何避免越修越乱

修移动端时，先只处理一个问题类型。比如这轮只修横向滚动，下一轮再修按钮尺寸。每修完一个问题，就用固定视口复查。不要在同一轮里同时改导航、hero、卡片、表单和页脚，否则很难判断哪一处带来副作用。

如果 Codex 给出大段重写建议，可以要求它缩小范围：“只改导致横向滚动的容器，不改变文案、不改变桌面布局、不新增依赖。”这种约束能让修复更接近项目里的实际需求。

什么时候需要客户确认

如果问题来自客户素材本身，例如 logo 太宽、图片比例不适合、标题太长、按钮文案必须保留，就不要擅自删改。可以给两个方案：保持内容并调整布局，或请客户缩短文案/更换素材。把选择权交给客户，避免你承担内容决策。

如果客户要求“所有手机都完美”，要把设备范围改成可检查范围，比如常见手机宽度和平板宽度。不同设备、浏览器和字体环境会有差异，交付记录要写清覆盖范围。

CTA：下一步

找一个手机端有问题的页面，先不要改代码。写下页面、视口、问题类型、截图和可能影响范围，再开始第一轮小修复。

免责声明

本文是学习和排查流程，不构成法律、财务、安全或职业承诺。具体修复需要结合项目代码、设计要求、客户素材、浏览器环境和真实设备人工判断。