viewport meta标签缺失或错误会导致所有断点失效，因Tailwind的sm:、md:等前缀依赖window.innerWidth触发媒体查询，而该值由<meta name="viewport" content="width=device-width, initial-scale=1">控制，缺省或错误将导致移动端以桌面宽度（如980px）渲染，断点全部错乱。
viewport meta标签缺失或错误会导致所有断点失效
Tailwind的sm:、md:等前缀依赖浏览器真实的视口宽度触发@media (min-width: ...)，而这个宽度由<meta name="viewport">控制。没它，移动端会强制以桌面宽度渲染（如980px），导致sm:（默认≥640px）永远命中，md:（≥768px）在iPhone竖屏下也直接生效——你看到的“断点没反应”，其实是断点全乱了。
- 必须写：
<meta name="viewport" content="width=device-width, initial-scale=1"> - 不能只写
width=device-width而漏掉initial-scale=1，iOS Safari会忽略该标签 - 不要写
user-scalable=no或maximum-scale=1，它们可能干扰matchMedia检测 - 检查是否被框架（如Vue CLI、Vite插件）自动注入了重复或冲突的viewport标签
为什么window.innerWidth和DevTools模拟器显示不一致
浏览器设备模拟器（比如Chrome DevTools里的“iPad Pro”）只是UI示意，真正决定断点是否生效的是window.innerWidth返回的像素值——它反映的是CSS视口宽度，不是设备物理分辨率或DPR。如果你在模拟器里切到“iPad”，但console.log(window.innerWidth)输出的是980，说明viewport没生效，断点自然不会按预期工作。
- 在控制台直接运行
window.innerWidth，以它为准，别信模拟器标签名 - 如果值异常大（如980、1024），大概率是viewport meta缺失或被覆盖
- 嵌入iframe或Webview环境时，
window.innerWidth可能读的是父容器宽，此时断点静默失效，需用document.documentElement.clientWidth交叉验证
Next.js/Nuxt等SSR框架首次加载闪动
服务端没有window对象，Tailwind无法执行matchMedia，所以所有带前缀的类（如md:text-center）在HTML初始响应中不会被注入样式规则。浏览器拿到HTML后才执行JS并匹配断点，造成“先显示移动端样式，再跳成桌面样式”的闪动。这不是bug，是SSR与客户端媒体查询天然割裂的结果。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 这是正常行为，不是配置错误；强行禁用JS或预设服务端断点反而更糟
- 若需消除闪动，可用
next/dynamic配合ssr: false延迟加载含断点的组件 - tailwindcss-debug-screens插件在SSR下只在客户端生效，适合调试但不能解决首屏问题
自定义screens后旧类突然不生效
Tailwind对theme.screens是全量替换而非合并。如果你在tailwind.config.js里重写了screens，但只写了{ md: '800px', lg: '1100px' }，那么sm、xl这些默认断点就彻底消失了——对应的所有sm:hidden、xl:flex类都不会生成CSS规则，浏览器里查不到，也不会报错。
立即学习“前端免费学习笔记（深入）”；
- 正确做法：用
theme.extend.screens追加，或手动复制默认值再修改（官方默认值见文档，别硬记） - 新增断点如
desktop，必须显式写进screens或extend.screens，否则desktop:bg-red-500纯属无效字符串 - 改完配置务必重启开发服务器，Tailwind不会热更新screens变更
window.innerWidth，而这个值又死死卡在viewport meta上。漏掉这行meta，后面所有调试都是在错误前提下打转。 
