不是HTML5的问题，而是CSS渲染策略与移动端硬件限制共同导致视觉延迟：高DPR设备下1px边框因像素对齐和缩放适配引发重绘延迟，需用scale、0.5px或box-shadow等方案优化。
HTML5 中用 border 设置实线边框，但手机浏览器渲染慢？先说结论：不是 HTML5 的问题，是 CSS 渲染策略和移动端硬件限制共同导致的视觉延迟
现代手机浏览器（尤其 Android WebView 和旧版 Safari）对细边框（1px）做抗锯齿或 subpixel 渲染时，容易触发重绘/重排或强制使用软件渲染路径，看起来“卡顿”或“加载慢”。这不是边框没生效，而是渲染管线在像素对齐、缩放、DPR（设备像素比）适配上花了额外时间。
border: 1px solid #000 在高 DPR 设备上实际是模糊线，浏览器会“犹豫”怎么画
比如 iPhone 的 DPR=2 或 3，1px CSS 像素实际对应 2～3 物理像素。浏览器若直接画 1 物理像素线，会太细不可见；若拉伸，又变虚或发灰。部分浏览器选择延迟绘制、等待 layout 稳定后再补全，造成“边框出现慢”的错觉。
- 用
window.devicePixelRatio检查当前 DPR，再配合transform: scale(0.5)或border-image手动模拟 1 物理像素线 - 更稳妥的做法：改用
border: 0.5px solid #000（仅 iOS Safari 支持），或退而求其次用border: 1px solid rgba(0,0,0,0.8)提升对比度加快视觉确认 - 避免在
:hover或动画中动态切换border宽度——这会频繁触发 layout，比静态边框慢得多
用 outline 替代 border 能绕过部分渲染瓶颈，但有局限
outline 不占布局空间、不触发重排，某些场景下绘制更快，尤其用于 focus 状态。但它无法设置圆角（outline-radius 无效）、不能分边设置（只能四边统一）、也不支持 border-image。
- 适合场景：
input:focus { outline: 1px solid #007aff; }（iOS Safari 对此优化较好） - 禁用默认 outline 后务必提供替代焦点样式，否则可访问性受损：
outline: none单独写等于自毁体验 - Android Chrome 对
outline的 subpixel 处理仍不稳定，测试时需真机抓帧（Chrome DevTools → Rendering → FPS Meter + Paint Flashing）
真正提速的关键：避免让边框参与复杂合成层判断
当元素同时满足“有 border + 有 transform + 有 will-change + 父容器 overflow:hidden”等条件时，浏览器可能将其提升为独立图层，但初始化图层合成耗时明显。边框本身不慢，慢在它成了“触发器”。
立即学习“前端免费学习笔记（深入）”；
- 检查是否误加了
will-change: border-color—— 这会让浏览器提前准备多套渲染路径，反而拖慢首次绘制 - 用
border: 1px solid transparent占位，后续只改border-color（不触发 layout） - 若边框只是装饰，考虑用
box-shadow: 0 0 0 1px #000，它走的是 GPU 阴影管线，在多数移动端更稳定
边框渲染慢的本质，是像素对齐、DPR 适配、图层策略三者没对齐。别死磕 border 参数，优先看它在什么上下文中被使用——一个 position: fixed 的带边框弹窗，比普通 div 慢三倍，这事跟语法无关。
