Tailwind 移动端样式检查清单

Tailwind 的响应式 class 很方便，但检查不能只靠肉眼扫一遍桌面端。移动端交付前，要逐项确认布局、导航、按钮、表单、图片、长文案和横向滚动。下面这份清单适合配合 Codex 使用，但最终仍要人工在视口里验证。

完整流程可读 用 Codex 检查 Tailwind 移动端样式。如果已经发现修一个坏一个，可以看 常见错误和修复顺序。

适合谁

适合已经完成 Tailwind 页面，准备发给客户或放进作品集的新手。你可能会写 class，但还不熟悉移动端检查顺序。

也适合做小网站交付检查的人。移动端通常是客户最先发现问题的地方，提前检查能减少返工。

不适合谁

不适合复杂后台、图表系统、地图应用或需要专门可访问性测试的大型产品。那些项目需要更完整的测试方案。

也不适合只靠截图判断交付。截图能说明视觉，但不能证明菜单、表单和按钮都可用。

风险提醒

移动端问题经常来自真实内容，而不是组件本身。客户的长品牌名、长邮箱、多行价格、产品图比例、第三方嵌入，都可能让原本正常的 demo 变形。

另外，隐藏溢出不是万能修复。overflow-hidden 可能只是把问题裁掉，用户仍然看不到内容。需要判断内容是否应该换行、缩小、堆叠还是重新排版。

具体步骤

1. 视口

• 375px 左右的手机宽度是否检查。
• 430px 左右的大屏手机是否检查。
• 768px 左右的平板宽度是否检查。
• 桌面宽度是否仍正常。
• 是否记录检查宽度。

至少看三个宽度，别只拖一下浏览器。

2. 横向滚动

• 页面是否出现横向滚动条。
• 长标题是否撑出屏幕。
• 卡片网格是否正确堆叠。
• 表格或价格区是否有移动端方案。
• 图片或代码块是否撑破容器。

横向滚动是最常见的移动端红灯。

3. 导航和 CTA

• 菜单是否可点。
• sticky header 是否遮挡内容。
• CTA 是否在首屏可见但不压住正文。
• 按钮文字是否换行正常。
• 返回、关闭、展开按钮是否有足够点击区域。

如果 CTA 需要第三方表单或链接，确认客户已提供最终目标。

4. 表单

• 输入框是否宽度合适。
• label 是否清楚。
• 错误提示是否不遮挡。
• 提交按钮是否可点击。
• 键盘弹出后是否还能操作。

如果表单未接真实后端，要在交付记录里说明。

5. 图片和媒体

• logo 是否清晰。
• 图片比例是否变形。
• hero 图是否裁剪过度。
• 视频或嵌入内容是否有移动端高度。
• alt 文案是否基本可用。

客户素材授权也要单独确认。

6. 记录和复查

• 修改前截图。
• 修改后截图。
• 检查视口。
• 已覆盖页面。
• 未覆盖设备。
• 客户待确认事项。

可以把记录放进 模板库，也可以和 小网站交付检查 合并成最终报告。

审核结论怎么写

建议把结论分为可交付、需客户确认、需修复、暂不交付。可交付表示核心视口已验证；需客户确认表示素材、链接或表单目标未最终确定；需修复表示有明确移动端 bug；暂不交付表示风险超出当前范围。

这个结论适合发给客户，也适合作为作品集复盘材料。

问题等级怎么标

可以把移动端问题分成三级。P1 是阻止交付的问题，例如页面横向滚动严重、导航打不开、主要 CTA 被遮挡、表单无法填写。P2 是影响体验的问题，例如图片裁剪过度、卡片间距混乱、按钮文字换行难看。P3 是可优化问题，例如局部间距、轻微对齐和文案长度建议。

有了等级，客户就更容易理解为什么先修某些问题。你也不会被一堆视觉细节带偏，忘记先处理阻止交付的风险。

交付截图怎么整理

每张截图建议标注页面、视口、时间和问题。比如“服务页 375px，价格卡片横向滚动，P1”。修改后再保存对应截图。不要只发一堆未命名图片，客户很难对应问题。

如果截图里有客户内部信息、测试邮箱、订单号或未授权素材，先打码再发。移动端检查虽然是样式任务，也可能碰到隐私和版权边界。

CTA：下一步

选一个 Tailwind 页面，按 375px、768px、桌面三个宽度截图。每张截图标注问题和下一步，不要只凭记忆判断。

免责声明

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