text-size-adjust 必须作用于块级祖先容器（如 html、nav、div）才生效，直接写在 p、a、span 等内联元素上无效；其生效前提为页面已通过正确 viewport 设置进入移动端模式，且推荐使用 100% 而非 none 以兼顾可访问性。
text-size-adjust 必须加在祖先容器上才生效
写 p { text-size-adjust: none; } 是无效的。浏览器只检查文本所在块级上下文的计算样式，不是看内联元素本身。你得把声明加到它的父级块容器上，比如 nav、.footer 或最保险的 html。
常见错误是直接作用于 a 或 span —— 这些不是“上下文根”，属性被忽略。真机调试时用 window.getComputedStyle(el).textSizeAdjust 查目标元素，如果返回空字符串，大概率就是加错了位置。
-
html上设是最稳妥的全局控制点 - 局部修复（如页脚菜单）优先选直接包裹文本的
div或ul，别跳过一级写到body - 避免用
*全局匹配，会干扰表单控件、按钮等需要响应系统字体偏好的区域
text-size-adjust: 100% 比 none 更安全且合规
text-size-adjust: none 确实能彻底关掉浏览器自动缩放，但它也同时屏蔽了用户系统级字体偏好（如 iOS「更大字体」、Android「字体大小」设置），违反 WCAG 1.4.4 可访问性要求。而 text-size-adjust: 100% 允许用户手动缩放，仅禁用浏览器基于启发式规则的擅自干预——这才是平衡控制与包容性的正确姿势。
现代浏览器（Chrome 90+、Safari 15.4+、Firefox for Android）对 100% 支持完整，无需前缀；none 则仍需 -webkit- 等兼容写法，且在部分旧版 Safari 上行为不一致。
立即学习“前端免费学习笔记（深入）”；
- 生产环境默认用
html { text-size-adjust: 100%; } - 仅在极少数 UI 严格像素级对齐场景（如图标文字、徽标）才考虑局部用
none - 别信 DevTools 模拟器表现——它默认禁用自动缩放，必须真机验证
viewport 设置错误会让 text-size-adjust 失效
text-size-adjust 生效的前提是页面渲染进入移动端模式。如果 <meta name="viewport"> 缺失、写错或被框架二次注入，浏览器可能回退到桌面布局逻辑，直接忽略该 CSS 属性。
典型症状：写了 html { text-size-adjust: 100%; }，但页脚文字依然比正文小一圈。先检查 <head> 里是否只有一条 <meta name="viewport" content="width=device-width, initial-scale=1.0">，且它位于所有其他 meta 和 link 标签之前。
-
width=device-width是 mandatory 的，initial-scale=1.0单独写等于没写 - 固定写
width=375或width=412会导致横屏失效，不同机型逻辑宽度不同 - 桌面 Chrome 不解析
initial-scale，别试图用 JS 动态插入 meta 去“修复”桌面缩放
验证是否真正生效的关键动作
光看 CSS 文件里写了没用。必须在真机上验证，且不能只靠肉眼判断——同一行文字在 header 和 footer 里看起来一样大，不代表浏览器没做缩放补偿。
打开 Chrome for Android 远程调试，选中目标元素，在 Computed 面板搜 text-size-adjust，确认值为 100% 或 none；再手动开启系统「更大字体」设置，刷新页面，观察文字是否等比放大（100% 应响应，none 不响应）。
- 若 Computed 中查不到该属性，说明声明未命中目标上下文，检查选择器和继承链
- 若响应系统设置失败，排查是否有父级
transform、zoom或百分比font-size干扰继承 - 不要依赖
!important覆盖font-size——这是对抗渲染层干预，无效
