css宽度计算不准主因是box-sizing: content-box使width仅指内容区，padding/border额外叠加；flex中width被flex-basis覆盖，需用flex: 0 0 xx锁定宽度，并全局设, ::before, *::after { box-sizing: border-box }。
不是单位写错了，是单位背后的参照系和计算逻辑没对齐。
box-sizing 默认不是你想要的“总宽”
写了 width: 200px、padding: 12px、border: 2px，实际占位却是 228px——这不是 bug，是 box-sizing: content-box 的标准行为。浏览器只把 width 当作内容区宽度，内外边距和边框全额外叠加。
- 表单控件（
input、textarea）在多数浏览器里仍默认content-box，并排时容易错位 - 第三方 UI 库（如旧版 Element UI）内部依赖
content-box，全局加* { box-sizing: border-box }可能破坏其内边距表现 - 用开发者工具看“Computed”面板里的
box-sizing值，别猜；关键元素（如表单、卡片容器）显式设box-sizing: border-box
flex 子项的 width 是个“建议值”
在 display: flex 容器里，width 不起决定性作用。真正控制尺寸的是 flex-basis，而 flex-shrink 会压缩它，flex-grow 又可能拉伸它。
- 想固定宽度：用
flex: 0 0 200px（等价于flex-grow: 0; flex-shrink: 0; flex-basis: 200px） - 避免同时写
width和flex-basis，后者优先级更高，容易覆盖预期 - 图片或长文本撑开容器？加
min-width: 0配合flex-basis: 0，否则它们会按固有尺寸强行扩展
rem 基准值和渲染链路没对齐
rem 显示不准，90% 情况下不是单位问题，而是 html 的 font-size、编译工具配置、浏览器像素渲染三者脱节。
-
postcss-pxtorem的rootValue必须等于线上html最终生效的font-size（单位是 px），差 1px 就会导致所有尺寸系统性偏移 - JS 动态设置
font-size（比如根据clientWidth计算）时，别用postcss-pxtorem这类编译时工具——改用运行时注入方案，或直接上clamp(1rem, 4vw, 1.5rem) - 禁用
propList: ['*']，尤其别把border转 rem：1px 边框转成0.05rem后，在 2x 屏上可能渲染为 0.1px，直接不可见
绝对定位元素的参照物本身就不稳定
position: absolute 的 top/left/right/bottom 是相对于最近的定位祖先（relative/absolute/fixed），但这个祖先若用 px 固定尺寸、或被 transform: scale() 干扰，子元素就会“失锚”。
- 优先考虑
position: relative+inset：比如inset: 1rem auto auto 2rem，不脱离文档流，父容器尺寸变化时自然跟随 - 避免单独用
left: 20vw——375px 屏是 75px，1920px 屏变成 384px，按钮直接飞出视口；改用calc(50vw - 100px)把固定尺寸和流体单位对齐 - 真需要视口高度？用
dvh替代vh，iOS Safari 地址栏会吃掉一部分vh，dvh才是动态可视高度
最常被忽略的其实是“你以为在调尺寸，其实是在调参照物”。检查时先打开 outline: 1px solid red 把所有盒子显形，再确认是不是容器本身尺寸就错了，而不是单位用得不对。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
