企业官网建设流程全解析

上周同事甩给我一张截图，说他的 Vue 后台在办公室台式机上看得好好的，换到自己那台 1920×1080 的笔记本上，右侧栏直接消失，侧边菜单挤成一条缝，表格最后一列被硬生生截断。我问他系统缩放是不是 125%，他愣了一下说对啊，出厂默认就这样。问题到这里基本就锁定了——不是代码写错了，是1920×1080 分辨率配上 125% 系统缩放，浏览器拿到的 CSS 视口宽度根本不是 1920。

这篇内容就是围绕这个场景写的：一个 Vue 项目的页面，怎么才能在 1920×1080 加 125% 缩放的笔记本上正常显示，同时又不牺牲在标准 1920 或者 1366 屏幕上的观感。我会把问题成因、三种主流适配路线的取舍、rem 与 transform scale 两套完整可抄的代码、以及我自己踩过的一堆坑全部摊开讲。适合正在做后台管理系统、数据大屏、监控看板的 Vue 开发看，也适合刚接手别人项目、被"为什么我这里排版全乱了"折磨过的同学。

1. 先把问题看透：125%缩放到底改变了什么

1.1 物理像素、CSS像素和设备像素比，这三个概念必须分清

很多人调布局时盯着"我的屏幕是 1920×1080"，这个 1920 是物理像素，是屏幕面板上真实存在的发光点数量。但浏览器排版用的是CSS 像素，两者之间隔着一个"缩放系数"。Windows 在 125% 缩放下，等于告诉系统和所有应用：把 1 个 CSS 像素画成 1.25 个物理像素。于是浏览器能用的 CSS 空间变成 1920 ÷ 1.25 = 1536。

这个换算关系对应的就是window.devicePixelRatio，在 125% 缩放下它等于 1.25。你可以打开控制台敲一行window.devicePixelRatio，再敲一行document.documentElement.clientWidth，看看实际值。在我手上的机器里，1920×1080 加 125% 缩放，devicePixelRatio是 1.25，clientWidth是 1536（如果有竖向滚动条还会更少，通常是 1536 减去滚动条宽度）。同时screen.width返回的也是 1536，不是 1920——这一点很关键，很多人以为screen.width是物理分辨率，其实 Chrome 在 Windows 上返回的是 CSS 像素值。

顺便说一句，浏览器自身的缩放（Ctrl 加号减号）和系统缩放会叠加。用户把浏览器调到 110%，再叠加系统 125%，实际devicePixelRatio会变成 1.375，clientWidth进一步缩到 1396 左右。所以做布局自适应时，永远别假设视口宽度是某个固定值。

1.2 常见缩放组合下的真实视口对照

光说理论不够直观，我整理了一张表，覆盖了目前市面上最常见的几种笔记本配置，你可以对照自己的机器看一眼：

看最后一行，4K 屏 250% 缩放和 1080P 屏 125% 缩放，最终 CSS 视口宽度居然都是 1536。这件事的意义是：你不需要为每一种分辨率单独适配，你真正要对齐的是 CSS 视口宽度这个维度。把适配的靶心从"1920"改成"1536 到 1920 这个区间"，思路会立刻清晰很多。

1.3 三类典型的翻车现场

理解了上面的换算，再看下面这些现象就不会觉得莫名其妙了。

第一类是媒体查询永远不生效。很多人习惯这么写断点：@media (min-width: 1920px) { ... }。在 125% 缩放的笔记本上，视口只有 1536，这个查询永远命中不了，你为大屏写的两栏布局、更大的字号、更宽松的间距全部失效，页面退回默认样式，看起来就是"排版乱了"。这个坑我自己踩过两次，第二次才发现问题根本不在 CSS 写得对不对。

第二类是固定像素宽度导致溢出。侧边栏写死 240px，主内容区写死min-width: 1400px，加一起 1640px 已经超过 1536，于是底部横出一条滚动条，或者主内容被 flex 压缩。flex 的默认flex-shrink: 1会把子项往死里压，表格单元格被挤到只剩几十像素，文字疯狂换行，看起来像布局崩塌。

第三类是绝对定位元素被裁掉。顶部固定的用户信息区、右上角的消息弹层、右下角的悬浮按钮，如果用了right: 0加固定宽度，在 1536 视口下位置会整体左移，和左侧内容叠在一起。这一类和前面两类不同，它不是溢出，而是"位置算错了"。

还有一种更隐蔽的：UI 组件库内部尺寸和你的布局打架。以 Element Plus 为例，它自己的表格、日期选择器内部有大量固定 px，你的全局缩放如果只作用于自己写的元素，就会出现"菜单缩了、表格没缩"的错位感。这类问题在后面第 3 节会专门讲怎么处理。

2. 适配方案选型：别一上来就改代码

2.1 方案A：rem 动态根字号，后台管理系统的首选

思路很朴素：让页面上所有尺寸都以rem为单位，然后用 JS 根据当前视口宽度动态设置html的font-size。视口 1920 时根字号设成 100px，视口 1536 时根字号设成 80px，那么一个设计稿里 300px 宽的卡片，写成3rem，在两种视口下会分别渲染成 300px 和 240px，比例完全一致。

这个方案的最大优势是整个页面的所有元素等比缩放，不需要你写任何断点，一套代码从 1366 到 1920 无缝过渡。缺点也很明确：依赖构建工具做 px 到 rem 的转换，内联样式和 canvas 绘制的内容要单独处理；另外根字号变小后字号会触及浏览器最小字号限制，这个坑值得单开一节讲。

适合：后台管理系统、表单密集的业务系统、需要严格还原设计稿比例的项目。

2.2 方案B：transform scale 整体缩放，大屏项目的标准答案

大屏看板这类项目有个特点：设计稿就是 1920×1080 一张大图，元素位置全是绝对定位，比例不能有任何变形。这种场景下 rem 反而不好用，因为你很难把每个绝对定位的坐标都换算成 rem。

transform: scale()的做法是：外层容器 100% 撑满，内层容器写死设计稿尺寸 1920×1080，然后用scale = min(视口宽/1920, 视口高/1080)整体缩放内层。因为缩放是基于容器的，所有子元素、文字、图片、canvas 一起缩放，视觉上和设计稿完全等比。

这里有个额外选择：CSS 的zoom属性。现代浏览器已经普遍支持它，而且zoom参与布局计算——也就是说，zoom: 0.8之后，元素的实际占位宽度就是原来的 0.8 倍，鼠标事件的坐标也自动换算好了，不像transform: scale()那样需要你手动反算。我在一个中等规模的大屏项目里用过zoom，效果不错，代价是 ECharts 这类 canvas 库在zoom下的渲染会和鼠标位置有一些微妙偏差，需要多测几个交互。

适合：数据大屏、数字孪生、监控看板、展厅一体机。

2.3 方案C：纯弹性布局加断点，内容型站点的稳妥路线

如果你的项目是官网、文档站、内容页这类以文字阅读为主的东西，那其实不需要等比缩放。用户在小屏上本来就更希望文字大一点、内容少一点，而不是所有东西一起缩小。

这种场景用 flex、grid、minmax()、clamp()组合就够了。比如网格写成grid-template-columns: repeat(auto-fill, minmax(280px, 1fr))，字号写成font-size: clamp(14px, 0.9vw, 18px)，再配合 1366、1536、1920 三档断点微调。代码干净、无障碍友好、不依赖 JS。

适合：官网、博客、文档、营销页。

2.4 三种方案的横向对比与组合策略

实际项目里最常见的做法是组合：后台管理系统用 rem 做整体比例，局部列表页用弹性布局兜底；大屏项目用 transform scale 做整体缩放，图表内部用 ECharts 自己的 resize 逻辑处理。别追求一个方案通吃所有页面，这不现实。

3. 动手实操：rem 方案从零配置

3.1 依赖安装与版本选择

需要两个东西：一个负责把 CSS 里的 px 自动转成 rem，一个负责在运行时动态设置根字号。前者现在主流选择是postcss-pxtorem，后者很多人用amfe-flexible，但那个库是为移动端设计的（默认按 750 设计稿算），用在大屏上要改一堆参数，我建议直接手写一个十几行的脚本，可控性更高。

# 安装转换插件，构建工具用 Vite / Webpack 都一样 npm i -D postcss-pxtorem

这里提醒一句，网上不少教程推荐px2rem-loader，那是 Webpack 时代的产物，在 Vite 项目里用不了或者要绕很多弯。用 Vite 就老老实实走 PostCSS 插件，配置更简单。

3.2 postcss 配置的三个关键参数

在项目根目录建postcss.config.js：

// postcss.config.js export default { plugins: { 'postcss-pxtorem': { // 设计稿 1920 宽，约定 1rem = 100px，所以 rootValue 填 100 rootValue: 100, // 转换所有属性，包括 font、border、box-shadow propList: ['*'], // 类名包含 no-rem 或 ignore- 的元素不转换，用于兜底 selectorBlackList: ['no-rem', 'ignore-'], // 小于 2px 的值不转换，避免 1px 边框被转成 0.01rem 后渲染消失 minPixelValue: 2, // 第三方 UI 库不转换，否则组件内部尺寸和布局会对不上 exclude: /node_modules/i } } }

四个参数里，rootValue和exclude最要命。

rootValue的算法是这样的：设计稿宽 1920，你希望 1rem 在设计稿里代表多少像素？我选 100，因为换算最直观——设计稿上量出来 320px，写成 3.2rem 就行，心算一秒完成。那么rootValue就等于 100。如果你习惯 1rem 等于 16px 那种方案，rootValue填 16，但设计稿量出来的 320px 要写成 20rem，笔算容易出错。

exclude排除node_modules这件事，网上争议挺大。我的观点是：如果项目里 UI 库用得不多、且视觉要求高，排除掉更安全。因为 Element Plus、Ant Design Vue 这些库内部有大量的固定像素逻辑（比如下拉框的定位偏移、表格列的宽度计算），你把这些 px 转成 rem，一旦根字号变化，组件内部算出来的位置和实际渲染位置就可能不一致，出现"浮层位置偏了一截"这种诡异现象。排除之后，UI 库保持固定尺寸，你自己的业务代码等比缩放，视觉上会有一点不一致，但至少功能是好的。反过来如果你追求完全等比，那就得把 UI 库也纳入转换，但要留足测试时间。

3.3 动态根字号脚本，一定要加区间钳制

在src/utils/下新建flexible.js：

// src/utils/flexible.js const DESIGN_WIDTH = 1920 // 设计稿里 1rem 对应 100 个设计像素，和 postcss 的 rootValue 保持一致 const BASE_FONT_SIZE = 100 // 缩放比例下限：对应 1366 宽屏幕（1366 / 1920 ≈ 0.71） const MIN_SCALE = 0.7 // 缩放比例上限：防止 2K、4K 屏上元素被放得过大 const MAX_SCALE = 1.3 let resizeTimer = null function setRootFontSize() { const clientWidth = document.documentElement.clientWidth if (!clientWidth) return let scale = clientWidth / DESIGN_WIDTH // 区间钳制，这一步是整个脚本的灵魂 scale = Math.min(Math.max(scale, MIN_SCALE), MAX_SCALE) const fontSize = BASE_FONT_SIZE * scale document.documentElement.style.fontSize = fontSize + 'px' } function handleResize() { // 防抖 200ms，避免拖动窗口时根字号高频跳变导致页面抖动 clearTimeout(resizeTimer) resizeTimer = setTimeout(setRootFontSize, 200) } // 首次执行要在 DOM 内容加载后，避免 clientWidth 为 0 if (document.readyState === 'loading') { document.addEventListener('DOMContentLoaded', setRootFontSize) } else { setRootFontSize() } window.addEventListener('resize', handleResize) window.addEventListener('orientationchange', handleResize)

然后在main.js里第一行引入：

// src/main.js import './utils/flexible' import { createApp } from 'vue' import App from './App.vue' createApp(App).mount('#app')

为什么必须加MIN_SCALE和MAX_SCALE？因为不做钳制的话，有人在 3840 宽的显示器上打开你的后台，根字号会变成 200px，整个页面元素放大一倍，一个按钮占半个屏幕，没法用。反过来在小窗口里，根字号会掉到 40px 以下，文字小到看不清。钳制区间把适配范围锁定在合理范围内，超出部分交给滚动条，这才是真实可用的方案。

3.4 在 Vue 里怎么用、哪些地方不能用

配置完成后，你写在<style>里的 px 会被自动转换，这部分基本无感。但有三个地方要注意。

内联样式不会转换。像<div :style="{ width: '320px' }">这种写法，PostCSS 处理不到。解决办法是提前算出 rem 值，写一个工具函数：

// src/utils/px2rem.js const BASE_FONT_SIZE = 100 // 把设计稿上的 px 值转成 rem 字符串，用于内联样式 export function px2rem(px) { return (Number(px) / BASE_FONT_SIZE).toFixed(4) + 'rem' }

用的时候:style="{ width: px2rem(320) }"，虽然麻烦一点，但至少不会漏。

Canvas 和 SVG 不吃 rem。ECharts 的fontSize、grid间距、symbolSize这些参数都是纯数字，单位是 canvas 内部像素。你得在初始化图表时读一次根字号，自己乘系数：

// 读取当前根字号，按比例换算图表参数 function getScaleFactor() { const rootFontSize = parseFloat( getComputedStyle(document.documentElement).fontSize ) return rootFontSize / 100 } const factor = getScaleFactor() const option = { textStyle: { fontSize: Math.round(14 * factor) }, grid: { left: Math.round(40 * factor), right: Math.round(40 * factor) } }

1px细线要特殊对待。在minPixelValue: 2的保护下，所有 1px 边框都不会被转成 rem，保持固定。听着是好事，但在 125% 缩放下 1px 会被渲染成 1.25 个物理像素，浏览器做抗锯齿后可能看起来比实际浅，某些深色主题下甚至像"缺了一块"。如果你很在意这条线，可以写一个全局工具类：

/* 高 DPR 下用缩放模拟更细的线条 */ .hairline-bottom { position: relative; } .hairline-bottom::after { content: ''; position: absolute; left: 0; bottom: 0; width: 100%; height: 1px; background: currentColor; transform: scaleY(0.8); transform-origin: bottom; }

4. 动手实操：大屏项目的 transform scale 方案

4.1 容器结构与 transform-origin 的讲究

大屏适配的核心是两句话：外层容器撑满视口，内层容器保持设计稿尺寸并用scale缩放。transform-origin必须设成left top，因为默认值是center center，缩放后元素会围绕中心点收缩，四周留出空白，位置全乱。

/* 外层容器：撑满整个视口，隐藏溢出 */ .screen-wrapper { position: relative; width: 100vw; height: 100vh; overflow: hidden; background: #0b1020; } /* 内层容器：固定设计稿尺寸，左上角对齐 */ .screen-content { position: absolute; left: 0; top: 0; background: #0b1020; }

缩放值由 JS 计算，scale = min(视口宽 / 1920, 视口高 / 1080)。为什么要取 min 而不是直接用宽度？因为如果只按宽度算，在一个宽而矮的窗口里（比如用户手动拖成 1920×600），内层高度 1080 缩放后仍然超过可视高度，底部内容被裁掉。取 min 保证宽高都放得下，代价是可能出现留白，留白部分用背景色填充即可。

4.2 封装成 Vue 组件，一次配置全项目复用

在src/components/下建ScreenAdapter.vue：

<!-- src/components/ScreenAdapter.vue --> <template> <div ref="wrapperRef" class="screen-wrapper"> <div class="screen-content" :style="contentStyle" > <slot /> </div> </div> </template> <script setup> import { ref, reactive, onMounted, onBeforeUnmount, computed } from 'vue' const props = defineProps({ designWidth: { type: Number, default: 1920 }, designHeight: { type: Number, default: 1080 }, // 是否在缩放后发送全局事件，方便图表组件联动 broadcast: { type: Boolean, default: true } }) const wrapperRef = ref(null) const state = reactive({ scale: 1, offsetX: 0, offsetY: 0 }) let resizeTimer = null const contentStyle = computed(() => ({ width: props.designWidth + 'px', height: props.designHeight + 'px', transform: `translate(${state.offsetX}px, ${state.offsetY}px) scale(${state.scale})`, transformOrigin: 'left top' })) function computeScale() { const el = wrapperRef.value if (!el) return const { clientWidth, clientHeight } = el // 取宽高比例的较小值，保证内容完整可见 const scale = Math.min( clientWidth / props.designWidth, clientHeight / props.designHeight ) state.scale = scale // 计算居中偏移量，避免宽高比不一致时内容贴左上角 state.offsetX = (clientWidth - props.designWidth * scale) / 2 state.offsetY = (clientHeight - props.designHeight * scale) / 2 if (props.broadcast) { window.dispatchEvent( new CustomEvent('screen-scale-change', { detail: { ...state } }) ) } } function handleResize() { clearTimeout(resizeTimer) resizeTimer = setTimeout(computeScale, 200) } onMounted(() => { computeScale() window.addEventListener('resize', handleResize) }) onBeforeUnmount(() => { clearTimeout(resizeTimer) window.removeEventListener('resize', handleResize) }) </script>

注意我用的是translate加scale的组合，而不是单纯的scale。这样在宽高比不一致时（比如 1920×1080 的设计稿放在 1536×864 的视口里，比例其实一样；但如果放在 1536×700 的视口里就不一样了），内容会自动居中，视觉上更舒服。

4.3 事件坐标换算，这个坑必须填

transform: scale()最容易出问题的地方是鼠标事件。浏览器的事件对象返回的clientX、clientY是视口坐标，而你的元素实际渲染在缩放后的位置。假设缩放比是 0.8，你在屏幕上看到元素在 (800, 400) 的位置，但点上去clientX是 800，而元素在设计稿坐标系里的位置是 800 ÷ 0.8 = 1000。

如果你的大屏里有可拖拽的面板、可点击的热区、自定义的 tooltip 定位，不做换算就会"点左边触发右边"。

// 把视口坐标换算成设计稿坐标 function toDesignCoord(event, wrapperEl, scale) { const rect = wrapperEl.getBoundingClientRect() return { x: (event.clientX - rect.left) / scale, y: (event.clientY - rect.top) / scale } }

这里有个细节：getBoundingClientRect()返回的坐标本身已经是缩放后的值，所以先减掉容器的左偏移，再除以缩放比，得到的才是设计稿坐标系里的位置。如果你的容器有translate偏移，rect.left会把它算进去，逻辑是对的。这一套我在触控一体机上验证过，手指拖拽悬浮窗的位置精度完全够用。

如果你嫌手动换算麻烦，把.screen-content的transform换成zoom: 0.8也能达到类似效果，而且事件坐标由浏览器自动处理。代价是zoom在某些 canvas 库下渲染会有点糊，而且和position: fixed的元素配合时行为比较怪。两种都试试，看你的项目里哪种问题更少。

5. 常见问题与排查速查表

5.1 高频问题速查表

下面这张表是我这几年处理适配问题时积累的，遇到问题先对照查一遍，能省掉大量调试时间：

5.2 最小字号限制，这是 rem 方案最隐蔽的坑

浏览器有一个"最小字号"设置，Chrome 中文环境下默认是 12px。意思是无论你 CSS 写多小，渲染出来的文字都不会低于 12px。这个限制在 rem 方案里会引发连锁反应。

假设你的设计稿里有一段辅助文字是 12px，转换成 rem 是0.12rem。在 1536 视口下根字号是 80px，0.12rem等于 9.6px。浏览器把它强制渲染成 12px。结果就是：文字比预期大了 25%，原来一行能放下的内容换行了，容器高度没变，文字直接溢出。

更糟的是，这个问题只在小视口下出现，在大视口上完全正常，所以测试的时候很容易漏。我的处理办法有两个：一是把辅助文字的设计稿字号提高到 14px，留出缩放余量；二是在项目的全局样式里明确声明：

/* 明确设置基准字号，避免继承到意外值 */ html { font-size: 100px; } body { font-size: 0.14rem; /* 设计稿 14px */ /* 在 1366 视口下根字号约 71px，14px 设计稿 ≈ 9.9px，仍会被限制 */ }

说实话第二种办法治标不治本。如果项目里大量使用 12px 到 14px 的小字，我更建议用 transform scale 方案，因为它通过视觉缩放实现，不触发最小字号限制。这是我在两个大屏项目对比之后得出的结论，比任何理论分析都有说服力。

5.3 滚动条宽度引起的 resize 死循环

这个坑很有意思。你的适配脚本监听resize，在回调里改根字号。根字号一改，页面内容高度变了，竖向滚动条可能出现或消失。滚动条一出现，clientWidth减少大约 15 到 17 像素。这个变化又会触发一次resize，于是根字号再变，内容高度再变，滚动条再来一次……看起来就像页面在无限抖动。

解决办法是加防抖，并且给根字号的变化加一个阈值判断：

let lastWidth = 0 function setRootFontSize() { const clientWidth = document.documentElement.clientWidth // 宽度变化小于 2px 直接忽略，躲开滚动条抖动 if (Math.abs(clientWidth - lastWidth) < 2) return lastWidth = clientWidth // 后续缩放逻辑... }

防抖时间我一般给 200ms，太短了挡不住滚动条抖动，太长了用户拖窗口时会看到明显的延迟跳变。

6. 把适配做成基础设施：检测、监控与回归

6.1 用 matchMedia 精确监听缩放变化

resize事件只能告诉你尺寸变了，但分不清是窗口被拖动，还是用户改了系统缩放。想精确监听缩放，可以用matchMedia配合dppx单位：

// 监听设备像素比变化，也就是系统缩放变化 function watchDpr(callback) { let mediaQuery = null function listen() { const dpr = window.devicePixelRatio if (mediaQuery) mediaQuery.removeEventListener('change', onChange) // resolution 查询支持小数，如 1.25dppx mediaQuery = window.matchMedia(`(resolution: ${dpr}dppx)`) mediaQuery.addEventListener('change', onChange) } function onChange() { callback(window.devicePixelRatio) // 变化后重新绑定新的查询值 listen() } listen() } watchDpr((dpr) => { console.log('设备像素比变为', dpr) // 这里可以触发一次根字号重算或图表重绘 })

这个技巧在需要区分"用户调整了系统缩放"和"用户拖动了窗口"的场景下非常有用。比如你想在缩放变化时重新加载某些高分辨率资源（根据 dpr 选 1x 还是 2x 图），就可以挂在这上面。

6.2 图片和图标的高清资源策略

在 125% 缩放下，一个设计稿上 24×24 的图标，实际会占用 30 个物理像素。如果你只有一张 24×24 的 PNG，浏览器放大后边缘会发虚。解决办法有几个层次：

能用 SVG 就用 SVG，这是最省事的，矢量图在任何缩放下都清晰。如果必须用位图，用image-set()让浏览器按 DPR 自动选图：

.logo { background-image: image-set( url('./logo.png') 1x, url('./logo@2x.png') 2x ); background-size: contain; }

如果项目用的是 uni-app 或者老浏览器需要兼容，退回到媒体查询也是可以的：

@media (min-resolution: 1.3dppx) { .logo { background-image: url('./logo@2x.png'); background-size: contain; } }

这里注意1.3dppx这个阈值，它比 1.25 略大一点，是为了覆盖 125% 和 150% 缩放两种情况，同时不误伤 100% 缩放的机器。

6.3 适配回归测试清单，上线前必过一遍

适配这种东西，改的时候觉得没问题，一上线就出各种幺蛾子。我在项目里固定了一份回归清单，每次改完布局都要过一遍：

这份清单里，第二项是最容易被忽略的，也是这次要解决的核心问题。建议在开发环境里装一个 Chrome 扩展或者直接用 Chrome DevTools 的设备模拟器，手动把宽度设成 1536 来长期自测，比每次改系统缩放重启浏览器高效得多。

6.4 一个实用的调试小工具

最后分享一个我自己写的调试浮层，开发阶段挂在 App 根组件里，一眼就能看到当前的真实视口参数，排查适配问题的时候能省很多来回切换的功夫：

<!-- src/components/DebugViewport.vue --> <template> <div v-if="visible" class="debug-viewport"> <span>视口：{{ width }} × {{ height }}</span> <span>DPR：{{ dpr }}</span> <span>根字号：{{ rootFontSize }}px</span> <button @click="visible = false">关闭</button> </div> </template> <script setup> import { ref, onMounted, onBeforeUnmount } from 'vue' const visible = ref(import.meta.env.DEV) const width = ref(0) const height = ref(0) const dpr = ref(1) const rootFontSize = ref(0) function update() { width.value = document.documentElement.clientWidth height.value = document.documentElement.clientHeight dpr.value = window.devicePixelRatio rootFontSize.value = parseFloat( getComputedStyle(document.documentElement).fontSize ).toFixed(1) } onMounted(() => { update() window.addEventListener('resize', update) }) onBeforeUnmount(() => { window.removeEventListener('resize', update) }) </script> <style scoped> .debug-viewport { position: fixed; right: 12px; bottom: 12px; z-index: 99999; display: flex; gap: 12px; padding: 8px 12px; font-size: 12px; color: #fff; background: rgba(0, 0, 0, 0.75); border-radius: 4px; } </style>

这个组件的visible默认值是import.meta.env.DEV，也就是只在开发环境显示，打包上线自动隐藏，不需要额外配置。我把这三个数值放在最显眼的位置，是因为适配问题十有八九就是这三个值和你预期的不一样，先把它们看清楚，再动手改代码。

我在实际项目里的体会是，适配这件事最难的部分从来不是写代码，而是搞清楚"到底发生了什么"。刚开始做适配的时候，我也是一看到排版乱了就去调 CSS，改了半天发现只在自己电脑上有效，换台机器又崩。后来养成习惯，先打开控制台确认视口宽度和设备像素比，再决定用哪套方案，效率提升了不止一个档次。你现在遇到的这个 1920×1080 加 125% 缩放的场景，本质就是视口宽度从 1920 变成了 1536，把这个数字记牢，剩下的都是执行细节。