text-size-adjust: none 是唯一能彻底禁用浏览器自动文本缩放的硬性手段，必须作用于文本祖先容器（如 .menu 或 #bottommenublock），而非内联标签；现代浏览器原生支持，但会牺牲可访问性，推荐生产环境优先使用 text-size-adjust: 100% 平衡控制与用户自主调节能力。
text-size-adjust: none 是最直接的硬性重置手段
当菜单文字在 Android Chrome 真机上出现“明明写了 1rem，却比其他区域小一圈”的现象，text-size-adjust: none 就是唯一能彻底切断浏览器自动干预的 CSS 声明。它不是“建议”或“优化”，而是强制禁用文本缩放引擎——现代浏览器（Chrome ≥ 76、Firefox ≥ 69、Safari iOS ≥ 9.3）均原生支持，无需 polyfill。
常见错误是把它写在 a 或 span 上：该属性必须作用于文本的**祖先容器**，否则无效。例如：.menu 或 nav 元素才应加此声明，而非其内部的文字标签。
- 写在
html或body上会全局生效，但会牺牲可访问性 - 写在
#bottommenublock这类具体模块选择器上，才是生产环境推荐做法 - 若同时用了
transform: scale()或zoom，可能干扰计算，需一并排查
为什么 text-size-adjust: 100% 比 none 更稳妥
text-size-adjust: 100% 允许用户通过系统设置（如 iOS「更大字体」、Android「字体大小」滑块）主动调整字号，但禁止浏览器基于行宽、字号启发式地“擅自放大”。它在真机上同样能解决菜单文字忽大忽小的问题，且不破坏辅助技术链路。
这个值在绝大多数场景下效果与 none 一致，但兼容性略高（旧版 Safari 对 none 支持不稳定），更重要的是——它把控制权交还给用户。
立即学习“前端免费学习笔记（深入）”；
- 必须设在包含文本的容器上，比如
.footer-nav，不能只设在p或li - 若父级已设
font-size: 14px，text-size-adjust: 100%会严格按此渲染，不再叠加缩放因子 - 在 Chrome DevTools 的 Computed 面板中搜索
text-size-adjust，确认值为100%即生效
viewport meta 标签无法替代 text-size-adjust
很多人试图用 <meta name="viewport" content="width=device-width, initial-scale=1.0"> 解决字体缩放问题，但它只影响布局视口缩放，对文本自动缩放机制完全无效。即使加上 user-scalable=no，Android Chrome 仍会根据内容密度触发最小字号保护逻辑。
真正起作用的是 text-size-adjust，viewport 只负责初始布局尺度。两者职责不同，不可混淆。
-
maximum-scale=1.0和user-scalable=no仅限制用户双指缩放，不影响浏览器自动文本缩放 - 如果页面已有 viewport 设置但菜单文字仍异常，说明问题不在 viewport，而在 text-size-adjust 缺失
- 部分旧文档误传“viewport + font-size: 16px 能防缩放”，实测在 Android Chrome 120+ 上已失效
验证是否生效的关键检查点
光写 CSS 不够，必须在真机上验证。模拟器和 DevTools 设备模式无法复现真实缩放行为，因为它们不启用底层文本缩放引擎。
打开 Chrome for Android 远程调试，在 Elements 面板选中目标菜单项，看 Computed 中 text-size-adjust 是否为 none 或 100%；也可在 Console 执行 window.getComputedStyle(document.querySelector('.menu-item')).textSizeAdjust 直接读取值。
- 若返回空字符串或
auto，说明样式未命中或被更高优先级规则覆盖 - 若返回
none但文字仍缩放，需检查是否有父级设置了transform或font-size百分比继承链 - iOS 上某些版本对
text-size-adjust的解析存在延迟，建议配合font-size: 1rem显式声明
span，就足以让整个菜单视觉断裂。 
