最稳妥的文字大小控制方式是使用 rem 单位，基于 html 根元素动态设置 font-size（如 100% 或媒体查询适配），避免 px 硬编码、%嵌套失控及 vw 引发的滚动问题，并注意组件内不破坏 rem 基准、第三方库需主题覆盖、渲染差异需 line-height 等协同优化。
用 font-size 控制文字大小最直接，但单位选错就跨平台失效
浏览器对 font-size 的解析依赖单位，而不同单位在缩放、系统字体设置、移动端适配中表现差异极大。比如用 px 在 iOS Safari 缩放时可能被忽略，用 em 又容易因嵌套继承失控。
-
rem是目前最稳妥的选择：基于根元素html的font-size，不受局部样式干扰，也支持用户系统级字体缩放（如 Windows “放大文本” 或 macOS “更大字体”） - 避免纯
px：它在强制缩放模式下不响应，部分安卓 WebView 也不尊重用户设置 - 慎用
%：它继承父级计算值，深层嵌套后实际大小难以预测，调试成本高 - 移动端建议搭配
viewport设置：，否则rem基准可能被缩放打乱
设置根字号（html 的 font-size）不能写死，得适配设备和用户偏好
把 html { font-size: 16px; } 硬编码，等于放弃所有系统字体调节能力。iOS 和 Android 都允许用户在系统设置里调大默认字体，网页应尊重这一行为。
- 推荐用
html { font-size: 100%; }—— 它等价于用户代理默认值（通常是 16px），且会随系统设置变化 - 如需动态响应（比如适配小屏或高DPI），可用 JS 检查
window.devicePixelRatio或matchMedia，但优先走 CSS 媒体查询 - 媒体查询示例：
@media (max-width: 480px) { html { font-size: 14px; } }，比 JS 更轻量、更早生效 - 不要用
vw直接设根字号（如html { font-size: 4vw; }），它会导致横向滚动条意外触发，且在横屏/竖屏切换时跳变
内联样式、CSS-in-JS、框架组件里改文字大小，容易绕过全局基准
React/Vue 组件里写 style={{ fontSize: '18px' }}，或用 styled-components 写 font-size: 1.125rem，看似没问题，但一旦组件内部又设置了 font-size，就会干扰 rem 计算链。
- 组件内尽量用
rem或无单位数值（如1.125，配合em时需明确上下文） - 避免在组件根节点上重设
font-size，尤其别用px；若必须调整，用scale()替代，不影响排版流 - 第三方 UI 库（如 Ant Design、Element Plus）默认用
px，需通过主题变量覆盖为rem，否则和自定义样式混用会失衡 - 检查 DevTools 中的“Computed”面板，确认最终
font-size值是否来自预期层级，而非被某处!important或内联样式劫持
字体渲染差异会让相同 font-size 看起来大小不一
Chrome 和 Safari 对 font-weight、line-height、甚至 font-family 的微调都会影响视觉字号。比如 font-size: 16px 的 "SF Pro Text" 和 "Roboto" 实际占据高度可能差 1–2px。
立即学习“前端免费学习笔记（深入）”；
- 始终显式设置
line-height（推荐无单位值，如1.5），否则不同字体默认行高差异会被放大 - 用
font-feature-settings或text-rendering: optimizeLegibility可能轻微改变字形占位，仅在必要时启用 - 在 macOS 上测试时注意：Safari 默认启用字体平滑，Chrome 可能关闭，导致同一
font-size下文字“发虚”或“发硬”，这不是 bug，是渲染策略不同 - 真要像素级对齐？别靠
font-size调，用transform: scale()+origin微调，但仅限 icon 文字等极少数场景
rem，只要 html 根节点没设 font-size 或设成了 px，整个链路就断了。 
