v-scale-screen与 CSS 媒体查询：一套代码跑通工控屏、拼接屏、车载 HMI 的真实适配实践
你有没有遇到过这样的现场？
在客户机房里，刚部署好的可视化大屏系统，在 1920×1080 的显示器上一切正常，但一接到工控现场——换上一块 1280×720 的电阻式触摸屏，文字立刻糊成一片，按钮点不准，图表坐标轴错位；再切到车载中控台的 1920×540 超宽屏，整个页面被横向拉伸得不成样子；更别提某些嵌入式 QtWebEngine 环境下，zoom: 0.8直接被内核禁用，vw/vh单位在 DPR=2 的设备上又疯狂放大……
这不是兼容性问题，而是物理世界和设计世界的尺度没有对齐。
我们习惯把“响应式”等同于“适配不同宽度”，但在工业终端、边缘设备、定制浏览器的真实战场里，真正的挑战从来不是“宽一点还是窄一点”，而是：“这块屏的像素密度是多少？”、“它的渲染引擎是否支持缩放？”、“用户是用手指戳还是鼠标点？”、“它连window.devicePixelRatio都返回undefined怎么办？”
v-scale-screen就是在这些坑里趟出来的。它不是另一个“响应式框架”，而是一个运行时视口感知型缩放控制器——不改 HTML 结构、不侵入业务样式、不依赖构建工具，只做一件事：让设计稿上的 1px，在任何一块物理屏幕上，都尽可能地“看起来像 1px”。
而 CSS 媒体查询，则从过去“被迫扛起缩放重担”的角色中解放出来，回归它本该专注的事：理解用户场景，重构信息结构。
二者不是替代关系，也不是叠加关系，而是正交协同——就像镜头对焦（v-scale-screen）和构图取景（媒体查询）的关系：一个管“看清”，一个管“看懂”。
它到底怎么工作的？别被“缩放”二字骗了
很多人第一反应是：“哦，就是给<html>加个transform: scale()？”
对，但远远不止。
关键在于：缩放的时机、依据、边界和副作用控制。
比如，为什么必须用transform-origin: top left？
因为如果不设锚点，scale(0.7)会让整个页面向右下偏移，导致左上角内容被裁掉——这在无滚动条的全屏工控界面里，等于直接丢失关键状态栏。
为什么缩放后还要手动设置html { width: X%; height: X% }
