最轻量设备判断用 navigator.userAgent 字符串匹配，优先查 'Mobile' 再补 'Android'、'iPhone'、'iPad'；iPad 需结合 maxTouchPoints > 1 或屏幕宽度；matchMedia 更可靠但无法早执行；服务端判断更稳但需模板化 index.html；禁用 window.innerWidth 做设备分类。
用 navigator.userAgent 做最轻量的设备判断
直接读取 navigator.userAgent 字符串，检查是否包含常见手机/平板标识是最常用、零依赖的方式。它不发请求、不等加载、不调 API，适合在 index.html 的 <script> 标签里第一时间执行。
注意：这不是 100% 准确（比如某些桌面浏览器可伪装 UA），但对绝大多数跳转、样式切换、埋点等场景已足够可靠。
- 手机关键词优先查
'Mobile'（iOS 和多数 Android 浏览器都带这个） - 再补查
'Android'、'iPhone'、'iPad'，避免漏掉非 Mobile 后缀的 UA（如部分微信内置浏览器） - 别只靠
'iPad'判断平板——它在 iOS 13+ 默认返回桌面 UA，需结合maxTouchPoints > 1或屏幕宽度辅助判断
matchMedia 比 UA 更靠谱的响应式 fallback 方案
如果目标是适配布局或加载不同资源，matchMedia 查 '(max-width: 768px)' 或 '(hover: none) and (pointer: coarse)' 往往比 UA 更贴近真实交互能力。它不依赖字符串匹配，而是基于浏览器当前渲染环境。
缺点是无法在 HTML 加载前执行（必须等 DOM ready 或至少 script 执行时），且不能区分“手机开桌面模式”这类 UA 被覆盖的情况。
立即学习“前端免费学习笔记（深入）”；
- 适合做 CSS 切换或动态 import：用
const mql = window.matchMedia('(max-width: 768px)') - 监听变化时记得用
mql.addEventListener('change', handler)（旧版用mql.addListener） - 首次判断别忘了查
mql.matches，否则可能错过初始状态
服务端判断比前端更稳，但 index.html 本身做不到
index.html 是静态文件，浏览器直接加载，服务端没机会插手 UA。真要服务端判别，得把 index.html 改成模板（如 index.php 或通过 Nginx 重写 + 变量注入），由后端读取 User-Agent 请求头后输出对应 HTML。
这么做能规避所有前端 UA 伪造问题，也利于 SEO（搜索引擎看到的是设备适配后的 HTML），但增加了部署复杂度和首字节延迟。
- Nginx 示例：用
$http_user_agent匹配正则，通过sub_filter注入 class 或 JS 变量 - Node.js/Express 示例：用
req.get('User-Agent')解析后渲染模板 - 静态托管平台（如 Vercel、Cloudflare Pages）基本不支持运行时服务端逻辑，这条路走不通
别在 index.html 里用 window.innerWidth 当设备判断依据
window.innerWidth 只反映当前窗口尺寸，不是设备类型。用户缩放浏览器、分屏、DevTools 面板打开都会让它剧烈波动，拿它当“手机/电脑”开关会导致误判。
它适合做「响应式断点」，不适合做「设备分类」。比如你写 if (window.innerWidth < 992) { loadMobileJS() }，用户从 1000px 拖到 991px 就触发一次，体验极差。
- 真正需要设备类型时，坚持用 UA 或服务端头
- 只需要适配布局？纯 CSS media query 就够了，不用 JS 干预
- 必须用 JS 控制资源加载？配合
matchMedia+addEventListener，而不是轮询resize
index.html 的 <script> 里，但最容易被忽略的是 iPad 在桌面模式下的 UA 行为，以及 resize 导致的误触发——这两处不处理好，后续所有适配逻辑都可能翻车。 
