viewport标签未生效导致页面退化为桌面模式，90%因未正确书写或缺失该标签；必须静态置于head顶部、内容完整且不可动态插入，否则浏览器默认以980px虚拟视口渲染，致使响应式布局全部失效。
viewport 标签没生效，页面直接退化成桌面模式
移动端页面缩成一团、文字糊、左右可拖动，90% 是因为 <meta name="viewport"> 没写对，或压根没写。它不是可选配置，而是浏览器渲染的开关——缺了就默认走 980px 虚拟视口，媒体查询、rem、flex 全部失效。
必须满足三个硬性条件：
-
<meta name="viewport" content="width=device-width, initial-scale=1.0">这一行要完整，且静态写死在最顶部，早于所有 CSS/JS - 不能用 JS 动态插入（
document.head.appendChild()在 iOS Safari 和多数 Android WebView 中被忽略） - 禁用
user-scalable=no或maximum-scale=1.0：既不真正禁缩放，又违反 WCAG 可访问性，横屏时还可能卡死 - 绝对不要写
width=375或width=414这类固定值——折叠屏、iPad 分屏、键盘弹出时全崩
rem 基准计算导致闪屏或错位
用 JS 在 DOMContentLoaded 里执行 document.documentElement.style.fontSize = ...，用户会明显看到文字先按 16px 渲染、再跳变——这不是体验问题，是渲染流程缺陷。
更可靠的做法是把计算逻辑前置到 CSS 中：
- 现代浏览器推荐：
<style>html { font-size: calc(100vw / 375 * 16px); }</style>（假设设计稿宽 375px） - iOS ≤12 不支持
calc(100vw / 375 * 1rem)混单位，必须统一用px - 加
clamp()限幅防极端场景：font-size: clamp(12px, 100vw / 375 * 16px, 24px); - 避免监听
resize动态重设——横竖屏切换后window.innerWidth常滞后，尤其 iOS 上不准
flex 布局在老 iOS 和 Android WebView 中行为异常
写了 min-width: 200px 却被压缩到 0 宽，不是 bug，是 iOS 12 及更早版本 flex 算法根本不处理 min-width；Android 4.4 WebView 对 flex: 1、align-items: stretch 支持也不完整。
绕过方案要具体到属性级：
- 子元素需保宽度？加
flex-shrink: 0，比min-width更受老系统尊重 - 或改用
width: max-content; flex: 0 0 auto; - Android ≤4.4 必须降级：
display: -webkit-box;+-webkit-box-flex: 1; - 别依赖
flex-basis控关键尺寸——Chrome 80 前表现不一致
第三方组件（如 mp-html）在鸿蒙 NEXT 上递归崩溃
mp-html 的 node.vue 组件靠递归嵌套处理富文本树结构，但鸿蒙 NEXT 明确禁止组件直接或间接调用自身，一渲染就报错或 JS 线程崩溃。
临时能跑通的实操路径只有两条：
- 如果业务中富文本嵌套简单（无表格套表格、图片套链接等），直接删掉
<node></node>组件里的自引用，改用扁平化模板手动展开层级 - 若必须支持深层嵌套，得把递归逻辑改写为迭代：用栈模拟调用栈，逐层解析节点，同时控制最大深度防内存溢出
- WXS 脚本在鸿蒙 NEXT 上直接不可用，所有逻辑必须迁移到标准 JS，且避免使用微信特有 API
真机测试比模拟器重要得多——鸿蒙 NEXT 的 WebView 行为和 Chrome 差异极大，尤其在 touch 事件响应和 DOM 渲染节奏上，不测等于没适配。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
