link标签不控制视口，仅用于关联外部资源；viewport必须由<meta name="viewport">在<head>最前声明，link位置错误（如挤占meta位置）会导致viewport失效。
link 标签本身不控制视口，也不影响 viewport 行为。它和移动端视口样式没有直接关系——这是个常见误解。
为什么 link 标签不能设置或修改视口
link 是资源关联标签，只用于引入外部文件（如 CSS、icon、preload 资源等）；而 viewport 是元信息，必须由 meta 标签在 <head> 中声明。浏览器在解析 HTML 时，meta name="viewport" 是最早读取并立即生效的指令之一，link 的加载时机晚得多，且完全不参与视口初始化逻辑。
- 动态用
document.head.appendChild()插入meta都无效，更别说link -
link rel="stylesheet"即使加载了 CSS，也无法覆盖已错误初始化的 layout viewport（比如默认 980px） - 某些构建工具误把
link标签插到<meta charset>前面，会挤占viewport的合法位置，间接导致失效
link 和视口“配合使用”的真实场景
虽然 link 不管视口，但它加载的 CSS 决定视口是否“真正起效”：视口只是打开理想渲染的开关，CSS 才是执行者。
- 必须用
link rel="stylesheet" href="main.css"引入响应式 CSS，否则即使viewport正确，页面仍可能横向滚动或文字糊 - CSS 中若写了
width: 1200px或未设max-width: 100%，会撑破视口宽度，viewport完全拦不住 - 引入
normalize.css或重置样式时，注意它是否重置了bodymargin/padding——留白过大也可能触发横向滚动，被误判为视口问题
link 标签放错位置会连累视口生效
link 自身不干预视口，但它的位置会影响 viewport 是否被正确识别。
立即学习“前端免费学习笔记（深入）”；
-
link必须放在<head>内，且不能插在<meta charset>和<meta name="viewport">中间——哪怕一个空格、一行注释、一个自动注入的占位符，都可能让浏览器跳过后续meta - Vite/Next.js 等框架模板若在
head里先写了一堆link（比如图标、preload），再写viewport，iOS Safari 可能直接忽略后者 - 验证方式：Chrome DevTools → Elements → 查看
<html>的clientWidth，iPhone 13 应为 ~390；若仍是 980，说明viewport没生效，优先检查meta是否被link或其他标签挤偏
真正卡住移动端适配的，从来不是要不要加 link，而是 meta name="viewport" 是否在最开头、是否唯一、content 是否精简。CSS 文件再漂亮，也救不回一个没启动的视口。
