viewport标签必须同时含width=device-width和initial-scale=1.0且置于head最前；内容溢出（如宽容器、nowrap文本）会强制浏览器缩放，与标签声明无关；user-scalable=no等已失效并违反可访问性标准。
width=device-width 和 initial-scale=1.0 必须同时存在，缺一不可；单独写任一个，移动端页面大概率会“自动缩小”或“文字糊成一团”。
viewport meta 标签必须放在 里且不能动态插入
浏览器解析到它就立即锁定缩放行为，晚了或位置错了，整个页面可能已经按默认 980px 宽度渲染并缩放了一次——这个过程不可逆。
- 放到
<body>里完全无效，DevTools 可能显示它，但 Safari/Chrome Mobile 根本不认 - 用 JS 动态创建并 append 到
<head>，iOS Safari 会忽略；Next.js、Vue 的 SSR 模板里要检查源码是否真有该标签 - 重复声明 viewport（比如 CMS 插入第二个）时，只取第一个，后面的被丢弃
- 务必确保它在所有 CSS/JS 引入之前，越靠前越好
为什么写了 initial-scale=1.0 却还是被缩放
不是浏览器不执行，而是内容本身把视口“撑爆”了，浏览器被迫放弃声明、强制缩小以保证可读性。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 页面里有
width: 1200px的容器，或white-space: nowrap未处理的长文本，导致内容宽度 >device-width - 浮动元素未清除、
min-width过大、flex 容器子项未设flex-shrink: 1，都可能让父容器意外变宽 - iOS Safari 明确优先保障“用户能看清”，哪怕你写了
initial-scale=1.0，只要内容溢出，它就缩 - 测试时用 Chrome DevTools 的「Capture screenshot」看真实渲染宽度，别只信 CSS 面板里的 computed 值
user-scalable=no 和 maximum-scale=1.0 已不可靠
这些参数在 2026 年已基本失效，且带来可访问性风险，真要防误触，该换方案。
立即学习“前端免费学习笔记（深入）”；
- iOS 16+ 和 Android Chrome（2025 起）已弱化甚至忽略
user-scalable=no，部分 WebView 直接跳过 -
maximum-scale=1.0等效于禁用缩放，但更难调试——它不会报错，只是某天在新机型上突然不生效 - 它直接违反 WCAG 2.1，会让 iOS「更大字体」等辅助功能彻底失效，视障用户无法放大阅读
- 替代方案是
touch-action: manipulation：保留单指滚动和辅助缩放，只禁双指缩放和长按，更安全
真正卡住缩放问题的，往往不是 viewport 写得不对，而是 CSS 里某个没重置的 min-width、一行没换行的 JSON 字符串、或者一个忘了加 overflow: hidden 的卡片容器——这些细节在模拟器里看不出来，只有真机截全屏图才能暴露。
