initial-scale=1.0仅控制页面初始缩放，无法响应用户后续的手动缩放（如Ctrl/Cmd+），且当配合user-scalable=no或maximum-scale=1.0时会直接禁用iOS/安卓WebView的手动缩放功能，剥夺弱视用户自主放大权利；真正兼容的方案是移除缩放限制、使用rem/em等相对单位、避免transform:scale()破坏可访问性，并通过操作系统级缩放测试交互可用性。
为什么 initial-scale=1.0 不能保证弱视用户正常缩放
因为 initial-scale 只控制页面加载瞬间的缩放状态，之后用户用 Ctrl/Cmd + + 或系统级文本缩放调整时，它完全不起作用。更关键的是：iOS Safari 和部分安卓 WebView 在 user-scalable=no 或 maximum-scale=1.0 存在时，会直接禁用所有手动缩放行为——这等于把弱视用户的放大权利直接关掉了。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 移除所有
user-scalable=no、maximum-scale=1.0等限制属性 -
viewportmeta 标签只保留width=device-width, initial-scale=1.0，不加其他缩放约束 - 测试时必须用真实操作系统级缩放（如 Windows 显示设置调到 175%，macOS 辅助功能里调大文本），而不是仅靠浏览器 Ctrl+ 验证
transform: scale() 会破坏可访问性，别乱用
用 body { transform: scale(1.3); transform-origin: 0 0; overflow: hidden; } 确实能“看起来”放大整个页面，但它让 JS 获取的 clientWidth、getBoundingClientRect() 等尺寸值仍返回原始值，导致点击热区偏移、滚动位置错乱、屏幕阅读器聚焦错位——对依赖键盘导航或 VoiceOver 的用户是灾难性的。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 绝对不要对
body或html使用transform: scale()来模拟“全局放大” - 如果必须动态缩放（如按钮控制），只作用于内容容器（如
#main-content），并确保其父容器有明确position: relative和overflow: visible - 每次缩放后，手动触发
window.dispatchEvent(new Event('resize'))，让依赖 resize 的脚本有机会重算
真正兼容弱视用户的缩放方案只有两个
一个是靠浏览器原生支持的全页缩放（Ctrl/Cmd +），另一个是操作系统级文本缩放。这两者都要求你的 CSS 单位和布局能响应变化。硬编码 px、固定 width: 320px、滥用 overflow: hidden 都会直接导致内容被裁切或重叠。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 字体统一用
rem或em，根元素html { font-size: 100%; }，不设死值 - 容器宽度优先用
%、max-width、ch或clamp()，避免px固定宽 - 行高用
em或无单位数值（如line-height: 1.6），禁用px行高 - 所有图片加
max-width: 100%; height: auto;，防止放大后溢出容器
测试缩放是否真可用，重点看这三点
不是“页面变大了就行”，而是看放大后用户能否继续完成核心操作。很多页面在 200% 缩放下文字清晰了，但按钮被截断、表单字段点不到、导航栏折叠后无法展开——这些才是实际障碍。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 在 Chrome 中按 Ctrl/Cmd + 至少放大到 200%，检查所有交互控件（按钮、输入框、复选框）是否完整可见且可点击
- 启用 Windows “显示设置 → 缩放与布局 → 175%”，打开页面，确认文字没重叠、行距没塌陷、横向滚动没出现
- 用 macOS VoiceOver + Command + Option + + 连续放大，听读顺序是否仍符合视觉流，跳过的内容是否逻辑连贯
最常被忽略的点：缩放后焦点轮廓（:focus-visible）是否仍清晰可见，以及 outline 是否被 overflow: hidden 切掉——这对键盘用户是致命的。
