HTML5本身不提供“改格式”功能，实际依赖CSS媒体查询、touch事件处理和移动端适配实践；平板上document.body.style.fontSize失效主因是viewport未禁用缩放、使用px固定单位、监听click而非touchstart；横竖屏适配优先用resize防抖+matchMedia判断方向；触屏拖拽卡顿关键在touchstart未preventDefault及避免同步layout读写。
HTML5 本身不提供“改格式”功能，所谓“HTML5改格式平板可用_触屏友好”，实际是用 HTML5 技术构建的响应式、支持触摸事件的前端工具——核心不在 HTML5 版本，而在 CSS 媒体查询、touchstart/touchmove 事件处理和移动端适配实践。
为什么直接用 document.body.style.fontSize 在平板上失效
很多开发者尝试用 JS 动态改字体、宽高来“改格式”，但在 iPad 或安卓平板上常无反应，原因通常是：
- 未禁用双指缩放：
缺失或user-scalable=yes导致样式被用户手势覆盖 - 使用了
px固定单位，未切换到rem或vw/vh，导致横竖屏切换时布局断裂 - 监听了
click而非touchstart，在部分 Android 平板上存在 300ms 延迟甚至不触发
resize 和 orientationchange 哪个更适合平板横竖屏适配
orientationchange 更精准，但兼容性差（iOS Safari 支持，Chrome for Android 已弃用）；resize 更通用，但会高频触发。真实项目中建议：
- 优先监听
resize，并用setTimeout防抖（延迟 100ms 再执行布局重算） - 同时读取
window.matchMedia("(orientation: landscape)").matches判断方向，比依赖事件更可靠 - 避免在回调里直接操作 DOM 样式，改用切换预设 class，例如：
document.body.classList.toggle("layout-landscape", isLandscape)
触屏拖拽改布局时，touchmove 为何总卡顿
卡顿主因是默认行为未阻止，或重绘逻辑过重。关键修复点：
立即学习“前端免费学习笔记（深入）”；
- 必须在
touchstart中调用event.preventDefault()，否则 iOS 会触发滚动/缩放干扰 -
touchmove中避免读写 layout 属性（如offsetTop），改用getBoundingClientRect()批量读取 +requestAnimationFrame更新 - 不要在每次
touchmove都调用element.style.transform = "translateX(...) translateY(...)"，改用CSS transform: translate3d(0,0,0)触发 GPU 加速
真正“触屏友好”的格式调整，不是加一堆 HTML5 标签，而是控制 viewport、用对触摸事件、避开强制同步 layout 读写——这些细节在桌面端不明显，一上平板立刻暴露。最易被忽略的是：没有在 touchstart 里 preventDefault，却反复调试 touchmove 的坐标计算逻辑。
