直接用 width/height 写死像素值会失控，因其脱离设计系统、难以主题化、响应式维护成本高；根本原因是缺乏“尺寸语义”，应改用 CSS 自定义属性 + rem 构建可配置层级，并结合 max-inline-size、inline-size 等逻辑属性及 JS 读取能力实现健壮适配。
为什么直接用 width/height 写死像素值会失控
组件尺寸一旦写成 width: 200px; height: 44px;，就和设计系统脱钩了：按钮在卡片里显得太大，在表单里又太小；换一套主题时所有尺寸要全局搜索替换；响应式断点一加，px 值还得再配三套。根本原因是它没抽象出「尺寸语义」——大/中/小不是绝对数值，而是相对层级关系。
用 CSS 自定义属性 + rem 实现可配置的尺寸层级
把「小」「中」「大」映射为根元素上的 CSS 变量，再用 rem 统一驱动：
html {
--size-xs: 0.75rem; /* 12px */
--size-sm: 0.875rem; /* 14px */
--size-md: 1rem; /* 16px */
--size-lg: 1.125rem; /* 18px */
--size-xl: 1.25rem; /* 20px */
}组件类名直接绑定语义，不写具体值：
.btn--sm { padding: var(--size-xs) calc(var(--size-xs) * 1.5); }
.btn--md { padding: var(--size-sm) calc(var(--size-sm) * 1.5); }
.btn--lg { padding: var(--size-md) calc(var(--size-md) * 1.5); }- 修改整套尺寸只需改
html根变量，无需动组件样式 -
rem基于font-size，配合媒体查询可一键缩放全站尺寸（如@media (max-width: 768px) { html { font-size: 14px; } }） - 避免用
em—— 它会继承父级font-size，导致嵌套组件尺寸意外叠加
max-width 和 inline-size 才是响应式组件的真实尺寸锚点
按钮、输入框这类行内级组件，光设 width 容易撑破容器。真正可控的是它的「最大可用宽度」和「内联方向尺寸」：
立即学习“前端免费学习笔记（深入）”；
- 用
max-inline-size: 100%;替代width: 100%;，兼容竖排文本（writing-mode: vertical-rl）场景 - 对卡片类块级组件，
max-width: 480px;比width: 100%;更安全——防止在超宽屏上拉得太开 -
inline-size和block-size是逻辑属性，比width/height更健壮，但注意 Safari 15.4+ 才完全支持
组件尺寸不能只靠 CSS，得让 JS 能读取并参与判断
比如一个下拉菜单，需要根据触发按钮的尺寸动态调整弹层宽度。这时 CSS 变量必须能被 JS 读取：
const root = document.documentElement;
const mdSize = parseFloat(getComputedStyle(root).getPropertyValue('--size-md'));
// → 1 （单位是 rem，需乘以 root font-size 才得 px）
const pxSize = mdSize * parseFloat(getComputedStyle(root).fontSize);- 别用
getComputedStyle(el).width取计算后值——它返回带单位字符串，且不含max-width限制后的实际渲染尺寸 - 组件库内部做尺寸适配时，优先监听
resize事件 +ResizeObserver，而不是依赖窗口宽度断点 - 第三方组件（如 Ant Design）的
size="large"属性，底层仍是映射到同一套 CSS 变量，确保风格统一
真实项目里最常被忽略的，是尺寸系统的「边界行为」：当父容器宽度小于 --size-lg 对应的像素值时，max-inline-size: 100% 会生效，但组件内部的 padding 和 font-size 仍按原 rem 计算，可能造成文字溢出或点击热区过小。这时候得靠 clamp() 或媒体查询兜底，而不是指望一套变量包打天下。
