为什么在 Chrome 开发者工具中调整窗口大小的行为与调整“响应框”大小的行为不同？
MrJ*_*eno 12 html javascript css viewport google-developer-tools
昨天，我观察到一些非常奇怪的行为，并就此写了一个很长的问题。正如@tacoshy正确指出的那样，这个问题缺乏重点。因此，在这篇文章中，我将重点关注一个问题：
为什么在 Chrome 开发者工具中调整窗口大小的行为与调整“响应框”大小的行为不同？
前言
- 元素<head>包含以下视口元标记
<meta name="viewport" content="width=device-width, initial-scale=1" />
在下面显示任何视频之前，已在 Chrome-devtools
Settings > Preferences > Reset defaults and reload
和中执行了以下操作
The kebab-icon in the responsive view > Reset to defaults
应用程序。
一个 React 应用程序，其状态 ( ) 会在调整大小事件触发时windowWidth更新。window.innerWidth我还有一个容器 divmin-width设置为windowWidth. 简而言之，容器应该始终具有min-width与window.innerWidth. 该容器包含一个min-width静态设置为 400px 的 div。
行为
当我只打开 Chrome 开发人员工具并通过更改开发人员工具的宽度来调整可见窗口的大小时，这是观察到的行为：
window.innerWidth对应于窗口的大小。- 比例（来自
window.visualViewport.scale）仍为 1。
现在我们尝试在Chrome开发者工具响应模式下：
- 宽度保持静态（781px）
- 视口的整个比例下降。
进一步调查
window.visualViewport.width将产生几乎相同的行为- （除了宽度有时会转换为小数点值）
window.screen.width会产生不同但也是错误的行为：
- 直到屏幕变得小于青色元素（在最小宽度为 400px 的标题中）之前，布局不会中断。然后容器似乎缩小得更快，此时我们还可以看到规模如何开始下降。
- 静态设置
windowWidth为 100vw 会产生与上面完全相同的行为。
奇怪行为的解决方案
上面关于布局破坏的所有示例都有一个共同点：比例开始下降，而不是视口的实际宽度下降。因此，人们可以想象，更新包含的视口元标记minimum-scale=1可以解决问题，而且确实如此！使用
<meta
name="viewport"
content="width=device-width, initial-scale=1, minimum-scale=1"
/>
产生以下行为：
正如您所看到的，比例保持为 1 并且布局没有破坏。事实上，添加minimum-scale=1、innerWidth和visualViewport.width都会screen.width在 Chrome 开发者工具的响应式视图中产生相同的预期行为。
不幸的是，解决这不是问题，问题仍然是：
为什么在 Chrome 开发者工具中调整窗口大小的行为与调整“响应框”大小的行为不同？
编辑
在 Firefox 开发人员工具响应式视图中查看页面时，不会反映这种奇怪的缩放行为。
编辑2
类似问题
Chrome-Dev-Tools 中的移动视图是否强制缩放？
完全相同的问题，通过添加元标记解决：
<meta name="viewport" content="width=device-width, initial-scale=1.0">
显然，这确实在 2020 年 1 月解决了问题，但今天并没有解决问题（正如我们在此处看到的那样）。
也可以通过添加解决：
<meta name="viewport" content="width=device-width, initial-scale=1.0">
这一次已经出现了。
与我的行为完全相同，但所选的解决方案是 jQuery-hack。摆姿势的人还提到了倾斜手机然后再次倾斜回来时类似的缩放问题，我也经历过（当在视口元标记中添加最小宽度=1时，它就会消失）。
概括
看起来这个问题曾经通过添加来解决
<meta name="viewport" content="width=device-width, initial-scale=1.0">
但现在需要
<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1">
在这种情况下我的问题仍然是
- 他们为什么要改变这个？
- 开发者在调整响应式窗口大小时改变页面的比例有什么用呢？
- 这是一个功能还是一个错误？
编辑3
另一方面，Edge 似乎确实反映了这种行为。
这个问题涉及的事情很多，所以很难回答。但是，经过我自己的研究（今晚我遇到了同样的问题），我发现以下细节有些有用。我认为，当没有“元视口”标签时，浏览器对移动设备默认行为的近似在某种程度上是模拟尝试处理面向桌面的页面的设备行为的“最大努力”。也许这会有所帮助：
- 非响应站点的默认视口宽度：移动浏览器使用比设备实际屏幕更宽的默认视口宽度，通常在 800 到 1024 像素之间，其中 980 像素是常见的默认值。当网站没有任何指令（如
viewport元标记）告诉浏览器如何针对不同的屏幕尺寸缩放或调整内容大小时，使用此宽度。 - 默认宽度的目的：选择此默认宽度是为了近似桌面网站的典型宽度。如果没有它，非响应式网站（专为台式机设计）将显得非常小并且难以在移动设备上阅读。浏览器本质上将页面渲染为在更宽的屏幕上，然后将其缩小以适合移动屏幕。
- 设备模拟中的效果：在没有响应式
viewport元标记的情况下在 Chrome DevTools 中使用设备模拟时，您可能会注意到内容会缩放，就像在 980 像素宽的屏幕上呈现一样。这是因为模拟正在模仿移动浏览器处理无响应网站的行为。 - 响应式设计和视口元标记：在响应式网站中，
viewport元标记 (<meta name="viewport" content="width=device-width, initial-scale=1">) 指示浏览器使用实际设备宽度进行渲染，而不是默认的 980 像素。此标记可确保内容的大小和缩放适合设备，从而无需默认宽度。
老实说，我认为 Chrome（和 Firefox 等）团队应该更详细地了解他们提供的模拟行为，但要理解，“我们会尽力而为”，而没有“元视口”标签对我有帮助。一旦<meta name="viewport"...设置完毕，它的播放效果应该会更加一致。
（注意：我正在关注这个问题，因为我想更多地了解这些没有充分记录的微妙行为）