低分辨率屏幕适配关键在viewport设置、CSS单位选择和浏览器兼容性；需显式设定viewport宽度、优先使用px单位、查具体CSS/JS特性兼容性并真机测试。
HTML 在低分辨率屏幕写代码没问题，但浏览器渲染可能出问题
能写，完全能写；问题不在 HTML 本身，而在浏览器如何把 <html>、<body> 这些标签转成你眼睛看到的像素。低分辨率屏幕（比如 800×600 或 1024×768 的老设备、小尺寸工控屏）本身不“拒绝” HTML，但现代前端框架、默认 CSS 重置、甚至 viewport 元标签没配对时，页面会缩放错乱、文字挤成一团、按钮点不中。
viewport 元标签配错是低分辨率下最常见白屏/缩放异常原因
很多开发者直接复制 “响应式模板” 里的 <meta name="viewport" content="width=device-width, initial-scale=1.0">，但在 800×600 屏上，device-width 可能被浏览器识别为 800，导致强制缩放到“看起来像手机”，实际内容反而变小、交互失效。
- 真实场景：嵌入式 Linux 设备跑 Chromium，分辨率固定为 1024×600，但页面默认按 375px 宽渲染，右侧大面积空白
- 正确做法：显式设
width=1024（或你目标视口宽度），禁用缩放：<meta name="viewport" content="width=1024, user-scalable=no, initial-scale=1.0"> - 注意：
initial-scale=1.0在某些旧版 Android WebView 下无效，得加maximum-scale=1.0补全 - 别信“自动适配”——低分屏没有“DPR”概念，
device-pixel-ratio基本是 1，硬套高清屏逻辑必翻车
CSS 单位选 px 而非 rem 或 em 更稳妥
在分辨率固定、DPI 明确的低分屏上，rem 依赖根字体大小，而根字体又常被浏览器默认样式或 normalize.css 干扰；em 更容易因嵌套层层放大缩小。这时候反而是最原始的 px 最可控。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 按钮高度设
height: 32px，比height: 2rem更容易保证在 600px 高的屏幕里有足够点击区域 - 字体大小同理：
font-size: 14px比font-size: 0.875rem少一层计算误差 - 如果必须用相对单位，只在容器级用
%（如width: 90%），内部元素回归px控制细节 - 避免
vw/vh：1vw = 视口宽的 1%，在 800px 宽屏上就是 8px，稍一写多就溢出或过小，调试极难
硬件最低适配不是看 CPU 或内存，而是看浏览器内核和 CSS 支持表
所谓“最低适配”，实际是问“哪个浏览器版本能在该屏上正确解析 flex、grid、甚至 position: sticky”。老设备常配旧内核（如 Chromium 53、WebKitGTK 2.4），这些版本对现代 CSS 支持残缺。
立即学习“前端免费学习笔记（深入）”；
- 查兼容性不要查“HTML5”，要查具体特性：比如
display: grid在 Chromium 57+ 才稳定，低于此版本回退到float或inline-block - 用
@supports做渐进增强：@supports (display: grid) { ... }，否则直接写grid会让老内核忽略整段样式 - JavaScript 同理：
fetch()在 Chromium 42+ 支持，若设备跑的是 40，就得用XMLHttpRequest回退 - 真机测试比模拟器重要：Chrome DevTools 的 device mode 会伪造 DPR 和 UA，但无法模拟旧内核的布局 bug
低分辨率本身不构成技术门槛，卡住人的永远是“以为它能跑新东西”——而它连 border-box 的盒模型都可能解析错。
