viewport meta 标签必须写在 <head> 中且不可动态插入，需紧贴 <title> 后；width=device-width 是 initial-scale 生效前提；maximum-scale=1.0 和 user-scalable=no 在现代 iOS 上不可靠；桌面浏览器默认不解析 viewport 缩放属性。
viewport meta 标签必须写在 里，且不能动态插入
如果 <meta name="viewport"> 出现在 <body> 中，或通过 JS 动态 document.write() / appendChild() 插入，绝大多数浏览器（尤其是 iOS Safari 和 Android Chrome）会直接忽略它——缩放配置完全不生效。
- 必须放在
<head>最早可插入的位置，最好紧贴<title>后 - 不能依赖 JS 注入：哪怕 DOMContentLoaded 后立刻加，也晚了；浏览器解析 HTML 时已按默认视口规则渲染完首屏
- 服务端渲染或静态 HTML 中硬编码该标签是最稳妥的
width=device-width 是 initial-scale 生效的前提条件
initial-scale=1.0 单独存在时，在 iPhone、iPad、多数安卓 WebView 中形同虚设。浏览器只在识别到 width=device-width 时，才将 initial-scale 解释为“相对于 layout viewport 的缩放比”。否则它可能被降级为忽略，或退化成桌面行为。
- 错误写法：
<meta name="viewport" content="initial-scale=1.0"> - 正确写法：
<meta name="viewport" content="width=device-width, initial-scale=1.0"> - 若页面需适配固定宽度（如 375px 设计稿），可用
width=375替代width=device-width，但此时initial-scale意义变为“让 375px 宽内容铺满设备屏幕”，需手动换算比例（例如 iPhone 14 Pro 的 device-width 是 430px，则initial-scale=430/375≈1.147）
maximum-scale=1.0 和 user-scalable=no 在现代 iOS 上已不可靠
iOS Safari 13+ 及后续版本对 user-scalable=no 做了限制：即使写了，双指缩放仍可能触发，尤其在长按文本、聚焦输入框等场景下。而 maximum-scale=1.0 仅约束用户操作上限，无法阻止系统级微调（如阅读模式、字体放大补偿）。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 不要指望靠这两个参数“彻底锁死”缩放 —— 它们更多是提示，不是强制指令
- 若真需防缩放，应配合 CSS：
html { touch-action: manipulation; }减少误触响应，再用text-size-adjust: none禁用 iOS 文本自动放大 - 注意：禁用缩放会损害可访问性，WCAG 明确反对无条件
user-scalable=no
桌面浏览器根本不解析 viewport 缩放属性
Chrome、Firefox、Edge 桌面版在正常模式下完全无视 initial-scale、maximum-scale 等缩放相关值 —— 这不是 bug，是规范行为。只有开启 DevTools 的设备模拟模式（Ctrl+Shift+M），才会启用移动端 viewport 解析逻辑。
立即学习“前端免费学习笔记（深入）”；
- 调试时务必确认已进入响应式调试模式，否则看到的缩放效果全是假象
- file:// 协议下部分 Electron 或 PWA 环境可能漏掉
MobileUA 字符串，导致 WebView 不启用 viewport，需显式设置userAgent: 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)' - 真正要控制桌面端显示比例，只能靠用户手动缩放（
Ctrl+0）或系统 DPI 设置，HTML 无权干预
